介绍
先了解一下mysql的主从复制是什么回事,我们都知道,mysql主从复制是基于binlog的复制方式,而mysql默认的主从复制方式,其实是异步复制.
主库实际上并不关心从库是否把数据拉完没有,也不关心从库有没有把数据写进硬盘入库,反正数据丢过去,让从库自己慢慢跑,而实际上这也并不影响主库任何使用的情况.
细心的人就会发现,这种情况下,假如主库临时挂了,binlog还没传输完毕,即使是集群也不能保证说这挂了之后的数据一致性,因为你不能排除别人在主库是正常提交的,而从库没有数据的情况.
然后在某个位面的时间上,就有人提出同步复制的概念,意思就是说,只要从库没写入,主库就不返回完成,这个时候即使主库挂了,这也只是一个未完成的事务,从库也不会记录,能保证数据一致性.
看上去,数据一致性是解决了,但是呢,每个事务的延时就增大了,如果是大事务的话,就更惨,这得看网络带宽能不能顶得住,不然延时更低,性能更差.
最后,在mysql5.5之后,半同步就提出来了,意思就是说,每个事务的复制,至少保证一个从库已经收到了binlog,主库才返回事务完成,但不需要理会从库是否写入硬盘.
这样做虽然延时还是有,但是比起完全的同步方式还是好太多,对于数据一致性要求高的情况,牺牲性能来换取一定的价值,是在所难免的.
光看文字难免有些虚,可以看看下面的图片来大致了解一下,
大家留意上面的数字,
第一部,客户端提交sql语句,
第二部,提交给存储引擎解析并处理数据修改,
第三部,事务在主库处理完毕,处于待完成状态,等待最终完成,
第四部,同时提交给各从库,等待完成,
第五部,从库返回状态给主库,标记已完成,半同步只需要一个从库返回就可以，其他会转成异步
第六部,返回客户端,整个事务已完成.
看上去还是比较不错,主从的数据一致性得到很大的提高,但是延时也不含糊,就是牺牲性能来提高一致性的问题了.
不过我还是得负责任的讲句,在极端的情况下,还是可能会丢一些数据的,所以定期做主从数据校验还是有必要的,例如使用PT工具什么的,至于为什么,这个不仿让大家思考一下,而对于大事务来说,半同步也是比较无力的情况,性能损耗较大.
安装使用
下面来看看如何安装使用半同步,大部分mysql本身并没有预装半同步的组件,需要另外安装,但是一般mysql的包里面会自带so文件,所以只要手动加载一下就可以用了.
先检查下有没有装
#查找是否有semisync字母,有就是装了,没有就是没装,默认是不安装的,所以请看下一步 mysql> show plugins; . . .
然后我们开始准备安装的事情:
#查找mysql插件目录位置 mysql> show variables like 'plugin_dir'; +---------------+------------------------------------+ | Variable_name | Value | +---------------+------------------------------------+ | plugin_dir | /usr/local/mysql/lib/mysql/plugin/ | +---------------+------------------------------------+ 1 row in set (0.00 sec)
去看一下相关文件夹:
#查看目录文件是否存在 [root@pingtest1 ~]# ll /usr/local/mysql/lib/mysql/plugin/ 总用量 25328 -rwxr-xr-x 1 root root 16916 3月 4 01:18 adt_null.so -rwxr-xr-x 1 root root 183009 3月 4 01:18 audit_log.so -rwxr-xr-x 1 root root 44095 3月 4 01:18 auth_pam_compat.so -rwxr-xr-x 1 root root 45929 3月 4 01:18 auth_pam.so -rwxr-xr-x 1 root root 27406 3月 4 01:18 auth.so -rwxr-xr-x 1 root root 13607 3月 4 01:18 auth_socket.so -rwxr-xr-x 1 root root 26229 3月 4 01:18 auth_test_plugin.so -rw-r--r-- 1 root root 227 3月 3 21:27 daemon_example.ini drwxr-xr-x 2 root root 4096 3月 4 01:23 debug -rwxr-xr-x 1 root root 4702357 3月 4 01:20 dialog.so -rwxr-xr-x 1 root root 2212305 3月 4 01:18 handlersocket.so -rwxr-xr-x 1 root root 14950125 3月 4 01:22 ha_tokudb.so -rwxr-xr-x 1 root root 834597 3月 4 01:18 innodb_engine.so -rwxr-xr-x 1 root root 39169 3月 4 01:18 libdaemon_example.so -rwxr-xr-x 1 root root 27048 3月 4 01:18 libfnv1a_udf.so -rwxr-xr-x 1 root root 27089 3月 4 01:18 libfnv_udf.so -rwxr-xr-x 1 root root 779519 3月 4 01:18 libmemcached.so -rwxr-xr-x 1 root root 28683 3月 4 01:18 libmurmur_udf.so -rwxr-xr-x 1 root root 17898 3月 4 01:18 mypluglib.so -rwxr-xr-x 1 root root 12224 3月 4 01:18 mysql_no_login.so -rwxr-xr-x 1 root root 18574 3月 4 01:18 qa_auth_client.so -rwxr-xr-x 1 root root 27059 3月 4 01:18 qa_auth_interface.so -rwxr-xr-x 1 root root 13877 3月 4 01:18 qa_auth_server.so -rwxr-xr-x 1 root root 395960 3月 4 01:18 query_response_time.so -rwxr-xr-x 1 root root 56417 3月 4 01:18 scalability_metrics.so -rwxr-xr-x 1 root root 537609 3月 4 01:18 semisync_master.so -rwxr-xr-x 1 root root 289069 3月 4 01:18 semisync_slave.so -rwxr-xr-x 1 root root 357058 3月 4 01:18 tokudb_backup.so -rwxr-xr-x 1 root root 188402 3月 4 01:18 validate_password.so
看到下面两个,就是半同步的组件了,一个是主库组件,一个是从库组件,你可以两个都装上或者只装一个.
semisync_master.so semisync_slave.so
下面开始正式安装:
#在主库上执行 mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so'; mysql> show plugins; #看到下面这个就证明成功了 rpl_semi_sync_master | ACTIVE | REPLICATION | semisync_master.so | GPL
从库当然也要做
#然后在从库执行 mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so'; mysql> show plugins; #看到下面这个就证明成功了 rpl_semi_sync_slave | ACTIVE | REPLICATION | semisync_slave.so | GPL
安装完了,就开始准备启动了,
主库很简单,只要设置一下半同步启动就可以了.
mysql> set global rpl_semi_sync_master_enabled = on;
当然,你也可以写到配置文件,不过写到配置文件要重启才生效,而且还要重新加载组件,所以这就没意思了.
然后到从库,slave要重启动IO线程来生效，否则还是异步的方式复制数据。
mysql> set global rpl_semi_sync_slave_enabled = on; mysql> stop slave IO_THREAD; mysql> start slave IO_THREAD;
同样你也能写到配置文件,我就不多说了,反正这就启动完毕了.
下面来验证一下是否成功,以下是主库的信息,因为从库很多信息是没有的.
mysql> show status like '%Rpl_semi_sync%'; +--------------------------------------------+---------+ | Variable_name | Value | +--------------------------------------------+---------+ | Rpl_semi_sync_master_clients | 1 | | Rpl_semi_sync_master_net_avg_wait_time | 746 | | Rpl_semi_sync_master_net_wait_time | 3788497 | | Rpl_semi_sync_master_net_waits | 5077 | | Rpl_semi_sync_master_no_times | 0 | | Rpl_semi_sync_master_no_tx | 0 | | Rpl_semi_sync_master_status | ON | | Rpl_semi_sync_master_timefunc_failures | 0 | | Rpl_semi_sync_master_tx_avg_wait_time | 614 | | Rpl_semi_sync_master_tx_wait_time | 2797020 | | Rpl_semi_sync_master_tx_waits | 4552 | | Rpl_semi_sync_master_wait_pos_backtraverse | 0 | | Rpl_semi_sync_master_wait_sessions | 0 | | Rpl_semi_sync_master_yes_tx | 5077 | | Rpl_semi_sync_slave_status | OFF | +--------------------------------------------+---------+ 15 rows in set (0.00 sec)
解释几个重要的值。
Rpl_semi_sync_master_status: 是否启用了半同步(有时候可能网络超时导致切换成异步)。
Rpl_semi_sync_master_clients: 半同步模式下Slave一共有多少个。
Rpl_semi_sync_master_no_tx: 往slave发送失败的事务数量(最好不要有)。
Rpl_semi_sync_master_yes_tx: 往slave发送成功的事务数量。
看完上面的解析,大概你也知道我这个状态是正常的了.其他延时类别的,大家得看实际情况.
来看看我们能设置些什么关于半同步的参数
mysql> show variables like '%Rpl%'; +------------------------------------+----------+ | Variable_name | Value | +------------------------------------+----------+ | rpl_semi_sync_master_enabled | ON | | rpl_semi_sync_master_timeout | 10000 | | rpl_semi_sync_master_trace_level | 32 | | rpl_semi_sync_master_wait_no_slave | ON | | rpl_semi_sync_slave_enabled | OFF | | rpl_semi_sync_slave_trace_level | 32 | | rpl_stop_slave_timeout | 31536000 | +------------------------------------+----------+ 7 rows in set (0.00 sec)
也来看看解析:
rpl_semi_sync_master_enabled: 显示是否已开启半同步机制
rpl_semi_sync_master_timeout: Master等待slave响应的时间，单位是毫秒，默认值是10秒，超过这个时间，slave无响应,将自动转换为异步复制,如果探测到从库恢复后,又从新进入半同步状态
rpl_semi_sync_master_trace_level: 监控等级，一共4个等级（1,16,32,64）。
* 1：general 等级，如：记录时间函数失效
* 16：detail 等级，记录更加详细的信息
* 32：net wait等级，记录包含有关网络等待的更多信息
* 64：function等级，记录包含有关function进入和退出的更多信息
rpl_semi_sync_master_wait_no_slave: 是否允许master 每个事物提交后都要等待slave的receipt信号。默认为on ，每一个事务都会等待，如果slave当掉后，当slave追赶上master的日志时，可以自动的切换为半同步方式，如果为off,则slave追赶上后，也不会采用半同步的方式复制了，需要手工配置。
毫无疑问,这些参数都能通过配置文件或直接set来更改,只要你觉得这个适合你的需求,例如一般我们会把响应时间设成1秒.
最后,我们来看看同样的命令在从库会有些什么信息
mysql> show status like '%Rpl_semi_sync%'; +--------------------------------------------+-------+ | Variable_name | Value | +--------------------------------------------+-------+ | Rpl_semi_sync_master_clients | 0 | | Rpl_semi_sync_master_net_avg_wait_time | 0 | | Rpl_semi_sync_master_net_wait_time | 0 | | Rpl_semi_sync_master_net_waits | 0 | | Rpl_semi_sync_master_no_times | 0 | | Rpl_semi_sync_master_no_tx | 0 | | Rpl_semi_sync_master_status | OFF | | Rpl_semi_sync_master_timefunc_failures | 0 | | Rpl_semi_sync_master_tx_avg_wait_time | 0 | | Rpl_semi_sync_master_tx_wait_time | 0 | | Rpl_semi_sync_master_tx_waits | 0 | | Rpl_semi_sync_master_wait_pos_backtraverse | 0 | | Rpl_semi_sync_master_wait_sessions | 0 | | Rpl_semi_sync_master_yes_tx | 0 | | Rpl_semi_sync_slave_status | ON | +--------------------------------------------+-------+ 15 rows in set (0.00 sec)
也正如我刚才说的,很多信息基本上没有,只有最后一行是不一样的,也只是证明从库半同步正常连接中.
再看看这个
mysql> show variables like '%Rpl%'; +------------------------------------+----------+ | Variable_name | Value | +------------------------------------+----------+ | rpl_semi_sync_master_enabled | OFF | | rpl_semi_sync_master_timeout | 10000 | | rpl_semi_sync_master_trace_level | 32 | | rpl_semi_sync_master_wait_no_slave | ON | | rpl_semi_sync_slave_enabled | ON | | rpl_semi_sync_slave_trace_level | 32 | | rpl_stop_slave_timeout | 31536000 | +------------------------------------+----------+ 7 rows in set (0.00 sec)
主要就最后两行:
rpl_semi_sync_slave_enabled: 是否开启了从库半同步
rpl_semi_sync_slave_trace_level: 监控等级,默认也是32
rpl_stop_slave_timeout: 控制stop slave 的执行时间，在重放一个大的事务的时候,突然执行stop slave ,命令 stop slave会执行很久,这个时候可能产生死锁或阻塞,严重影响性能，可以通过这个参数控制stop slave 的执行时间,一般不需要修改.
问题汇总
5.7.3新加了一个半同步参数，至少有N个slave接收到日志，然后返回ack，这个半同步事务才能提交，默认是1。当这个值设置到和从库数量相等的话，则效果会等同于全同步复制。
#例如我有3个从库，我现在要设置两个从库应答才能返回事务提交成功 rpl_semi_sync_master_wait_for_slave_count = 2
5.7新功能，在控制半同步模式下 主库在返回给会话事务成功之前提交事务的方式。旧模式是AFTER_COMMIT，新模式是AFTER_SYNC，默认值：AFTER_SYNC 。master 将每个事务写入binlog ,传递到slave，并且刷新到磁盘。master等待slave 反馈接收到事务并刷新到磁盘。一旦接到slave反馈，master在主库提交事务并且返回结果给会话。 在AFTER_SYNC模式下，所有的客户端在同一时刻查看已经提交的数据。假如发生主库crash，所有在主库上已经提交的事务已经同步到slave并记录到relay log。此时切换到从库，可以保障最小的数据损失。
#显然新模式更好，不过5.7默认就是这个参数，可改可不改 rpl_semi_sync_master_wait_point = AFTER_SYNC
而当半同步复制设置N个slave应答，如果当前Slave小于N,取决于rpl_semi_sync_master_wait_no_slave的设置。
#设成0会立刻变成异步复制。 rpl_semi_sync_master_wait_no_slave = 0 #设成1仍然等待应答，直到超时。 rpl_semi_sync_master_wait_no_slave = 1
超时时间rpl_semi_sync_master_timeout的值，不应该短过应用（例如JDBC）连接池或线程池的超时时间，这样应用可能出现一直等待或者是抛出异常的问题。
#例如某些大数据量的操作，随时都超过5分钟，那么我们就要设大一点 set global rpl_semi_sync_master_timeout = 300000