mysql集群的几种方案

Asynchronous Replication Automatic failover

其原理是在一条异步复制通道上配置多个可用复制源，当某个复制源不可用时（宕机、复制链路中断），且 slave 的 IO 线程尝试重连无效，自动根据权重选择新的源继续同步。

准备一个 MGR 集群和单实例，模拟复制链路切换，当 primary 故障，slave 自动切换到其他节点。dbdeployer deploy replication --topology=group 8.0.22 --single-primarydbdeployer deploy single 8.0.22

2. 在从机上建立指向 MGR 主节点的复制通道，

change master to master_user='msandbox',master_password='msandbox', master_host='127.0.0.1',master_auto_position=1,source_connection_auto_failover=1,master_port=23223,master_retry_count=6,master_connect_retry=10 for channel 'mgr-single'

在 master_retry_count 和 master_connect_retry 的设置上要考虑尝试重连多久才切换复制源。

3. 在从机上配置 asynchronous connection auto failover

配置 asynchronous connection auto failover 的两个函数：

asynchronous_connection_failover_add_source(channel-name,host,port,network-namespace,weight)

asynchronous_connection_failover_delete_source(channel-name,host,port,network-namespace)

权重值大的被优先级选择，可以配合MGR的选举权重配置 asynchronous_connection_failover 的权重。当 MGR 节点切换，异步复制也能切换到新的主节点。

SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23223,null,100)SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23224,null,80)SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23225,null,50)start slave for channel 'mgr-single'

4. 检查异步复制通道是否启用 failover。

mysql>SELECT CHANNEL_NAME, SOURCE_CONNECTION_AUTO_FAILOVER FROM performance_schema.replication_connection_configuration+--------------+---------------------------------+| CHANNEL_NAME | SOURCE_CONNECTION_AUTO_FAILOVER |+--------------+---------------------------------+| mgr-single   |  1                              |+--------------+---------------------------------+1 row in set (0.01 sec

5. 把 MGR 的 primary 节点 kill 掉，这个从节点会在尝试几轮重连失败后自动切换到次权重的复制源，其日志中会输出切换信息。

注意：当主节点故障，一旦复制链路成功 failover 后，在新的复制链路没有故障时，如果原主节点恢复，是不会回切的。如果当前复制链路发生故障，会再次选择权重高的进行切换

本文将演示如何在 KubeSphere[1] 上部署 RadonDB MySQL on Kubernetes 2.1.2 ，快速实现高可用的 MySQL on K8s。

若已在 KubeSphere 部署过历史版本 Operator，可以选择如下方式更新到最新版本。

可任选一个 RadonDB MySQL 配置示例[5] 部署，或自定义配置部署。

以 mysql_v1alpha1_mysqlcluster.yaml 模版为例，创建一个 RadonDB MySQL 集群。

注意

未指定项目时，集群将被默认安装在 kubesphere-controls-system 项目中。若需指定项目，安装命令需添加 --namespace=<project_name>。

预期结果

预期结果

在 demo-project 项目中，查看 RadonDB MySQL 集群状态。

至此，完成在 KubeSphere 中部署 RadonDB MySQL 集群。

[1]：KubeSphere： https://kubesphere.com.cn

[2]：OpenPitrix： https://kubesphere.io/zh/docs/pluggable-components/app-store

[3]：创建 *** 作： https://kubesphere.io/zh/docs/quick-start/create-workspace-and-project

[4]：项目网关： https://kubesphere.io/zh/docs/project-administration/project-gateway

[5]：配置示例： https://github.com/radondb/radondb-mysql-kubernetes/blob/main/config/samples

1.Mysql cluster: share-nothing,分布式节点架构的存储方案，以便于提供容错性和高性能。

需要用到mysql cluster安装包，在集群中的每一个机器上安装。

有三个关键概念：Sql节点（多个），数据节点（多个），管理节点（一个），数据节点之间采用的是同步复制来保证各节点之间的数据一致性。

同步复制：

a) Master执行提交语句时，事务被发送到slave，slave开始准备事务的提交。

b) 每个slave都要准备事务，然后向master发送OK(或ABORT)消息，表明事务已经准备好（或者无法准备该事务）。

c) Master等待所有Slave发送OK或ABORT消息，如果Master收到所有 Slave的OK消息，它就会向所有Slave发送提交消息，告诉Slave提交该事务；如果 Master收到来自任何一个Slave的ABORT消息，它就向所有 Slave发送ABORT消息，告诉Slave去中止事务。

e) 每个Slave等待来自Master的OK或ABORT消息。如果Slave收到提交请求，它们就会提交事务，并向Master发送事务已提交 的确认；如果Slave收到取消请求,它们就会撤销所有改变并释放所占有的资源，从而中止事务，然后向Masterv送事务已中止的确认。

f) Master收到来自所有Slave的确认后，就会报告该事务被提交（或中止），然后继续进行下一个事务处理。

由于同步复制一共需要4次消息传递，故mysql  cluster的数据更新速度比单机mysql要慢。所以mysql cluster要求运行在千兆以上的局域网内，节点可以采用双网卡，节点组之间采用直连方式。

2.主从（Master-Slave）: 主从机器上安装mysql community（普通版）就可以。

主从之间是通过mysql的replication来保证数据的一致性。相对mysql cluster的数据同步方式来讲是异步的。

Replication：主节点要开启binlog，设置一个唯一的服务器id（局域网内唯一）；从节点设置服务器id，binlog记录了master上的所有 *** 作，会被复制到从节点的relaylog并在从节点上回放。

---