# Recommended actions for PXC in case maintenance windows **URL:** \ **Category:** Percona Operator for MySQL\ **Created:** [March 13, 2023, 5:55pm UTC](https://forums.percona.com/t/recommended-actions-for-pxc-in-case-maintenance-windows/20545 "2023-03-13T17:55:29Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Francisco\_Ruben\_Jime](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/francisco_ruben_jime/32/9183_2.png) [@Francisco\_Ruben\_Jime](https://forums.percona.com/u/Francisco_Ruben_Jime)\ **Post date:** [March 13, 2023, 5:55pm UTC](https://forums.percona.com/t/recommended-actions-for-pxc-in-case-maintenance-windows/20545/1 "2023-03-13T17:55:29Z")
Hi all, Good day! We had implemented 3 PXC clusters, running each on a different OCP cluster. Like the diagram attached. ![pxc diagram](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/2X/8/8910c6a20e5c35e8ec05381710c6190f8ff33df2.png) What are the best practices in the following scenarios? - We need to take the OCP Cluster hosting PXC1 offline for maintenance but do not want to disrupt database services. Is there an automatic way to switch over pxc, I mean, to change from Source to Replica and from Replica to Source? Or what is your recommended approach for this needs. Current pxc and ocp version included in the diagram. ---
**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\ **Post date:** [March 13, 2023, 8:52pm UTC](https://forums.percona.com/t/recommended-actions-for-pxc-in-case-maintenance-windows/20545/2 "2023-03-13T20:52:52Z")
Hello @Francisco_Ruben_Jime, Just to clarify, do you have 3-node clusters in each OCP cluster (total 9 servers)? Or just 1 PXC, with 3-nodes (total 3 servers), each node in a different OCP? Your diagram seems to show the former, 3 separate clusters, using async replication to keep 2 clusters in sync with the primary cluster. If this is the case, I would do the following: - Stop replication from PXC1-\>PXC3 - Establish replication from PXC2-\>PXC3 - Shut down PXC1 as needed based on your plan - Move applications to PXC2 The tricky part comes with PXC1 is back online. You will need to configure replication from PXC2-\>PXC1 in order to sync all the changes that occurred on PXC2 while PXC1 was offline ---
**Author:** ![Francisco\_Ruben\_Jime](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/francisco_ruben_jime/32/9183_2.png) [@Francisco\_Ruben\_Jime](https://forums.percona.com/u/Francisco_Ruben_Jime)\ **Post date:** [March 13, 2023, 9:57pm UTC](https://forums.percona.com/t/recommended-actions-for-pxc-in-case-maintenance-windows/20545/3 "2023-03-13T21:57:57Z")
Your supposition was right, We have 3-node clusters in each OCP cluster (total 9 servers). Analyzing your suggested action path… and I apologize in advance if I am doing so basic questions, This is our very first implementation of the Percona Operator for MySQL, hopefully not the last one. When you mention: **stopping the replication** is just as simple as removing the **replicationChannels** section from the cr.yaml file, or involve a **pause: true** of the PXC cluster? Your step number two, involves first Stop replication from PXC2, and after that configure as a **isSource: true** for PXC2 and finally configure replication from PXC2 to PXC3. The step number three, involve a **pause: true** of the PXC1 cluster, right? for a graceful poweroff of the running instances. I think we understood the logic of your suggested steps, I have a final doubt, all those steps can be safely without any db service disruption? Is there a plan to do the mentioned process automatically? a sort of Orchestrator: MySQL Replication Topology Manager, for Percona Operator for MySQL. ---
**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\ **Post date:** [March 14, 2023, 1:29am UTC](https://forums.percona.com/t/recommended-actions-for-pxc-in-case-maintenance-windows/20545/4 "2023-03-14T01:29:57Z")
I must apologize, I am not familiar enough with K8S and our operator to give guidance on those aspects within the config files. The steps I gave were a high-level process. You have a highly complex and unusual setup. There isn’t anything I know of that can do this automatically. If you were using a standard MySQL replication, then yes, Orchestrator would be able to handle this via some drag-n-drop. But since you are using PXC in a multi-cluster setup, Orchestrator can’t help here.