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 后，在新的复制链路没有故障时，如果原主节点恢复，是不会回切的。如果当前复制链路发生故障，会再次选择权重高的进行切换

研发的同事反馈，mysql的半同步怎么变异步了？开始觉得不足为奇，超时之后，自然变成异步了。但同步binlog的速度变得正常之后，就会自动变成同步了。但抱着严谨负责的态度，马上去检查了一

下数据库的日志跟半同步的状态。

看了一下从库的错误日志，被图片中所示的sem-sync slave net_flush() reply failed 刷屏。。。。。。，汗了，这又是哪一出？  主库却没有任何日志。

虽然此时的主从同步的延迟时间是正常的，维持在0s的延迟，但此时同步状态却是异步的。

好奇怪呢？

查看一下代码，该Semi-sync slave net_flush() reply failed 信息来自函数

ReplSemiSyncSlave::slaveReply，函数如下

 该错误发生的条件就是执行net_flush(net)函数，没有收到正常的返回，报错了，所以有上面的错误发生，该函数的作用是将从库收到的binlog file 跟binlog pos的信息发送给主库。

网络有问题？ 即使网路抖动性的问题，网路恢复之后应该正常才是。

为什么这个错误持续刷屏？ 而主从同步目前是正常的，只是由半同步变成了异步。

 当我将slave重启之后，错误信息也很快就出现。

因为该函数是向主库发送同步binlog的确认信息的，也就是ack信息，难道是主库的ack的接收线程出了问题？ 而主库没有任何的报错信息 。

关键时刻，自己搞不定的时候，尝试找帮手。我将错误信息，发给oracle公司的mysql开发者宋老师，宋老师是负责replication模块的开发者，对replication相当熟悉，说我可能遇上一个mysql的Bug，让我查看一下Bug 79865 .   在此，非常感谢宋老师的热情的无偿援助。

  bug 详情链接： http://bugs.mysql.com/bug.php?id=79865

我们来看看采用了select()多路复用io模型的ack_reciver 线程的代码：

bug的关键点是因为 ret= select(max_fd+1, &fds, NULL, NULL, &tv)  select()函数的入参max_fd+1有1024的限制，且这个限制无法通过修改nproc来突破？

（ulimit -n 命令可以修改nproc参数）。

貌似所有的疑问都揭开，但请继续。

 作者采用的环境是5.7.15,同时，作者采用的 *** 作系统是centOS 7,  根据上面http://bugs.mysql.com/bug.php?id=79865 后半部分，Meiji Kimura 的描述信息，该bug在centos 6上复现了, 而在centOS7上没有复现。而作者正是采用了centos 7.

MYSQL没有TRIGGER回滚 create trigger update_exceed BEFORE INSERT on A

for each row

begin

select count(*) into @ee from A where UserID=new.UserID

if @ee>=5 then

insert into A(id) values(0)

end if

end

加粗部分,就是拦截部分。由于MYSQL在触发器内不允许对自身的修改，所以会产生一个1442的错误,插入失败。

---