MySQL 5.7.19 主從複製實現與調優
一、引言
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 2.下載mysql5.7.19
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.rpmserver3 上也需要同樣安裝
##master(server2)配置
[[email protected] ~]# 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
[[email protected] ~]# /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 [email protected]: qpNtt:l*v3kR
[[email protected] ~]# mysql -p
Enter password: ##使用剛才的密碼登陸
mysql> alter user [email protected] identified by '1234+ASdf'; ##修改密碼，否則不允許對資料庫操作,密碼有強壯度檢測
Query OK, 0 rows affected (0.02 sec)
mysql> grant replication slave on *.* to [email protected]'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？
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)
[[email protected] ~]# 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
[[email protected] ~]# /etc/init.d/mysqld restart
[[email protected] ~]# 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)
[[email protected] 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
[[email protected] mysql]# /etc/init.d/mysqld restart
[[email protected] 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裡面：
[[email protected] ~]# 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 [email protected]_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
[[email protected] ~]# 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
[[email protected] ~]# /etc/init.d/mysqld restart
[[email protected] ~]# 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 重新開啟之後，有自動恢復為半同步複製。
相關推薦
MySQL 5.7.19 主從複製實現與調優
一、引言 MySQL 支援單向、非同步複製,複製過程中一個伺服器充當主伺服器,而一個或多個其它伺服器充當從伺服器。主伺服器將更新寫入二進位制日誌檔案,並維護檔案的一個索引以跟蹤日誌迴圈。這些日誌可以記錄傳送到從伺服器的更新。當一個從伺服器連線主伺服器時,它通知
MySQL 5.7.22 主從複製配置
一、主從複製原理 MySQL 主從複製是一個非同步的複製過程，主庫傳送更新事件到從庫，從庫讀取更新記錄，並執行更新記錄，使得從庫的內容與主庫保持一致。每一個主從複製的連線，都有三個執行緒。擁有多個從庫的主庫為每一個連線到主庫的從庫建立一個 log dump 輸出執行緒，每一
LInux CentOS7 MySql 5.7.23主從複製(主從同步)
一、編輯主伺服器mysql 配置檔案 vim /etc/my.conf server-id=1 #伺服器id (主從必須不一樣) log-bin=mysql-bin #開啟日誌(主機需要開啟)，這個mysql-bin也可以自定義，這裡也可以加上路徑作為主機的配
MySQL 5.7.22 主從複製--use
一、mysql主從配置 1、解決web應用系統，資料庫出現的效能瓶頸，採用資料庫叢集的方式來實現查詢負載； 2、mysql支援資料庫的主從複製功能，使用主資料庫進行資料的寫入操作，從資料庫則用來進行資料讀操作 二、資料庫配置 1、修改主庫的配置檔案(my.cnf) [
MySQL 5.7.19組複製搭建
[mysqld3306] port = 3306 socket = /home/mysql/data/mysql.sock # GENERAL # user
【MySQL進階】Keepalived1.4.0結合MySQL 5.7.19實現主備高可用
port 腳本 amp ado roo ins log openss net 1、基本環境 數據庫安裝及主備同步接上一篇文章：http://blog.51cto.com/13946719/2309514JDK 1.8_171MySQL 5.7.19CentOS 7.4Kee
MySQL 5.7.19 編譯安裝與配置
進入MySQL官網下載頁面，地址https://www.mysql.com/downloads/，如果你想使用MySQL 5.7.19的原始碼版本，點此處直接下載! 進入MySQL Community Edition下載頁面 選擇作業系統為Source Code，選擇作業系統版本為Ge
win10 安裝mysql-5.7.19-winx64
安裝 win10 mysql 問：配置低不方便老開虛擬機還想學習一下mysql 怎麽辦，答：安裝在自己的Windows上。O(∩_∩)O 好了廢話不多說，下面開始1、 下載mysql-5.7.19-winx64包，沒有的去mysql網站https://dev.mysql.com/download
CentOS7/64位環境安裝Mysql 5.7.19二進制包教程
char group 教程 設置 路徑 datadir init alt mysq 1.下載mysql 在官網：http://dev.mysql.com/downloads/mysql/ 中，選擇二進制的mysql版本下載： #wget http://dev.mys
免編譯安裝mysql 5.7.19
mysql好久沒安裝mysql了，今天需要安裝才發覺竟然盡快得差不多了，記錄下，失憶時有用；mkdir /soft /data/mysql --建立目錄cd /softwget https://cdn.mysql.com//Downloads/MySQL-5.7/
Windows下Mysql 5.7.19 開啟bin-log以及mysql配置
mysql 5.7 binlog一、配置環境：OS：Win10Mysql：5.7.19二、我的Mysql配置文件（my.ini）如下：[client] port=3306 default-character-set=utf8 [mysqld] #Path to install software direc
MySQL 5.7下主從復制延遲解決方案
mysql replication 在MySQL下主從復制的延遲問題一直是在業界內比較大的困擾，主從的延遲會因為受到網絡磁盤等等相關的因素影響，但其中最主要的影響是就是在master太過繁忙的寫入導致slave無法有效的從relay_log中讀取到最新的相關記錄，這樣對於數據實時性很高的業務來說
windows下MySQL 5.7.19版本sql_mode=only_full_group_by問題
連接 end group 連接數 模式 數據庫 png func all 用到GROUP BY 語句查詢時出現 which is not functionally dependent on columns in GROUP BY clause; this is incom
Windows安裝MySQL 5.7.19及相關問題處理
mysql首先我們需要先安裝vc++2013否則可能出現,找不到msvcr110.dll文件http://www.microsoft.com/zh-cn/download/details.aspx?id=40784 1.下載(操作系統為Windows Server 2016數據中心版)https://dev.
CentOs6.5系統下MySQL-5.7.19安裝
mysql5.7安裝好長時間沒有更新了，今天給大家分享一波簡單的文檔，菜鳥的入門精神就是不斷的學習，不斷地找大神幫助！！！！在這裏今天給大家推薦一個博文地址：http://sumongodb.blog.51cto.com/好了！廢話少說，幹活走起來！！！！！！！！CentOs6.5下mysql5.7.19二進
Linux下CenOS系統 安裝Mysql-5.7.19
roo img .rpm undle -1 -c style root ima 1.輸入網址https://www.mysql.com/downloads/，進入downloads，選擇Community 2.選擇對應的版本和系統；
MySQL 5.7.19 CentOS 7 安裝
sed mysql variable 若有 views copy 文件 inux 現在 Linux的版本有很多，因此下載mysql時，需要註意下載對應Linux版本的MySql數據庫文件。以下方法也適合centOS 7 的mysql 5.7.* 版本的安裝。安裝方法我整理為
mysql-5.7.19-winx64 安裝 服務無法啟動
.cn data 服務 sql 5.7 logs 錯誤 mage 文件 錯誤截圖 解決方案： 刪除之前新建data文件夾，重現初始化 mysql-5.7.19-winx64 安裝 服務無法啟動
mysql 5.7.19編譯安裝
安裝 class 項目 .tar.gz load oot sharp div 下載安裝 因負責的項目數據庫版本較低，存在安全漏洞要求升級～ 純內網環境，所以只能編譯安裝。。 一、下載安裝包 [[email protected] mysql]# cd /usr/l
【環境部署】centos7安裝mysql-5.7.19 group-replication
mysql初始化 add path data state mysqld _for boot serve --mysql高可用官方文檔： https://dev.mysql.com/doc/refman/5.7/en/group-replication.html mysql