兩種模式

一主兩從

      server1

       /     \

server2  server3

級聯式

server1<----server2<------server3

注意：

去中心化server3找server2，server2找server1  -------級聯，這樣降低了server1的負載

配置mysql是，很多問題直接看報錯日志就可以解決！！！！！

主從復制是單向的，不能在從機直接操作數據庫寫數據

主從復制的基礎是在底層數據一致上才能搭建，如果不一致，一定要先同步數據在slave上

 

///////////////////////保證數據一致性，導入數據庫////////////////////////////////////////////////////////////

1，主：mysqldump -p test > test.sql  默認會復制gtid信息

注意:mysqldump有個bug，如果在從機上存在和要備份名字一樣的表，那么回刪除這個表，也就是從機數據會丟失

2，scp test.sql server從機

在導入之前需要修改test.sql（要創建這個庫，如果已經存在就不用創建了，還要使用這個庫，和下面的sql語句銜接，從sql語句可以看到，會刪除userlist 如果它存在）

3，mysq -p < test.sql

此時可以登錄查看已經出現了test庫和userlist表

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////

（/etc/my.cnf里面參數的下劃線和短橫線沒有什么區別）

 

一，基于gtid的數據庫級聯主從復制：
server1 < server2 < server3

server2里面要寫log-slave-updates，如果server3后面還有節點，那么在server2上面也需要寫log-slave-updates，而且需要在server3中認server2主 ，以此類推，其實配置時可以認為就是一主一從，級聯配置同server1-server2

1，配置文件：

server2如下

server3如下

2，server2上授權(serevr2是server3的master)

3，授權之后可以遠程登錄測試一下用戶

4，server3上配置server2為master，啟動slave，如果之前是slave，必須要先stop slave;

配置完成！！！可以在server1上寫入數據，如果server3可以看到，那么server2一定可以看見，因為server3就是從server2那獲取的數據。

 

 

 

二，并行復制

多線程，當主庫寫入很頻繁時，從庫復制要等很久

1，只在slave中配置 server2,server3，主庫不變

vim /etc/my.cnf

slave-parallel-type=LOGICAL_CLOCK

slave-parallel-workers=16不要設置為1，那樣反而效率很低

master_info_repository=TABLE

relay_log_info_repository=TABLE

relay_log_recovery=ON

等于TABLE 相當于直接寫在數據庫里面，避免重復記錄在/etc/lib/mysqlmaster.info里面，一直刷磁盤

2，重啟server2,sever3的mysql服務

3，此時查看進程

********************************************************

判斷延遲

show slave status

三個值

Read_Master_Log_Pos:

Exec_Master_Log_Pos:這兩個pos號相等

Seconds_Behind_Master:這個值為0 那么可以判斷無延遲

********************************************************

 

***************************延遲服務器*****************

1，避免誤操作delete，此時還可以從延遲服務器中挽救

2，測延遲對業務的影響，最大多大的延遲會影響到業務

**********************************************************

 

普通的replication，即mysql的異步復制，依靠mysql二進制日志也即binary log進行數據復制。比如兩臺機器，一臺主機(master)，另外一臺是從機(slave)。

1. 正常的復制為：事務一（t1）寫入binlog buffer；dumper 線程通知slave有新的事務t1；binlog buffer 進行checkpoint；slave的io線程接收到t1并寫入到自己的的relay log；slave的sql線程寫入到本地數據庫。 這時，master和slave都能看到這條新的事務，即使master掛了，slave可以提升為新的master。
2. 異常的復制為：事務一（t1）寫入binlog buffer；dumper 線程通知slave有新的事務t1；binlog buffer 進行checkpoint；slave因為網絡不穩定，一直沒有收到t1；master 掛掉，slave提升為新的master，t1丟失。
3. 很大的問題是：主機和從機事務更新的不同步，就算是沒有網絡或者其他系統的異常，當業務并發上來時，slave因為要順序執行master批量事務，導致很大的延遲。

為了彌補以上幾種場景的不足，mysql從5.5開始推出了半同步。即在master的dumper線程通知slave后，增加了一個ack，即是否成功收到t1的標志碼。也就是dumper線程除了發送t1到slave，還承擔了接收slave的ack工作。如果出現異常，沒有收到ack，那么將自動降級為普通的復制，直到異常修復。

半同步帶來的新問題：

1. 如果異常發生，會降級為普通的復制。 那么從機出現數據不一致的幾率會減少，并不是完全消失。
2. 主機dumper線程承擔的工作變多了，這樣顯然會降低整個數據庫的性能。
3. 在MySQL 5.5和5.6使用after_commit的模式下, 即如果slave 沒有收到事務，也就是還沒有寫入到relay log 之前，網絡出現異常或者不穩定，此時剛好master掛了，系統切換到從機，兩邊的數據就會出現不一致。 在此情況下，slave會少一個事務的數據。

隨著MySQL 5.7版本的發布，半同步復制技術升級為全新的Loss-less Semi-Synchronous Replication架構，其成熟度、數據一致性與執行效率得到顯著的提升。

三，半同步

1，如果是節耦級聯式那么server2作為master和slave都要安裝插件之類的，使能寫在/etc/my.cnf可以永久實現，而且必須寫在[mysqld]中，延時可以不用寫

show plugins;查看插件

 

2，只要是主機server1,servre2配置為：

install pluginstall plugin rpl_semi_sync_master soname 'semisync_master.so';

in rpl_semi_sync_master soname 'semisync_master.so';

set global rpl_semi_sync_master_enabled=ON; 

只要是從機server2,server3配置為：

install plugin rpl_semi_sync_slave soname 'semisync_slave.so';

set global rpl_semi_sync_slave_enabled=ON;

3，從機半同步一定要stop/start slave io_thread才會生效，否則查看show variables like 'rpl_semi_sync% 狀態是OFF'

 

所以級聯式應該是這樣

server1

server2

server3

安裝插件，然后

 

4，查看變量

server2上面既有master又有slave的信息

延遲10000ms=10s

5，查看狀態，每行都是什么意思

 

測試

server2或者server3關閉 stop slave io_thread;然后master插入數據，會有10s的延遲，并且slave看不到同步數據，打開start slave io_thread才可以看到，而且級聯中只要有slave停止了io進程，那么整個都不會同步數據

 

重點！！！！

異步無法保證數據的一致性

半同步在生產中設置異步延遲為無窮大oo，實驗中我們沒有設置，默認為10s，這樣stop slave io_thread就相當于slave端有問題了，此時會去找異步方式，但是異步方式延遲是無窮大，slave端永遠同步不了數據，無法返回給master一個ack，所以master也沒辦法把數據從內存記入mysql_bin寫入磁盤，但是這樣會導致master端一致處于等待的狀態，也就是說master端業務無法正常允許，客戶端無法向數據庫寫入數據，這也是和異步不一樣的，異步不用等ack，我不管你slave端的狀態如何，在你返回一個ack之前，我已經把buffer里面的數據sync寫入內存，這也就是為什么異步無法保證數據的一致性的原因

MySQL 5.7 引入了新的變量slave-parallel-type，其可以配置的值有： 1. DATABASE （5.7之前默認值），基于庫的并行復制方式； 2. LOGICAL_CLOCK （5.7新增值），基于組提交的并行復制方式； MySQL 5.6版本也支持所謂的并行復制，但是其并行只是基于DATABASE的，也就是基于庫的。如果用戶的MySQL數據庫實例中存在多個DATABASE ，對于從機復制的速度的確可以有比較大的幫助，如果用戶實例僅有一個庫，那么就無法實現并行回放，甚至性能會比原來的單線程更差。 MySQL5.7中增加了一種新的并行模式：為同時進入COMMIT階段的事務分配相同的***，這些擁有相同***的事務在備庫是可以并發執行的。 MySQL 5.7真正實現的并行復制，這其中最為主要的原因就是slave服務器的回放與主機是一致的即master服務器上是怎么并行執行的slave上就怎樣進行并行回放。不再有庫的并行復制限制，對于二進制日志格式也無特殊的要求（基于庫的并行復制也沒有要求）。

四，組復制(全同步)

每個都是master，都可以讀寫

1，停掉所有的mysql

2，刪除/var/lib/mysql的所有

首節點配置如下server1

1，

可以修改/etc/init.d/mysqld

 

2，修改配置文件

https://dev.mysql.com/doc/refman/5.7/en/group-replication-configuring-instances.html  

server_id=1

gtid_mode=ON

enforce_gtid_consistency=ON

master_info_repository=TABLE

relay_log_info_repository=TABLE

binlog_checksum=NONE

log_slave_updates=ON

log_bin=binlog

binlog_format=ROW



transaction_write_set_extraction=XXHASH64

loose-group_replication_group_name="7552e307-9c7c-11e8-af0d-525400f07421"

loose-group_replication_start_on_boot=off

loose-group_replication_local_address= "172.25.28.1:24901"

loose-group_replication_group_seeds= "172.25.28.1:24901,172.25.28.2:24901,172.25.28.3:24901"

loose-group_replication_bootstrap_group=off

loose-group_replication_single_primary_mode=off

loose-group_replication_enforce_update_everywhere_checks=on

（loose的意思就是初始化的時候不檢查，雖然這些模塊在啟動mysql的時候沒有，但是后續會添加，防止無法啟動）

mysql> select uuid();  這個隨意獲取，這就是loose-group_replication_group_name

+--------------------------------------+

| uuid()                               |

+--------------------------------------+

| 7440de46-9c7c-11e8-af0d-525400f07421 |

+--------------------------------------+

1 row in set (0.00 sec)

3，啟動服務

4，獲取密碼，注意里面也記錄了之前的密碼，要看時間

grep password /var/log/mysqld.log

5，如果沒有安全初始化直接登錄使用數據庫時，它會讓你修改密碼

alter user root@localhost identified by 'Zming=1998';

6，配置

如果沒有在my.cnf里面設置ip白名單執行START GROUP_REPLICATION;

會出錯，這里我們先設置全局變量，結束后在my.cnf添加

7,建立庫，表

配置完之后要在配置文件里面寫上白名單，之前設定的全局變量重啟之后就不生效了

/etc/my.cf追加

loose-group_replication_ip_whitelist="172.25.28.0/24,127.0.0.1/8"

 

server2

1，先停止服務，刪除/var/lib//mysql所有數據

2，修改配置文件，兩處和server1不一樣

server_id=2                                             ###

gtid_mode=ON

enforce_gtid_consistency=ON

master_info_repository=TABLE

relay_log_info_repository=TABLE

binlog_checksum=NONE

log_slave_updates=ON

log_bin=binlog

binlog_format=ROW



transaction_write_set_extraction=XXHASH64

loose-group_replication_group_name="7552e307-9c7c-11e8-af0d-525400f07421"

loose-group_replication_start_on_boot=off

loose-group_replication_local_address= "172.25.28.2:24901"       ###

loose-group_replication_group_seeds= "172.25.28.1:24901,172.25.28.2:24901,172.25.28.3:24901"

loose-group_replication_bootstrap_group=off

loose-group_replication_single_primary_mode=off

loose-group_replication_enforce_update_everywhere_checks=on

loose-group_replication_ip_whitelist="172.25.28.0/24,127.0.0.1/8"

3，啟動服務

4，登錄修改密碼，配置服務

mysql> show databases;

ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.

mysql> alter user root@localhost identified by 'Zming=1998';

Query OK, 0 rows affected (0.07 sec)

mysql> SET SQL_LOG_BIN=0;

Query OK, 0 rows affected (0.00 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'Zming=1998';

Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> reset master;

Query OK, 0 rows affected (0.13 sec)

mysql> SET SQL_LOG_BIN=1;

Query OK, 0 rows affected (0.00 sec)

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='Zming=1998' FOR CHANNEL 'group_replication_recovery';

Query OK, 0 rows affected, 2 warnings (0.18 sec)

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';

mysql> START GROUP_REPLICATION;

Query OK, 0 rows affected (6.01 sec)

這里和server1首節點的配置有點不一樣，不用SET GLOBAL group_replication_bootstrap_group=ON，SET GLOBAL group_replication_bootstrap_group=OFF

5，查看

mysql> select * from test.t1;

+----+------+

| c1 | c2   |

+----+------+

|  1 | Luis |

+----+------+

1 row in set (0.00 sec)

 

仿照server2添加server3

1，先停止服務，刪除/var/lib//mysql所有數據

2，修改配置文件，兩處和server1不一樣

server_id=3                                           ###

gtid_mode=ON

enforce_gtid_consistency=ON

master_info_repository=TABLE

relay_log_info_repository=TABLE

binlog_checksum=NONE

log_slave_updates=ON

log_bin=binlog

binlog_format=ROW



transaction_write_set_extraction=XXHASH64

loose-group_replication_group_name="7552e307-9c7c-11e8-af0d-525400f07421"

loose-group_replication_start_on_boot=off

loose-group_replication_local_address= "172.25.28.3:24901"       ###

loose-group_replication_group_seeds= "172.25.28.1:24901,172.25.28.2:24901,172.25.28.3:24901"

loose-group_replication_bootstrap_group=off

loose-group_replication_single_primary_mode=off

loose-group_replication_enforce_update_everywhere_checks=on

loose-group_replication_ip_whitelist="172.25.28.0/24,127.0.0.1/8"

3，重啟服務

4，登錄修改密碼，配置服務

mysql> show databases;

ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.

mysql> alter user root@localhost identified by 'Zming=1998';

Query OK, 0 rows affected (0.07 sec)

mysql> SET SQL_LOG_BIN=0;

Query OK, 0 rows affected (0.00 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'Zming=1998';

Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> reset master;

Query OK, 0 rows affected (0.18 sec)

mysql> SET SQL_LOG_BIN=1;

Query OK, 0 rows affected (0.00 sec)

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='Zming=1998' FOR CHANNEL 'group_replication_recovery';

Query OK, 0 rows affected, 2 warnings (0.34 sec)

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';

Query OK, 0 rows affected (0.17 sec)

mysql> START GROUP_REPLICATION;

Query OK, 0 rows affected (2.91 sec)

mysql> SELECT * FROM performance_schema.replication_group_members;

+---------------------------+--------------------------------------+-------------+-------------+--------------+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

+---------------------------+--------------------------------------+-------------+-------------+--------------+

| group_replication_applier | 1fd24e68-9c83-11e8-9cf5-5254002c0a1d | server2     |        3306 | ONLINE       |

| group_replication_applier | 41f9478b-9c7d-11e8-914d-525400d4f7b9 | server1     |        3306 | ONLINE       |

| group_replication_applier | 4af67249-9c86-11e8-8f8c-525400f07421 | server3     |        3306 | ONLINE       |

+---------------------------+--------------------------------------+-------------+-------------+--------------+

3 rows in set (0.00 sec)

注意：1，這三個節點都必須ONLINE

2,初始節點要做開啟SET GLOBAL group_replication_bootstrap_group=ON，關閉SET GLOBAL group_replication_bootstrap_group=OFF之后節點的就不用了

3，同樣的數據是查不進去的，有主鍵

mysql> INSERT INTO test.t1 VALUES (1, 'Luis');

ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY'

mysql> select * from test.t1;

+----+------+

| c1 | c2   |

+----+------+

|  1 | Luis |

+----+------+

1 row in set (0.00 sec)

 

 

測試：

在server2上添加數據

mysql> INSERT INTO test.t1 VALUES (2, 'Luis');

Query OK, 1 row affected (0.33 sec)

在server1,3上都可以看見

mysql>  select * from test.t1;

+----+------+

| c1 | c2   |

+----+------+

|  1 | Luis |

|  2 | Luis |

+----+------+

2 rows in set (0.00 sec)

注意：三個節點最多允許down一個，否則構成不了集群