MySQL 5.7.19 主从复制实现与调优
来源:互联网 发布:u盘安装ubuntu黑屏 编辑:程序博客网 时间:2024/04/30 18:23
一、引言
MySQL 支持单向、异步复制,复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新,然后封锁并等待主服务器通知新的更新。
请注意当你进行复制时,所有对复制中的表的更新必须在主服务器上进行。否则,你必须要小心,以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。
单向复制有利于健壮性、速度和系统管理:
1. 主服务器/从服务器设置增加了健壮性。主服务器出现问题时,你可以切换到从服务器作为备份
2. 通过在主服务器和从服务器之间切分处理客户查询的负荷,可以得到更好的客户响应时间。SELECT 查询可以发送到从服务器以降低主服务器的查询处理负荷。但修改数据的语句仍然应发送到主服务器,以便主服务器和从服务器保持同步。如果非更新查询为主,该负载均衡策略很有效,但一般是更新查询。
3. 使用复制的另一个好处是可以使用一个从服务器执行备份,而不会干扰主服务器。在备份过程中主服务器可以继续处理更新。
MySQL 提供了数据库的同步功能,这对我们实现数据库的冗灾、备份、恢复、负载均衡等都是有极大帮助的。
二、mysql主从复制配置
1.基础环境
master:
操作系统:Red Hat Enterprise Linux Server release 6.5 (Santiago)
hoatname:server2
ip:172.25.20.2
mysql 5.7.19
slave:
操作系统:Red Hat Enterprise Linux Server release 6.5 (Santiago)
hoatname:server3
ip:172.25.20.3
mysql 5.7.19
[root@server2 mysql]# rpm -qa | grep mysqlmysql-5.1.71-1.el6.x86_64mysql-server-5.1.71-1.el6.x86_64mysql-libs-5.1.71-1.el6.x86_64[root@server2 mysql]# yum remove mysql-5.1.71-1.el6.x86_64 mysql-server-5.1.71-1.el6.x86_64 mysql-libs-5.1.71-1.el6.x86_64 ##删除旧版本的mysql[root@server2 ~]# rm -rf /var/lib/mysql/ ##删除旧的数据库目录,否则会冲突
2.下载mysql5.7.19
官网下载:
https://www.mysql.com/
官网下载地址:
https://dev.mysql.com/get/Downloads/MySQL-5.7/mysql-5.7.19-1.el6.x86_64.rpm-bundle.tar
3.安装配置
[root@server2 my_mysql]# lsmysql-5.7.19-1.el6.x86_64.rpm-bundle.tar[root@server2 my_mysql]# tar -xf mysql-5.7.19-1.el6.x86_64.rpm-bundle.tar[root@server2 my_mysql]# yum install -y mysql-community-client-5.7.19-1.el6.x86_64.rpm mysql-community-common-5.7.19-1.el6.x86_64.rpm mysql-community-libs-5.7.19-1.el6.x86_64.rpm mysql-community-libs-compat-5.7.19-1.el6.x86_64.rpm mysql-community-server-5.7.19-1.el6.x86_64.rpm
server3 上也需要同样安装
##master(server2)配置[root@server2 ~]# vim /etc/my.cnf[mysqld]datadir=/var/lib/mysqlsocket=/var/lib/mysql/mysql.socksymbolic-links=0server-id=1log-bin=mysql-binbinlog-do-db=testbinlog-ignore-db=mysql[root@server2 ~]# /etc/init.d/mysqld startInitializing MySQL database: [ OK ]Starting mysqld: [ OK ]##初始化后生成的初始密码在 /var/log/mysqld.log 里,如下 qpNtt:l*v3kR 就是我的密码2017-09-28T12:12:13.019482Z 1 [Note] A temporary password is generated for root@localhost: qpNtt:l*v3kR[root@server2 ~]# mysql -pEnter password: ##使用刚才的密码登陆mysql> alter user root@localhost identified by '1234+ASdf'; ##修改密码,否则不允许对数据库操作,密码有强壮度检测Query OK, 0 rows affected (0.02 sec)mysql> grant replication slave on *.* to repl@'172.25.20.%' identified by '1234+asDF'; ##创建了一个用户名为 repl 的用户,密码为 1234+asDF , 允许在 172.25.20 这个网段上的 Slave 登录。Query OK, 0 rows affected, 1 warning (0.00 sec)mysql> show master status;+------------------+----------+--------------+------------------+-------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+------------------+----------+--------------+------------------+-------------------+| mysql-bin.000002 | 691 | test | mysql | |+------------------+----------+--------------+------------------+-------------------+1 row in set (0.00 sec)
##slave(server3)配置[root@server3 ~]# vim /etc/my.cnfserver-id=2[root@server3 ~]# /etc/init.d/mysqld start[root@server3 mysql]# mysql -pEnter password: mysql> alter user root@localhost identified by '1234+ASdf';mysql> change master to master_host='172.25.20.2', master_user='repl', master_password='1234+asDF', master_log_file='mysql-bin.000002', master_log_pos=691;mysql> start slave;mysql> show slave status\G;*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 172.25.20.2 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000002 Read_Master_Log_Pos: 691 Relay_Log_File: server3-relay-bin.000002 Relay_Log_Pos: 320 Relay_Master_Log_File: mysql-bin.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yes
mysql主从复制配置成功
三、基于GTID的主从复制
1.GTID简介
MySQL 5.6 的新特性之一,是加入了全局事务 ID (GTID) 来强化数据库的主备一致性,故障恢复,以及容错能力。
- 什么是GTID?
官方文档:http://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html
在这篇文档里,全局事务 ID 的官方定义是:GTID = source_id:transaction_id
MySQL 5.6 中,每一个 GTID 代表一个数据库事务。在上面的定义中,source_id 表示执行事务的主库 uuid(server_uuid),transaction_id 是一个从 1 开始的自增计数,表示在这个主库上执行的第 n 个事务。MySQL 会保证事务与 GTID 之间的 1 : 1 映射。
在首次启动时 MySQL 会自动生成一个 server_uuid,并且保存到 auto.cnf 文件 —— 这个文件目前存在的唯一目的就是保存 server_uuid。在 MySQL 再次启动时会读取 auto.cnf 文件,继续使用上次生成的 server_uuid。
2.基于GTID的主从复制配置
###master(server2)[root@server2 ~]# vim /etc/my.cnfsymbolic-links=0server-id=1log-bin=mysql-binbinlog-do-db=testbinlog-ignore-db=mysqlgtid_mode=ONenforce-gtid-consistency=true[root@server2 ~]# /etc/init.d/mysqld restart[root@server2 ~]# mysql -pEnter password: mysql> show master status;+------------------+----------+--------------+------------------+-------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+------------------+----------+--------------+------------------+-------------------+| mysql-bin.000003 | 154 | test | mysql | |+------------------+----------+--------------+------------------+-------------------+1 row in set (0.00 sec)
###slave(server3)[root@server3 mysql]# vim /etc/my.cnfsymbolic-links=0server-id=2gtid_mode=ONenforce-gtid-consistency=truelog-error=/var/log/mysqld.logpid-file=/var/run/mysqld/mysqld.pid[root@server3 mysql]# /etc/init.d/mysqld restart[root@server3 mysql]# mysql -pEnter password: mysql> stop slave;Query OK, 0 rows affected (0.01 sec)mysql> change master to master_host='172.25.20.2', master_user='repl', master_password='1234+asDF', master_log_file='mysql-bin.000003', master_log_pos=154;mysql> start slave;Query OK, 0 rows affected (0.01 sec)mysql> show slave status\G;*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 172.25.20.2 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000003 Read_Master_Log_Pos: 154 Relay_Log_File: server3-relay-bin.000002 Relay_Log_Pos: 320 Relay_Master_Log_File: mysql-bin.000003 Slave_IO_Running: Yes Slave_SQL_Running: Yes
已经配置成功,下面进行检测
###----------slave----------mysql> select * from mysql.gtid_executed;Empty set (0.00 sec)###----------master--------------mysql> create database test;Query OK, 1 row affected (0.01 sec)mysql> use test;Database changedmysql> create table usertb ( -> username varchar(20) not null, -> password varchar(20) not null);Query OK, 0 rows affected (0.08 sec)mysql> insert into usertb values ('user1','111');Query OK, 1 row affected (0.04 sec)mysql> select * from usertb;+----------+----------+| username | password |+----------+----------+| user1 | 111 |+----------+----------+1 row in set (0.00 sec)###----------slave----------mysql> select * from test.usertb;+----------+----------+| username | password |+----------+----------+| user1 | 111 |+----------+----------+1 row in set (0.00 sec)mysql> select * from mysql.gtid_executed;+--------------------------------------+----------------+--------------+| source_uuid | interval_start | interval_end |+--------------------------------------+----------------+--------------+| 42989d0d-a446-11e7-8d8d-525400140b3d | 1 | 1 || 42989d0d-a446-11e7-8d8d-525400140b3d | 2 | 2 || 42989d0d-a446-11e7-8d8d-525400140b3d | 3 | 3 |+--------------------------------------+----------------+--------------+3 rows in set (0.00 sec)mysql> show variables like "autocommit";+---------------+-------+| Variable_name | Value |+---------------+-------+| autocommit | ON |+---------------+-------+1 row in set (0.00 sec)
可见,当master更新数据时,slave的transaction_id 增加了(因为我在master上执行了三个写入动作:创建database,创建table,往table里插入数据,所以可以看到gtid_executed这里有三条记录)
我们从binlog里面可以看到,我们的写操作都被记录到了binlog里面:
[root@server2 ~]# mysqlbinlog /var/lib/mysql/mysql-bin.000003# at 219#170928 20:44:34 server id 1 end_log_pos 313 CRC32 0x27e0abe9 Query thread_id=4 exec_time=0 error_code=0SET TIMESTAMP=1506602674/*!*/;SET @@session.pseudo_thread_id=4/*!*/;SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;SET @@session.sql_mode=1436549152/*!*/;SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;/*!\C utf8 *//*!*/;SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;SET @@session.lc_time_names=0/*!*/;SET @@session.collation_database=DEFAULT/*!*/;create database test/*!*/;# at 313#170928 20:45:08 server id 1 end_log_pos 378 CRC32 0xb8019e5d GTID last_committed=1 sequence_number=2 rbr_only=noSET @@SESSION.GTID_NEXT= '42989d0d-a446-11e7-8d8d-525400140b3d:2'/*!*/;# at 378#170928 20:45:08 server id 1 end_log_pos 535 CRC32 0xc02e87d2 Query thread_id=4 exec_time=1 error_code=0use `test`/*!*/;SET TIMESTAMP=1506602708/*!*/;create table usertb (username varchar(20) not null,password varchar(20) not null)/*!*/;# at 535#170928 20:45:18 server id 1 end_log_pos 600 CRC32 0xe1d28746 GTID last_committed=2 sequence_number=3 rbr_only=yes/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;SET @@SESSION.GTID_NEXT= '42989d0d-a446-11e7-8d8d-525400140b3d:3'/*!*/;# at 600#170928 20:45:18 server id 1 end_log_pos 672 CRC32 0x89b246c7 Query thread_id=4 exec_time=0 error_code=0SET TIMESTAMP=1506602718/*!*/;BEGIN/*!*/;# at 672#170928 20:45:18 server id 1 end_log_pos 726 CRC32 0x05c762c2 Table_map: `test`.`usertb` mapped to number 219# at 726#170928 20:45:18 server id 1 end_log_pos 772 CRC32 0xdb9c0b5d Write_rows: table id 219 flags: STMT_END_FBINLOG '3u7MWRMBAAAANgAAANYCAAAAANsAAAAAAAEABHRlc3QABnVzZXJ0YgACDw8EFAAUAADCYscF3u7MWR4BAAAALgAAAAQDAAAAANsAAAAAAAEAAgAC//wFdXNlcjEDMTExXQuc2w=='/*!*/;# at 772#170928 20:45:18 server id 1 end_log_pos 803 CRC32 0x9a239b16 Xid = 41COMMIT/*!*/;SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;DELIMITER ;# End of log file/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
四、并行复制
1.MySQL 5.7并行复制时代
MySQL的复制延迟是一直被诟病的问题之一,MySQL 5.7版本已经支持“真正”的并行复制功能,官方称之为enhanced multi-threaded slave(简称MTS),因此复制延迟问题已经得到了极大的改进。总之,好消息是:5.7版本后,复制延迟问题得到了极大的改进。
MySQL 5.7才可称为真正的并行复制,这其中最为主要的原因就是slave服务器的回放与主机是一致的即master服务器上是怎么并行执行的slave上就怎样进行并行回放。不再有库的并行复制限制,对于二进制日志格式也无特殊的要求(基于库的并行复制也没有要求)。
支持并行复制的GTID
如何知道事务是否在一组中,又是一个问题,因为原版的MySQL并没有提供这样的信息。在MySQL 5.7版本中,其设计方式是将组提交的信息存放在GTID中。那么如果用户没有开启GTID功能,即将参数gtid_mode设置为OFF呢?故MySQL 5.7又引入了称之为Anonymous_Gtid的二进制日志event类型,如:
mysql> SHOW BINLOG EVENTS in 'mysql-bin.000002';+------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------+| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |+------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------+| mysql-bin.000002 | 4 | Format_desc | 1 | 123 | Server ver: 5.7.19-log, Binlog ver: 4 || mysql-bin.000002 | 123 | Previous_gtids | 1 | 154 | || mysql-bin.000002 | 154 | Anonymous_Gtid | 1 | 219 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' || mysql-bin.000002 | 219 | Query | 1 | 398 | ALTER USER 'root'@'localhost' IDENTIFIED WITH 'mysql_native_password' AS '*1DD868CDB87D0B341D89881945E591C1DF147EF2' || mysql-bin.000002 | 398 | Anonymous_Gtid | 1 | 463 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' || mysql-bin.000002 | 463 | Query | 1 | 691 | GRANT REPLICATION SLAVE ON *.* TO 'repl'@'172.25.20.%' IDENTIFIED WITH 'mysql_native_password' AS '*F7BC302DD8EAE9DC4B6EBD2C1A1FBA0E9F63C536' || mysql-bin.000002 | 691 | Stop | 1 | 714 |
这意味着在MySQL 5.7版本中即使不开启GTID,每个事务开始前也是会存在一个Anonymous_Gtid,而这GTID中就存在着组提交的信息。
3.并行复制配置
###slave[root@server3 ~]# vim /etc/my.cnfsymbolic-links=0server-id=2gtid_mode=ONenforce-gtid-consistency=trueslave-parallel-type=LOGICAL_CLOCKslave-parallel-workers=16master_info_repository=TABLErelay_log_info_repository=TABLErelay_log_recovery=ONlog-error=/var/log/mysqld.logpid-file=/var/run/mysqld/mysqld.pid[root@server3 ~]# /etc/init.d/mysqld restart[root@server3 ~]# mysql -pmysql> show slave status\G;mysql> show processlist;
配置并行复制之前
配置并行复制之后
可以看到开了16个线程,具体测试需要压测,这里不演示了。
五、MySQL半同步复制
1.理解MySQL半同步复制
从MySQL5.5开始,MySQL以插件的形式支持半同步复制。如何理解半同步呢?首先我们来看看异步,全同步的概念
- 异步复制(Asynchronous replication)
- MySQL默认的复制即是异步的,主库在执行完客户端提交的事务后会立即将结果返给给客户端,并不关心从库是否已经接收并处理,这样就会有一个问题,主如果crash掉了,此时主上已经提交的事务可能并没有传到从上,如果此时,强行将从提升为主,可能导致新主上的数据不完整。
- 全同步复制(Fully synchronous replication)
- 指当主库执行完一个事务,所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回,所以全同步复制的性能必然会收到严重的影响。
- 半同步复制(Semisynchronous replication)
- 介于异步复制和全同步复制之间,主库在执行完客户端提交的事务后不是立刻返回给客户端,而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制,半同步复制提高了数据的安全性,同时它也造成了一定程度的延迟,这个延迟最少是一个TCP/IP往返的时间。所以,半同步复制最好在低延时的网络中使用。
半同步复制的潜在问题
客户端事务在存储引擎层提交后,在得到从库确认的过程中,主库宕机了,此时,可能的情况有两种
- 事务还没发送到从库上
- 此时,客户端会收到事务提交失败的信息,客户端会重新提交该事务到新的主上,当宕机的主库重新启动后,以从库的身份重新加入到该主从结构中,会发现,该事务在从库中被提交了两次,一次是之前作为主的时候,一次是被新主同步过来的。
- 事务已经发送到从库上
- 此时,从库已经收到并应用了该事务,但是客户端仍然会收到事务提交失败的信息,重新提交该事务到新的主上。
2.MySQL半同步复制安装部署
1).加载插件
需要加载/usr/lib64/mysql/plugin/ 下的 semisync_master.so 和 semisync_slave.so 两个插件
主:mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';mysql> show plugins;从:mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';mysql> show plugins;
2).查看插件是否加载成功
有两种方式
- mysql> show plugins;
- mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE ‘%semi%’;
3).启动半同步复制
在安装完插件后,半同步复制默认是关闭的,这时需设置参数来开启半同步
主:mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;从:mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1;
4).重启从上的IO线程
mysql> STOP SLAVE IO_THREAD;
mysql> START SLAVE IO_THREAD;
如果没有重启,则默认还是异步复制,重启后,slave会在master上注册为半同步复制的slave角色。
5).查看半同步是否在运行
主:mysql> show status like 'Rpl_semi_sync_master_status';从:mysql> show status like 'Rpl_semi_sync_slave_status';
这两个变量常用来监控主从是否运行在半同步复制模式下。
6).事实上,半同步复制并不是严格意义上的半同步复制
当半同步复制发生超时时(由rpl_semi_sync_master_timeout参数控制,单位是毫秒,默认为10000,即10s),会暂时关闭半同步复制,转而使用异步复制。当master dump线程发送完一个事务的所有事件之后,如果在rpl_semi_sync_master_timeout内,收到了从库的响应,则主从又重新恢复为半同步复制。
下面我们来验证一下
####server2mysql> show status like '%Rpl_semi_sync%';+--------------------------------------------+-------+| Variable_name | Value |+--------------------------------------------+-------+| Rpl_semi_sync_master_clients | 1 || 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 | ON || 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 |+--------------------------------------------+-------+14 rows in set (0.00 sec)mysql> select * from test.usertb;+----------+----------+| username | password |+----------+----------+| user1 | 111 || user2 | 222 |+----------+----------+2 rows in set (0.00 sec)mysql> insert into test.usertb values ('user3','333');Query OK, 1 row affected (0.01 sec)mysql> show status like '%Rpl_semi_sync%';+--------------------------------------------+-------+| Variable_name | Value |+--------------------------------------------+-------+| Rpl_semi_sync_master_clients | 1 || Rpl_semi_sync_master_net_avg_wait_time | 0 || Rpl_semi_sync_master_net_wait_time | 0 || Rpl_semi_sync_master_net_waits | 1 || 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 | 312 || Rpl_semi_sync_master_tx_wait_time | 312 || Rpl_semi_sync_master_tx_waits | 1 || Rpl_semi_sync_master_wait_pos_backtraverse | 0 || Rpl_semi_sync_master_wait_sessions | 0 || Rpl_semi_sync_master_yes_tx | 1 |+--------------------------------------------+-------+14 rows in set (0.00 sec)####server3mysql> select * from test.usertb;+----------+----------+| username | password |+----------+----------+| user1 | 111 || user2 | 222 || user3 | 333 |+----------+----------+3 rows in set (0.00 sec)mysql> STOP SLAVE IO_THREAD;####server2mysql> insert into test.usertb values ('user4','444');Query OK, 1 row affected (0.02 sec)mysql> show status like '%Rpl_semi_sync%';+--------------------------------------------+-------+| Variable_name | Value |+--------------------------------------------+-------+| Rpl_semi_sync_master_clients | 1 || Rpl_semi_sync_master_net_avg_wait_time | 0 || Rpl_semi_sync_master_net_wait_time | 0 || Rpl_semi_sync_master_net_waits | 2 || 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 | 412 || Rpl_semi_sync_master_tx_wait_time | 825 || Rpl_semi_sync_master_tx_waits | 2 || Rpl_semi_sync_master_wait_pos_backtraverse | 0 || Rpl_semi_sync_master_wait_sessions | 0 || Rpl_semi_sync_master_yes_tx | 2 |+--------------------------------------------+-------+14 rows in set (0.01 sec)####server3mysql> show status like '%Rpl_semi_sync%';+----------------------------+-------+| Variable_name | Value |+----------------------------+-------+| Rpl_semi_sync_slave_status | OFF |+----------------------------+-------+1 row in set (0.00 sec)mysql> select * from test.usertb;+----------+----------+| username | password |+----------+----------+| user1 | 111 || user2 | 222 || user3 | 333 |+----------+----------+3 rows in set (0.00 sec)mysql> START SLAVE IO_THREAD;mysql> select * from test.usertb;+----------+----------+| username | password |+----------+----------+| user1 | 111 || user2 | 222 || user3 | 333 || user4 | 444 |+----------+----------+4 rows in set (0.00 sec)mysql> show status like '%Rpl_semi_sync%';+----------------------------+-------+| Variable_name | Value |+----------------------------+-------+| Rpl_semi_sync_slave_status | ON |+----------------------------+-------+1 row in set (0.00 sec)mysql> select * from test.usertb;+----------+----------+| username | password |+----------+----------+| user1 | 111 || user2 | 222 || user3 | 333 || user4 | 444 |+----------+----------+4 rows in set (0.00 sec)mysql> show status like '%Rpl_semi_sync%';+----------------------------+-------+| Variable_name | Value |+----------------------------+-------+| Rpl_semi_sync_slave_status | ON |+----------------------------+-------+1 row in set (0.00 sec)mysql> stop slave IO_thread;Query OK, 0 rows affected (0.01 sec)mysql> show status like '%Rpl_semi_sync%';+----------------------------+-------+| Variable_name | Value |+----------------------------+-------+| Rpl_semi_sync_slave_status | OFF |+----------------------------+-------+1 row in set (0.00 sec)####server2mysql> insert into test.usertb values ('user5','555');Query OK, 1 row affected (10.01 sec)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 | 2 || Rpl_semi_sync_master_no_times | 1 || Rpl_semi_sync_master_no_tx | 1 || Rpl_semi_sync_master_status | OFF || Rpl_semi_sync_master_timefunc_failures | 0 || Rpl_semi_sync_master_tx_avg_wait_time | 412 || Rpl_semi_sync_master_tx_wait_time | 825 || Rpl_semi_sync_master_tx_waits | 2 || Rpl_semi_sync_master_wait_pos_backtraverse | 0 || Rpl_semi_sync_master_wait_sessions | 0 || Rpl_semi_sync_master_yes_tx | 2 |+--------------------------------------------+-------+14 rows in set (0.00 sec)####server3mysql> show status like '%Rpl_semi_sync%';+----------------------------+-------+| Variable_name | Value |+----------------------------+-------+| Rpl_semi_sync_slave_status | OFF |+----------------------------+-------+1 row in set (0.00 sec)mysql> select * from test.usertb;+----------+----------+| username | password |+----------+----------+| user1 | 111 || user2 | 222 || user3 | 333 || user4 | 444 |+----------+----------+4 rows in set (0.00 sec)mysql> start slave IO_thread;Query OK, 0 rows affected (0.00 sec)mysql> show status like '%Rpl_semi_sync%';+----------------------------+-------+| Variable_name | Value |+----------------------------+-------+| Rpl_semi_sync_slave_status | ON |+----------------------------+-------+1 row in set (0.00 sec)mysql> select * from test.usertb;+----------+----------+| username | password |+----------+----------+| user1 | 111 || user2 | 222 || user3 | 333 || user4 | 444 || user5 | 555 |+----------+----------+5 rows in set (0.00 sec)
当把从机上的 IO_THREAD 停掉之后,10000ms延时超时之后,就自动降级为异步复制,从机上的 IO_THREAD 重新开启之后,有自动恢复为半同步复制。
- MySQL 5.7.19 主从复制实现与调优
- MySQL主从复制配置与实现
- MySQL主从复制配置与实现
- MySQL主从复制实现
- mysql实现主从复制
- mysql实现主从复制
- MySQL实现主从复制
- mysql实现主从复制
- mysql实现主从复制
- mysql实现主从复制
- Mysql实现主从复制
- mysql实现主从复制
- mysql实现主从复制
- mysql 实现主从复制
- 【mysql】mysql实现主从复制
- MySQL 5.7主从复制
- mysql主从复制的实现
- mysql数据库实现主从复制
- Python 文件读写,中文编码
- 排序
- python .so共享文件没有找到
- java GUI AWT 布局管理器
- 【数据结构】第三章 栈和队列
- MySQL 5.7.19 主从复制实现与调优
- 学习php
- Matlab项目迁移到C++记忆录
- Openfiler2.99 图文教程1--搭建ISCSI网络存储
- 使用SecureCRT来上传和下载文件
- HDU 1863 (图论基础prim算法)
- LeetCode 19. Remove Nth Node From End of List
- 常见算法基础题思路简析(五)-队列和栈篇
- 数据挖掘类的国际顶尖会议