MySQL 5.7.19 主从复制实现与调优_Running_free的博客-CSDN博客_mysql主从热备机制
MySQL 5.7.19 主从复制实现与调优
Running_free
于 2017-09-28 22:10:35 发布
1443
收藏
分类专栏：
linux运维
文章标签：
mysql
主从复制
半同步
异步复制
服务器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Running_free/article/details/78128709
版权
linux运维
专栏收录该内容
84 篇文章
1 订阅
订阅专栏
一、引言
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 mysql
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
[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]# ls
mysql-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/mysql
socket=/var/lib/mysql/mysql.sock
symbolic-links=0
server-id=1
log-bin=mysql-bin
binlog-do-db=test
binlog-ignore-db=mysql
[root@server2 ~]# /etc/init.d/mysqld start
Initializing 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 -p
Enter 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.cnf
server-id=2
[root@server3 ~]# /etc/init.d/mysqld start
[root@server3 mysql]# mysql -p
Enter 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.cnf
symbolic-links=0
server-id=1
log-bin=mysql-bin
binlog-do-db=test
binlog-ignore-db=mysql
gtid_mode=ON
enforce-gtid-consistency=true
[root@server2 ~]# /etc/init.d/mysqld restart
[root@server2 ~]# mysql -p
Enter 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.cnf
symbolic-links=0
server-id=2
gtid_mode=ON
enforce-gtid-consistency=true
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[root@server3 mysql]# /etc/init.d/mysqld restart
[root@server3 mysql]# mysql -p
Enter 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 changed
mysql> 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=0
SET 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=no
SET @@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=0
use `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=0
SET 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_F
BINLOG '
3u7MWRMBAAAANgAAANYCAAAAANsAAAAAAAEABHRlc3QABnVzZXJ0YgACDw8EFAAUAADCYscF
3u7MWR4BAAAALgAAAAQDAAAAANsAAAAAAAEAAgAC//wFdXNlcjEDMTExXQuc2w==
'/*!*/;
# at 772
#170928 20:45:18 server id 1 end_log_pos 803 CRC32 0x9a239b16 Xid = 41
COMMIT/*!*/;
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.cnf
symbolic-links=0
server-id=2
gtid_mode=ON
enforce-gtid-consistency=true
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[root@server3 ~]# /etc/init.d/mysqld restart
[root@server3 ~]# mysql -p
mysql> 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内，收到了从库的响应，则主从又重新恢复为半同步复制。
下面我们来验证一下
####server2
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 | 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)
####server3
mysql> select * from test.usertb;
+----------+----------+
| username | password |
+----------+----------+
| user1 | 111 |
| user2 | 222 |
| user3 | 333 |
+----------+----------+
3 rows in set (0.00 sec)
mysql> STOP SLAVE IO_THREAD;
####server2
mysql> 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)
####server3
mysql> 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)
####server2
mysql> 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)
####server3
mysql> 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 重新开启之后，有自动恢复为半同步复制。
Running_free
关注
关注
点赞
收藏
打赏
评论
MySQL 5.7.19 主从复制实现与调优
MySQL 支持单向、异步复制,复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新,然后封锁并等待主服务器通知新的更新。
复制链接
扫一扫
专栏目录
mysql 主从 双机热备
xiaoxiaoxiaopb的博客
09-09
720
文章目录前言一、主从复制1.什么是主从复制2.主从复制优势3.实现主从复制4.主从复制原理5. 复制模式6. 存在问题7. 参数设置8. 级联复制9. 双机热备总结
前言
Mysql数据库没有增量备份的机制，当数据量太大的时候备份是一个很大的问题。还好mysql数据库提供了一种主从备份的机制，其实就是把主数据库的所有的数据同时写到备份的数据库中。实现mysql数据库的热备份。
&nbs
mysql 性能优化（八）主从复制
CodingAnHour
07-02
157
1、原理及配置
集群在数据库中的一种实现
docker 启动2个mysql 可以自行调整或者自行主机搭建mysql
docker run -p 33006:3306 --name mysql-master -v /Users/demo/tools/mysql-master/conf:/etc/mysql/conf.d -v /Users/demo/tools/mysql-master/logs:/logs -v /Users/demo/tools/mysql-master/data:/var/lib/my
参与评论
您还未登录，请先
登录
后发表或查看评论
MySQL数据库主从复制
最新发布
L2111533547的博客
06-27
301
在实际的生产中，为了解决Mysql的单点故障已经提高MySQL的整体服务性能，一般都会采用==「主从复制」。==比如：在复杂的业务系统中，有一句sql执行后导致锁表，并且这条sql的的执行时间有比较长，那么此sql执行的期间导致服务不可用，这样就会严重影响用户的体验度。主从复制中分为==【主服务器（master）】和【从服务器（slave）】，【主服务器负责写，而从服务器负责读】，Mysql的主从复制的过程是一个【异步的过程】==。这样读写分离的过程能够是整体的服务性能提高，即使写操作时间比较长，也不影响读
mysql主从复制优化_MySQL主从复制性能优化
weixin_29887959的博客
01-19
84
MySQL的主从复制的基本原理是从库连接到主库，主库生成一个主库DUMP线程，该DUMP线程的主要任务是一直挖掘binlog日志，然后发送到从库的IO线程,IO线程接收到日志流后，写入relay log,另一个线程SQL线程,会读取该relay log内容，然后对sql语句进行重放.主库DUMP线程会根据从库传来的文件位置信息去读取binlog文件中的内容，DUMP线程并不是每隔一段时间去读取的，...
MySQL主从搭建和性能优化（一）——MySQL主从搭建、MySQL性能优化（统计总记录数问题、原理分析、索引的分类、最左匹配原则、索引独立原则）、MySQL 查询执行流程
qq_41824825的博客
03-16
1400
MySQL主从搭建和性能优化（一）——MySQL主从搭建、MySQL性能优化（统计总记录数问题、原理分析、索引的分类、最左匹配原则、索引独立原则）、MySQL 查询执行流程
mysql双主热备_MYSQL双机热备、主从热备
weixin_34861702的博客
01-28
216
MYSQL数据库没有增量备份的机制，当数据量太大的时候备份是一个很大的问题。还好mysql数据库提供了一种主从备份的机制，其实就是把主数据库的所有的数据同时写到备份数据库中，实现mysql数据库的热备份。要想实现双机的热备首先要了解主从数据库服务器的版本的需求。要实现热备mysql的版本都要高于3.2，还有一个基本的原则就是作为从数据库的数据库版本可以高于主服务器数据库的版本，但是不可以低于主服务...
mysql主从调优_部署和调优 2.7 mysql主从配置-1
weixin_34329524的博客
02-08
60
MySQL 主从(MySQL Replication)，主要用于 MySQL 的时时备份或者读写分离。在配置之前先做一下准备工作，配置两台 mysql 服务器，如果你的机器不能同时跑两台 Linux虚拟机，那可以考虑在同一个机器上跑两个 mysql 服务。MySQL 主从原理非常简单，总结一下：每个从仅可以设置一个主。主在执行 sql 之后，记录二进制 log 文件(bin-log)。从连接主，并...
mysql 5.7.19主从复制_mysql5.7.19版本的主从复制问题分享
weixin_34258386的博客
01-19
39
今天学习构建mysql 5.7.19版本的MySQL的主从复制碰到了一些坑，特定分享下：mysql的主从服务器是通过克隆虚拟机完成，导致uuids一样，需要修改auto.cnf文件在slave上想通过在/etc/my.cnf里添加连接master的配置，总是导致启动mysqld服务失败，看错误日志，说不支持的选项。原因是5.7.19里已经淘汰了在配置文件里加这种配置的方法了。下面是部分笔记，特分享...
mysql 5.7.19主从复制_MySQL5.7.19 - 主从复制 - 日志点
weixin_33705384的博客
01-26
51
【第一部分】 Master - Lebron - 192.168.1.1221. 开放3306端口[root@lebron sysconfig]# vim /etc/sysconfig/iptables# Firewall configuration written by system-config-firewall# Manual customization of this file is no...
mysql 主从提高性能_【MySQL主从复制】提高服务性能，看看叭？
weixin_42501270的博客
01-21
157
aligaduo 个人博客www.zhangxiaoshuai.funMySQL Replication主从复制允许将来自一个MySQL数据库服务器(主服务器)的数据复制到一个或多个MySQL数据库服务器(从服务器)。为什么要进行复制？为了减轻主库的压力，应该在系统应用层面做读写分离，写操作走主库，读操作走从库。分散对数据库的访问压力，提升整个系统的性能和可用性，降低大访问量引发数据库宕机的故障...
Mysql双机热备配置教程
04-26
Mysql双机热备配置教程，mysql主从双向，单向同步，教程清晰。
mysql主从同步延迟优化大全
发歌的数据架构
07-09
7307
mysql> create database fafa;
Query OK, 1 row affected (0.01 sec)
mysql> use fafa
Database changed
mysql> create table test(jj int,kk varchar(10));
Query OK, 0 rows affected (0.02 sec)
MySQL5.7.19安装及主从复制构架配置
ziele_008的博客
07-11
2334
好长时间没更新blog了，主要因为今年单位做了部门调整。我的岗位从技术调整成为业务支撑，既要管技术又要管运营。而运营对我来说是个完全陌生的领域，牵扯了很多精力。好在经过小半年的适应逐渐找到了一些门道，终于有时间再搞搞构架了。
碰巧这段时间单位安排了一个项目，需求方要求不能用oracle，必须用开源的mysql。这可真出了个难题，主要是我不用mysql好多年。单位dba又是oracle方向的而且在歇...
mysql主从备份--双机热备.pdf
04-02
双机热备就是使用MySQL提供的一种主从备份机制实现。所谓双机热备其实是一个复制的过程，复制过程中一个服务器充当主服务器，一个或多个服务器充当从服务。这个复制的过程实质上是从服务器复制主服务器上MySQL的二进制日志（bin-log），并在从服务器上还原主服务器上的操作。
MySql实现主从热备和读写分离
热门推荐
Sanjay的专栏
10-05
1万+
MySql 主从热备份工作原理简单的说：就是主服务器上执行过的sql语句会保存在binLog里面，别的从服务器把他同步过来，然后重复执行一遍，那么它们就能一直同步啦。我们进一步详细介绍原理的细节， 这有一张图：以上是一个主-从复制（热备)的例子。 整体上来说，复制有3个步骤：
作为主服务器的Master，会把自己的每一次改动（每条sql语句）都记录到二进制日志Binarylog中。
作为从服务器Sl
高性能Mysql主从架构的复制原理及配置详解
weixin_30311605的博客
03-06
1830
温习《高性能MySQL》的复制篇.
1 复制概述
Mysql内建的复制功能是构建大型，高性能应用程序的基础。将Mysql的数据分布到多个系统上去，这种分布的机制，是通过将Mysql的某一台主机的数据复制到其它主机（slaves）上，并重新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日...
MySQL数据库主从热备部署心得
数通畅联
06-30
356
MySQL数据库是一款优秀的开源数据库，目前公司的全线产品都使用的MySQL数据库，并且在实际项目中积累了大量MySQL配置以及优化方案，包括数据库主从配置、高可用配置，以及缓存机制、视图索引、I/O优化等一系列性能优化策略。
本次ESB项目采用的是K8S云平台的部署模式，并且通过7台服务器实现了高可用部署，为了从数据库层面保证系统运行，保证ESB服务流程运行的稳定，所以对数据库采用主从热备的部署方案，并对主从热备的配置方式进行总结。
1总体说明
主从机制是产品、数据库部署时比较常用的方式，通过主从部
使用Mysql主从复制技术实现数据库热备
菜鸟、上路
06-13
935
一、Mysql Replication
1、什么是Mysql Replication
Replication可以实现将数据从一台数据库服务器（master）复制到一台或多台数据库服务器（slave）
默认情况下属于异步复制，无需维持长连接
通过配置，可以复制所有的库或者几个库，甚至库中的一些表
是MySQL内建的，本身自带的
2、Mysql Replication的原理
简单...
学一点 mysql 双机异地热备份----快速理解mysql主从，主主备份原理及实践
weixin_30393907的博客
02-16
684
感谢大家在上一篇学一点Git--20分钟git快速上手里的踊跃发言。这里再次分享干货，简单介绍mysql双机，多机异地热备简单原理实战。
双机热备的概念简单说一下，就是要保持两个数据库的状态自动同步。对任何一个数据库的操作都自动应用到另外一个数据库，始终保持两个数据库数据一致。 这样做的好处多。 1. 可以做灾备，其中一个坏了可以切换到另一个。 2. 可以做负载均衡，可以将请求分摊到其中任...
mysql主从配置 热备_MYSQL 主从热备方式配置
weixin_32296949的博客
01-18
175
MySQL数据库没有增量备份的机制，当数据量太大的时候备份是一个很大的问题。还好MySQL数据库提供了一种主从备份的机制，其实就是把主数据库的所有的数据同时写到备份数据库中。实现MySQL数据库的热备份。 要想实现双机的热备首先要了解主从数据库服务器的版本的需求。要实现热备MySQL的版本都要高于3.2，还有一个基本的原则就是作为从数据库的数据库版本可以高于主服务器数据库的版本，但是不可...
“相关推荐”对你有帮助么？
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
©️2022 CSDN
皮肤主题：大白
设计师：CSDN官方博客
返回首页
Running_free
CSDN认证博客专家
CSDN认证企业博客
码龄5年
暂无认证
91
原创
5万+
周排名
150万+
总排名
19万+
访问
等级
2915
积分
113
粉丝
97
获赞
31
评论
427
收藏
私信
关注
热门文章
windows下如何查看本机所在局域网内所有可以访问的IP
12678
Python爬虫之headers和data的获取
11185
kubernetes(k8s)集群搭建
9546
codis集群部署实战 - 入门篇
8389
linux终端能显示中文，但是不能输入中文的解决方法
7730
分类专栏
Orangepi
10篇
linux运维
84篇
python
28篇
nginx
1篇
php
1篇
Ubuntu
6篇
vps
爬虫
2篇
人工智能
2篇
最新评论
linux终端能显示中文，但是不能输入中文的解决方法
lmw0320:
第一种有用！！
但是source ~/.inputrc 后，需要重开一个终端，就可以正常输入了。在原始的终端下，仍旧是没用的。
linux终端能显示中文，但是不能输入中文的解决方法
十有九悲.:
呜呜用第一种方法重启了还是不能输入中文
Orange pi GPIO输出控制，裸机点灯大法（一）！
breath_make_bug:
知道什么叫裸机吗？？？？？
Orange Pi 通过I2C总线连接LCD1602
QQ-2858498411:
踩坑人路过，官方系统是真的不能用，给我整秃头了。换上armbian马上就好了，谢谢谢谢！！！！！！！！
Orange Pi 通过I2C总线连接LCD1602
QQ-2858498411:
踩坑人路过，官方系统是真的不能用，给我整秃头了。换上armbian马上就好了，谢谢谢谢！！！！！！！！
您愿意向朋友推荐“博客详情页”吗？
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
老王家4.9元ESP8266温湿度传感器（光和未来）不开壳无损制作网页温湿度计
windows下如何查看本机所在局域网内所有可以访问的IP
ubuntu server 安装桌面环境
2021年1篇
2020年5篇
2019年8篇
2018年3篇
2017年76篇
目录
目录
分类专栏
Orangepi
10篇
linux运维
84篇
python
28篇
nginx
1篇
php
1篇
Ubuntu
6篇
vps
爬虫
2篇
人工智能
2篇
目录
评论
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
打赏作者
Running_free
你的鼓励将是我创作的最大动力
¥2
¥4
¥6
¥10
¥20
输入1-500的整数
余额支付
(余额：-- )
扫码支付
扫码支付：¥2
获取中
扫码支付
您的余额不足，请更换扫码支付或充值
打赏作者
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明：
1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、C币套餐、付费专栏及课程。
余额充值