MySQL8.0 异步复制源asynchronous_connection_failover

MySQL复制源，简单说就是配置多个可用复制源，当某个复制源不可用时(宕机、复制链路中断)自动根据权重选择新的源继续同步。有点类似于MongoDB的复制机制，但还是有一些区别的。

1.复制源开始

下面官方解释：
MySQL8.0.22开始，可以使用异步连接故障转移机制，在从一个副本到其源的现有连接失败后，根据权重，自动建立到新源的异步(源到副本)复制连接。异步连接故障转移机制可用于与多个MySQL服务器或共享数据的服务器组并保持副本同步。源服务器的列表信息存储在目标节点上。

MySQL 8.0.23版本支持组复制拓扑，通过自动监视对组成员的更改和区分主服务器和辅助服务器。当向源列表添加组成员并将其定义为托管组的一部分时，异步连接故障转移机制将更新源列表，使其与成员更改保持一致，并在组成员加入或离开时自动添加和删除组成员。只有占多数的在线组成员才用于连接和获取状态。如果管理组的最后一个成员离开了该组，则不会自动删除该成员，以便保留该管理组的配置。

2.实现方式

了解复制源之前，还记得2020年7月份master slave 术语事件，应对这部分官方给了新的命名方式，MySQL8.0.23版本开始就是replica和source。当然以前的方式也支持。5.7版本无这个待遇。
下面是新的复制命令方式：

复制源:

要激活复制通道,需要开启这个关键参数

SOURCE_CONNECTION_AUTO_FAILOVER=1

切换原理

当到源的现有连接失败时，副本首先重试相同的连接，通过SOURCE_CONNECT_RETRY 和 SOURCE_RETRY_COUNT 参数进行尝试。当这些尝试耗尽时，异步连接故障转移机制将接管。
异步连接故障转移机制在副本到源的连接失败后被激活，它发出一个START REPLICA 语句试图连接到一个新的源。
目前如果复制I/O线程由于源停止或网络故障而停止，则连接将中断。在任何其他情况下，例如当复制线程被STOP REPLICA语句停止时，连接不会故障转移。

3个参数关键点

SLAVE_NET_TIMEOUT:表示slave在slave_net_timeout时间之内没有收到master的任何数据(包括binlog，heartbeat)，slave认为连接断开，会进行重连。
SOURCE_CONNECT_RETRY 参数指定。默认值60s。表示重连的时间间隔。slave_net_timeout超时后，立刻重连，
SOURCE_RETRY_COUNT表示重连的最大次数。默认值86400次。

合适的值是SOURCE_RETRY_COUNT=3 重试连接3次和S
OURCE_CONNECT_RETRY=10 间隔10秒。

接口

添加和删除复制源操作：

主从复制函数：
asynchronous_connection_failover_add_source
asynchronous_connection_failover_delete_source

#asynchronous_connection_failover_add_source(channel, host, port, network_namespace, weight)

SELECT asynchronous_connection_failover_add_source('channel2', '127.0.0.1', 3310, '', 80);
SELECT asynchronous_connection_failover_delete_source('channel2', '127.0.0.1', 3310, '');

MGR函数：
asynchronous_connection_failover_add_managed
asynchronous_connection_failover_delete_managed

#asynchronous_connection_failover_add_managed(channel, managed_type, managed_name, host, port, network_namespace, primary_weight, secondary_weight)
SELECT asynchronous_connection_failover_add_managed('channel2', 'GroupReplication', 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa', '127.0.0.1', 3310, '', 80, 60);
SELECT asynchronous_connection_failover_delete_managed('channel2', 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa');

MySQL实例的主机名、端口号、网络命名空间和加权优先级(1-100,100是最高优先级)，以便从通道的源列表中添加或删除。
对于MGR，还可以指定管理服务的类型(目前只有“组复制”可用)和管理组的标识符(对于“组复制”，这是系统变量group_replication_group_name的值)，只需要添加一个组成员，副本将自动添加当前组成员中的其余成员。

系统视图：

源信息存储在mysql库下
1.mysql.replication_asynchronous_connection_failover
2.mysql.replication_asynchronous_connection_failover_managed
3.上述两个表官方提示中不允许使用TRUNCATE TABLE。测试实际情况可以truncate。
视图在Performance Schema下
1.replication_asynchronous_connection_failover
2.replication_asynchronous_connection_failover_managed
3.该副本使用一个监视线程来跟踪托管组的成员关系并更新源列表(thread/sql/replica_monitor)。

了解了关键指标和接口，就可以实际动起来。

3个常用场景：

设置复制区域通道的副本上的源列表。可以使用asynchronous_connection_failover_add_source和asynchronous_connection_failover_delete_source udf设置和管理源列表，以添加和删除单个复制源服务器

添加源：

SELECT asynchronous_connection_failover_add_source('channel_rpl', '10.100.20.206', 3306, '', 70);
SELECT asynchronous_connection_failover_add_source('channel_rpl', '10.100.20.206', 3307, '', 80);

删除源：

SELECT asynchronous_connection_failover_delete_source('channelS206', '10.100.20.206', 3307, '');

配置复制：

SET GLOBAL slave_net_timeout=2;

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='10.100.20.206',
  SOURCE_USER='repl',
  SOURCE_PASSWORD='123456',
  SOURCE_PORT=3306,
  SOURCE_CONNECTION_AUTO_FAILOVER=1, 
  SOURCE_AUTO_POSITION = 1,
  SOURCE_CONNECT_RETRY = 1,
  SOURCE_RETRY_COUNT = 6
  FOR CHANNEL 'channel_rpl' ;

问题点：

在主从架构下如果主库M突然宕机，导致从库S为新的复制源。从库S 已提升为主，但这时候主库突然恢复，复制源又会指原先的M。
切换之前如从库S之前的事务写入并且被purge了，复制源切换之后复制就会失败。

随着引入复制源，主从架构下，需要确保复制源变化控制（目前脚本+mysql原表直接updata方式），应该更便利。
双主架构下可以有效的切换，只要保证不出现脑裂，非常好用。

添加源：

#确认组名
SELECT @@group_replication_group_name;
#集群节点信息
select * from performance_schema.replication_group_members;
#复制源添加集群
SELECT asynchronous_connection_failover_add_managed('channel_rpl', 'GroupReplication', 'd150c201-c02c-11eb-a374-38f3ab632406', '10.132.20.206', 3306, '', 80, 60);

删除源：

SELECT asynchronous_connection_failover_delete_managed('channel_rpl', '02d95097-c036-11eb-9dff-38f3ab632406');

备注：从一个MGR 到另一个MGR ,配置值的时候需要多源复制配置项

CHANGE REPLICATION FILTER filter[, filter]
	[, ...] [FOR CHANNEL channel]

使用mysql-shell创建集群,元信息在mysql_innodb_cluster_metadata库，有变更信息也会同步，除此之外mysql库内部用户也会同步。不同的MGR集群之间是不允许的。除非不使用shell创建。

问题点：

group_replication_exit_state_action：比较关键,建议选择ABORT_SERVER

参数	意义
READ_ONLY	禁用服务器上的写操作
ABORT_SERVER	关闭服务器
OFFLINE_MODE	关闭所有链接，并禁止没有 CONNECTION_ADMIN 或 SUPER 权限的用户建立新的连接

目标端MGR集群破坏掉之后，目标端主节点复制配置，需要更改到新的节点，目前没有全局的配置方式，之后需要手动去处理。
源端MGR集群破坏掉之后，有可能会接到断开的节点上面，需要都方面测试验证，是否存在bug之类的。

双主V双主同步，通过不同的复制源channel控制，但场景太复杂，不好控制，可以放弃。

注意事项：

在通道的源列表中的所有源服务器上必须存在相同的复制用户帐户和密码。此帐户用于连接到每个源。
复制用户帐户必须具有Performance Schema表的SELECT权限，例如，GRANT SELECT ON performance_schema.* TO ‘repl’;
复制源是异步机制，所以存在延迟很正常。
源列表上的另一个可用服务器具有更高的优先级(权重)设置，异步连接故障转移机制也会在连接上失效.

总结：

从一个集群（主从，双主，MGR）到另一个主从集群可以很好的利用起来，但存在部分问题，上面提到，当一个集群发生多次分裂之后，同步的源是否有效，无法有效判断。需要人为干涩。
从MGR到MGR不建议是使用，心跳问题导致脑裂等方面还无法有效确认，新鲜的东西，总是有熟悉和了解的过程
稳定性方面，目前也没有案例。能做到无误差的心跳检测，各种场景下的正常切换，起码像主从一样效果，只能在慢慢磨练优化。

try harder!