Topologies
Operations
Backup And Restores
Custom Secret
Monitoring
A switchover is a planned operation where the primary instance in a MySQL cluster proactively transfers its role to a secondary instance. Unlike an unplanned failover, which occurs during unexpected failures, a switchover ensures a controlled and predictable role transition with minimal service disruption.
Aspect | Switchover | Failover |
---|---|---|
Initiation | Planned and manually triggered | Unplanned and automatically triggered |
Downtime | Few hundred milliseconds | Several seconds or more |
Primary Role Transition | Proactively transferred | Reactively promoted |
Use Case | Planned maintenance (e.g., upgrades) | Handling unexpected failures |
Using a switchover ensures smooth transitions and minimal service disruption, making it the preferred choice for planned maintenance activities.
Before proceeding, ensure the following:
kubectl create ns demo
namespace/demo created
Deploy a 2-node semi-sync MySQL cluster (1 primary, 1 secondary):
kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
name: example-mysql-cluster
namespace: demo
spec:
clusterDef: mysql
topology: semisync
terminationPolicy: Delete
componentSpecs:
- name: mysql
serviceVersion: 8.0.35
replicas: 2
resources:
limits:
cpu: '0.5'
memory: 0.5Gi
requests:
cpu: '0.5'
memory: 0.5Gi
volumeClaimTemplates:
- name: data
spec:
storageClassName: ""
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
EOF
Monitor the status of the MySQL cluster as it is created:
kubectl get cluster -n demo -w
Example Output:
NAME CLUSTER-DEFINITION TERMINATION-POLICY STATUS AGE
example-mysql-cluster mysql Delete Creating 4s
example-mysql-cluster mysql Delete Running 62s
List the Pods and their roles (primary or secondary):
kubectl get pods -n demo -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.kubeblocks\.io/role}{"\n"}{end}'
Example Output:
example-mysql-cluster-mysql-0 primary
example-mysql-cluster-mysql-1 secondary
To initiate a planned switchover, create an OpsRequest resource as shown below:
kubectl apply -f - <<EOF
apiVersion: operations.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
name: example-mysql-switchover-ops
namespace: demo
spec:
clusterName: example-mysql-cluster
type: Switchover
switchover:
- componentName: mysql
instanceName: example-mysql-cluster-mysql-0
EOF
Key Parameters:
instanceName
: Specifies the instance (Pod) that is primary or leader before a switchover operation.You can check the progress of the scaling operation with the following command:
kubectl describe ops example-mysql-switchover-ops -n demo
Expected Result:
Status:
Phase: Succeed
Progress: 1/1
...
After the switchover is executed, the specified instance ('example-semisync-mysql-mysql-0') will be promoted to the primary role, while the previously primary instance ('example-semisync-mysql-mysql-1') will take on the secondary role.
kubectl get pods -n demo -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.kubeblocks\.io/role}{"\n"}{end}'
example-mysql-cluster-mysql-0 secondary
example-mysql-cluster-mysql-1 primary
In this example:
Key Benefits of Planned Switchover:
In this guide, you learned how to:
Planned switchover is a critical operation for maintaining high availability during maintenance tasks, ensuring minimal service disruption and predictable transitions in highly available systems.