mysql5.7数据强一致性与高可用(2)

上节简单的介绍了MySQL5.5,5.6,5.7各版本做半同步复制的差异,现在开始做一个实际的操作。业务需求(金融):性能方面可以退而求其次,但是必须做到数据的强一致性与服务的高可用性。如此,正好用上MySQL5.7版本的无损复制。

基础环境:CentOS7.2 MySQL5.7.20
A:172.31.1.51
B:172.31.1.61
基本架构:两台服务器都要安装MySQL+keepalived,做MySQL的双主模型,平时只有一台(A)对外提供服务,另一台(B)做备,当对外提供服务的A宕机或服务不可用时则对外IP自动切换到备B服务器(也是主)上,做到服务的高可用性。

1.使用semisync半同步机制,保证双主数据一致。

A、B上都需执行:
mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so'; --安装 semisync_master.so插件

mysql>install plugin rpl_semi_sync_slave soname 'semisync_slave.so'; --安装 semisync_slave.so插件

然后分别查看:show plugins; 查看模块,模块都已安装。

如此,则证明A,B都可以使用semisync半同步机制了,下面再做相应的配置启用此功能。

双主的配置:

A:
[client]  
default-character-set=utf8

[mysqld]
#数据强一致性
rpl_semi_sync_master_enabled=1
rpl_semi_sync_slave_enabled=1
rpl_semi_sync_master_timeout=6000
#二进制日志的格式
binlog-format=ROW
###启用二进制日志
log-bin=master-bin
###slave 更新是否记录到日志
log-slave-updates=true
###启用gtid类型,否则就是普通的复制架构
gtid-mode=on
###强制GTID的一致性
enforce-gtid-consistency=true
###主服信息记录库=表/文件
master-info-repository=TABLE
###中继日志信息记录库
relay-log-info-repository=TABLE
###同步主库信息
sync-master-info=1
###从服务器的SQL线程数,要复制库数目相同
slave-parallel-workers=2
###校验码
binlog-checksum=CRC32
###主服校验
master-verify-checksum=1
###从服校验
slave-sql-verify-checksum=1
###二进制日志详细记录事件
binlog-rows-query-log_events=1
###提供复制报告端口
report-port=3306
###提供复制报告主机
report-host=172.31.1.51
###主库id
server-id=50
port=3306
##忽略不需要同步的库
binlog-ignore-db = information_schema
binlog-ignore-db = performance_schema
binlog-ignore-db = sys
##保留3天的二进制日志
expire-logs-days=3
#开启慢查询日志
slow_query_log = on
##超出时间设定值的SQL即被记录到慢查询日志
long_query_time = 2
slow_query_log_file = /var/log/mysql/master_slow.log
#优化部分
join_buffer_size = 128M
sort_buffer_size = 16M
read_rnd_buffer_size = 16M
interactive_timeout = 600
wait_timeout = 60
skip-name-resolve
back_log = 200
max_connections = 300
table_open_cache = 1024
max_allowed_packet = 4M
query_cache_size = 128M
innodb_buffer_pool_size = 4096M
innodb_file_per_table = 1
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

#修改字符集
character-set-server=utf8
collation-server=utf8_general_ci

B:

[client]  
default-character-set=utf8

[mysqld]
#数据强一致性
rpl_semi_sync_master_enabled=1
rpl_semi_sync_slave_enabled = 1
rpl_semi_sync_master_timeout=6000
#主从配置
log-bin=slave-bin
sync_binlog=0
binlog_format=row
log-slave-updates=true
gtid-mode=on
enforce-gtid-consistency=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
report-port=3306
port=3306
report-host=172.31.1.61
server-id = 60
expire-logs-days=3
slave-skip-errors=all
binlog-ignore-db = information_schema
binlog-ignore-db = performance_schema
binlog-ignore-db = sys

#优化配置
join_buffer_size = 128M
sort_buffer_size = 16M
read_rnd_buffer_size = 16M
interactive_timeout = 600
wait_timeout = 60
skip-name-resolve
back_log = 200
max_connections = 300
table_open_cache = 1024
max_allowed_packet = 4M
query_cache_size = 128M
innodb_buffer_pool_size = 4096M
innodb_file_per_table = 1
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

#修改字符集
character-set-server=utf8
collation-server=utf8_general_ci

然后在A、B上分别授权给从服务器(A、B互为主从,即双主)
A做主,B做从,A上执行:

主给从授权:
grant  replication  slave,replication  client  on  *.*  to  user1@'172.31.1.61'   identified   by 'xxxxxxxx';

从库执行:
change master to master_host='172.31.1.51',master_user='user1',master_port=3306,master_password='xxxxxxxx',master_auto_position=1;

A做从,B做主,B上执行:

主给从授权:
grant  replication  slave,replication  client  on  *.*  to  user1@'172.31.1.51'   identified   by 'xxxxxxxx';

从库执行:
change master to master_host='172.31.1.61',master_user='user1',master_port=3306,master_password='xxxxxxxx',master_auto_position=1;
2. 怎么确认是同步还是半同步?

至此,重启A、B的MySQL服务,分别执行如下SQL:
A上执行:

mysql5.7数据强一致性与高可用(2)_第1张图片
1.png

B上执行:
mysql5.7数据强一致性与高可用(2)_第2张图片
2.png

依据上面的A、B服务器的my.cnf配置我们可以看出,A、B都已经启用了semisync半同步机制,且都是主服务器。(不必纠结于我的binlog日志号,因为这是环境做好后补发的文档)

3.参数解析:
mysql> show status like "%semi%";
+--------------------------------------------+-------+
| Variable_name                              | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients               | 1     |有多少个Semi-sync的备库
| 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     |一共有几次从Semi-sync跌回普通状态
| Rpl_semi_sync_master_no_tx                 | 0     |库未及时响应的事务数,如果这个值很大就有问题
| Rpl_semi_sync_master_status                | ON    |主库上Semi-sync是否正常开启
| Rpl_semi_sync_master_timefunc_failures     | 0     |时间函数未正常工作的次数
| Rpl_semi_sync_master_tx_avg_wait_time      | 0     |开启Semi-sync,事务返回需要等待的平均时间
| 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     |Semi-sync模式下,成功的事务数
| Rpl_semi_sync_slave_status                 | ON    |备库上Semi-sync是否正常开启
+--------------------------------------------+-------+

rpl_semi_sync_master_timeout=60000

表示主库在某次事务中,如果等待时间超过6秒,则降级为普通模式,不再等待备库。如果主库再次探测到备库恢复了,则会自动再次回到semisync模式。
很好的解释了上篇讲到的如果从库宕机了,那么从库就不会返回ACK给master的解决办法。

rpl_semi_sync_master_wait_point=AFTER_SYNC

这个参数是MySQL5.7新增的,AFTER_SYNC(5.7默认)工作流程:
1、客户端提交一个事务,master将事务写入binlog并刷新到磁盘,发送到slave,master等待slave反馈。
2、slave接收master的binlog,写到本地的relaylog里。发送确认信息给master。
3、当接收到slave反馈,master提交事务并返回结果给客户端。这样就保证了主从数据一致。

4. 再来看A、B都为从库是否正常

A上执行sql如下:

mysql5.7数据强一致性与高可用(2)_第3张图片
3.png

B上执行sql如下:
mysql5.7数据强一致性与高可用(2)_第4张图片
4.png

此处可能会优点混乱,但是仔细看上面A、B服务器的my.cnf的配置就能够看出来是正常的,文档水平有限,请谅解。

至此,我的基于MySQL5.7做的双主数据强一致服务已然完成,下一篇再写高可用。如有不当之处,烦请指导。

你可能感兴趣的:(mysql5.7数据强一致性与高可用(2))