Home • Explore • Blog • CI
☰



kubernetes
4th chunk of `content/en/blog/_posts/2018-03-00-How-To-Integrate-Rollingupdate-Strategy.md`
5cd132c2db8ad098c75b8d057b252657f71149454c674baf000000010000090f
![](https://lh6.googleusercontent.com/7xnN_sODa-3Ch3ScAUlggCTeYfnE3-wxRaCIHrljHCB7LnXgth8zeCv0gk_UU1jbSDBQuACQ2Mf1FO1-E7GvMWwGKjp7irenAKp4DkHlA5LR9OVuLXqubPFhhksA8kfBUh4Z4OuN)  


###  Feature : RollingUpdate Strategy

MySQL Sharding Cluster brings us not only strong scalability but also some level of maintenance complexity. For example, when updating a MySQL configuration like innodb_buffer_pool_size, a DBA has to perform a number of steps:

1\. Apply change time.  
2\. Disable client access to database proxies.  
3\. Start a rolling upgrade.


Rolling upgrades need to proceed in order and are the most demanding step of the process. One cannot continue a rolling upgrade until and unless previous updates to MySQL instances are running and ready.

4 Verify the cluster.  
5\. Enable client access to database proxies.

Possible problems with a rolling upgrade include:  

* node reboot
* MySQL instances restart
* human error
Instead, WQ-RDS enables a DBA to perform rolling upgrades automatically.

###  StatefulSet RollingUpdate in Kubernetes

Kubernetes 1.7 includes a major feature that adds automated updates to StatefulSets and supports a range of update strategies including rolling updates.

**Note:** For more information about [StatefulSet RollingUpdate][4], see the Kubernetes docs.

Because TPR (currently CRD) does not support the rolling upgrade strategy, we needed to integrate the RollingUpdate strategy into WQ-RDS. Fortunately, the [Kubernetes repo][5] is a treasure for learning. In the process of implementation, there are some points to share:  

* **MySQL Sharding Cluster has ****changed**: Each StatefulSet has its corresponding ControllerRevision, which records all the revision data and order (like git). Whenever StatefulSet is syncing, StatefulSet Controller will firstly compare it's spec to the latest corresponding ControllerRevision data (similar to git diff). If changed, a new ControllerrRevision will be generated, and the revision number will be incremented by 1. WQ-RDS borrows the process, MySQL Sharding Cluster object will record all the revision and order in ControllerRevision.
* **How to perform a Rolling ****Upgrade**: Statefulset recreates pods in strictly decreasing order. The difference is that WQ-RDS updates shards instead of recreating them, as shown below:
Title: RollingUpdate Strategy in WQ-RDS for MySQL Sharding Clusters
Summary
This section discusses the RollingUpdate strategy in WQ-RDS, designed to simplify maintenance tasks for MySQL Sharding Clusters. It outlines the manual steps typically involved in updating MySQL configurations and the potential problems associated with rolling upgrades. WQ-RDS automates these rolling upgrades. It describes how WQ-RDS integrates the RollingUpdate strategy due to TPR limitations and explains the implementation process, including how MySQL Sharding Cluster changes are tracked using ControllerRevision and how shards are updated in decreasing order, differing from StatefulSet's pod recreation approach.