MySQL主从结构在线迁移至PXC高可用集群的方案（四）

持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第8天，点击查看活动详情

上文介绍了业务验证和生产流量切换环节，本文继续回退方案和高可用配置。

回退方案

发生以下情形，中止方案并进行回退

• 从库拉起pxc集群失败 从库以普通mysql模式重启，恢复主从同步
• 业务验证不通过 清理业务验证数据，从库以普通mysql模式重启，恢复主从同步
• 生产流量切至pxc后业务异常 根据数据产生情况，选择以下两个方案之一回退到mysql模式

1. 取消原主库read_only模式，将流量切回蓝色环境，可能需要处理业务验证期间写入pxc集群的数据
2. 停止pxc集群节点，以普通mysql模式拉起实例（数据是最新和最全的，不需要额外处理，后续将原主库作为从库从新主库同步数据）

高可用配置

假设我们已经建立了一个两个pxc server 加一个仲裁节点的集群，或者三个pxc server的集群，本文描述一种应用通过k8s service直连pxc server的方案，可以比使用haproxy代理等方式降低约9%的时延，通过一个pxc-check脚本，实时监测pxc节点的可用性，在当前连接节点不可用且另一节点可用时，自动切换k8s service连接指向可用节点。
具体方案如下：

建立k8s service

用pxc集群的两个实例，建立一主一备两个service和对应的endpoint

vim mysql-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: mysql
  namespace: ext
spec:
  ports:
  - port: 3306
    protocol: TCP
    targetPort: 3306
  type: ClusterIP
---
apiVersion: v1
kind: Endpoints
metadata:
  name: mysql
  namespace: ext
subsets:
- addresses:
  - ip: {ip}
  ports:
  - port: 3306
    protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: mysql-bak
  namespace: ext
spec:
  ports:
  - port: 3306
    protocol: TCP
    targetPort: 3306
  type: ClusterIP
---
apiVersion: v1
kind: Endpoints
metadata:
  name: mysql-bak
  namespace: ext
subsets:
- addresses:
  - ip: {ip-bak}
  ports:
  - port: 3306
    protocol: TCP
    
kubectl apply -f mysql-service.yaml

配置pxc-check

总体流程如下：

1. kubectl每秒获取mysql k8s 的主备service的ip、端口，
2. 分别检查实例的可用性
3. 主实例不可用，备用可用时，kubectl替换主备service的ip
4. 将以上逻辑写入脚本，并打包成镜像发布到k8s集群中
5. 为保证不可用节点的应用连接尽快释放，可以通过配置wsrep_notify_cmd=/var/lib/mysql/wsrep_notify.sh，在节点不可用时，主动kill应用连接。