Mysqlのプライマリ・スレーブ・レプリケーション、プライマリ・プライマリ・レプリケーション、半同期レプリケーションおよびレプリケーション・フィルタリング
20108 ワード
Mysqlのレプリケーション・アーキテクチャは、負荷分散、高可用性、バックアップ、データ分散のサーバ・クラスタを提供します.このようなクラスタを完了する前に、データベース・サーバが同期データを正常にレプリケーションできることを保証する必要があります.このような同期を完了する方法は、主スレーブ・レプリケーションと主マスター・レプリケーションです.
一、Mysqlの主従レプリケーション
1、環境準備
Linux仮想ホスト2台.Linuxバージョン:7.4 ip:192.168.0.82(master)、192.168.0.89(slave)データベースバージョン:mariadb-server.x86_64 1:5.5.56-2.El 7 mariadb-serverサービスを開始する前に、/etc/myを確保することに注意する.cnfプロファイルの構成はlog-binオプションをオンにします.このオプションは、プライマリ・セカンダリ・レプリケーションのデータ同期が、実際にはバイナリ・ログのバックアップで再現されるため、オンにする必要があります.
マスターサーバのデータベースプロファイルを構成するには、次の手順に従います.
slaveサーバのデータベースプロファイルを構成するには、次の手順に従います.
最後にデータベース・サービスを開始します.
2、主従レプリケーションの構築
データベース・サービスのインストールはここで省略し、関連するインストール方法を自分で検索できます.既存のデータベース・サーバでプライマリ・スレーブを構成する場合は、プライマリ・スレーブがデータと一致していることを確認してから、プライマリ・スレーブ・レプリケーションを構成する必要があります.サーバから主にmasterサーバのbinlogログを取得してサーバから再実行するため、データを同期させるため、サーバ自体に関連するデータベースがなければbinlogログの復元実行に失敗する可能性があります.
まずmasterサーバに同期用のアカウントを作成します.
次に、masterサーバで対応するバイナリ・ログの名前とログposの場所を表示します.
次にslaveサーバでchange master文を実行します.
show slave statusでは、対応するslaveステータスを表示し、対応するslave情報とエラーを表示できます.
これでマスターコピーが完了します.
二、Mysqlの主なコピー
1、環境準備
Linux仮想ホスト2台.Linuxバージョン:7.4 ip:192.168.0.82(master 1)、192.168.0.89(master 2)データベースバージョン:mariadb-server.x86_64 1:5.5.56-2.El 7は、プライマリ・プライマリ・レプリケーションがbinlogおよびrelay-log機能を2つのサーバ・ノードでオンにし、server_idは異なる値を使用する必要があります.データベースに自動成長idのテーブルが存在する場合、idが競合しないように、master-1の自己成長が奇数、master-2の自己成長が偶数などの自動成長方法をカスタマイズする必要があります.
master 1のプロファイル:
master 2のプロファイル:
2、マスターコピーの構築
プライマリ・プライマリ・レプリケーションを構築する前に、サーバ間のデータが同じであることを確認します.まず、2つのサーバノードに同期化を行うためのレプリケーションアカウントを作成します.
次に、対応するbinlog情報をmaster 1およびmaster 2にそれぞれ表示します.
次に、master 1とmaster 2でchange masterを使用して相手をmasterとして指定し、slaveを起動します.
3、テストマスターコピー
マスター1とマスター2のslaveステータスをそれぞれ表示します.
Slave_IO_RunningとSlave_SQL_Runningはyesとして表示され、プライマリ・プライマリ・レプリケーションが正常に開始されたことを示します.
master 1でmydbデータの作成をテストします.
マスター2で同期作成mydbをコピーし、マスター2でmydbライブラリのaccountテーブルを作成できるはずです.
このとき、master 1とmaster 2にaccountテーブルにそれぞれデータを挿入します.
挿入が完了したら、master 1とmaster 2に次のデータが表示されるはずです.
Mysqlのプライマリ・プライマリ・レプリケーションの同期が正常に行われたことを示します.
三、Mysqlの半同期コピー
MySQL 5から5から、MySQLはプラグイン形式で半同期レプリケーションをサポートします.半同期をどのように理解しますか?まず,非同期,全同期の概念を見てみよう.
非同期レプリケーション:MySQLのデフォルトのレプリケーションは非同期です.プライマリ・ライブラリはクライアントからコミットされたトランザクションを実行した後、すぐに結果をクライアントに返します.ライブラリから受信して処理されたかどうかは気にしません.これにより、プライマリがcrashを落とした場合、プライマリからコミットされたトランザクションがプライマリに転送されない可能性があります.この場合、強制的にプライマリから昇格します.新しいプライマリ上のデータが不完全になる可能性があります.≪フル同期レプリケーション|Full Synchronization Replication|emdw≫:プライマリ・ライブラリがトランザクションを実行した後、すべてのスレーブ・ライブラリがトランザクションを実行してからクライアントに戻ります.すべてのトランザクションがライブラリから実行されるまで待機する必要があるため、フル同期レプリケーションのパフォーマンスには大きな影響があります.半同期レプリケーション:非同期レプリケーションと全同期レプリケーションの間で、プライマリ・ライブラリは、クライアントがコミットしたトランザクションを実行した後、すぐにクライアントに戻るのではなく、少なくとも1つのライブラリから受信しrelay logに書き込まれてからクライアントに戻るのを待っています.非同期レプリケーションに比べて、半同期レプリケーションはデータのセキュリティを向上させ、同時にある程度の遅延をもたらし、この遅延は少なくともTCP/IP往復の時間である.したがって、半同期レプリケーションは、低遅延のネットワークで使用することが望ましい.Mysqlハーフ同期レプリケーションは、Mysql 5.5以降で使用し、関連するサポートプラグインをインストールする必要があります.次に、これまでのプライマリは、レプリケーションの構成環境から半同期レプリケーションを構築しました.
1、半同期レプリケーションの構築
まず、Masterとslaveサーバが動的追加プラグインをサポートしているかどうかを確認します.
次に、対応するプラグインディレクトリの下にプラグインsemisync_が存在するかどうかをそれぞれチェックします.master.soとsemisync_slave.so:
次にmasterサーバにプラグインsemisync_をインストールします.master.so,slaveサーバにsemisync_をインストールするslave.soプラグイン:
インストールが完了すると、mysqlライブラリのpluginテーブルに適切なプラグインが表示されます.
次に、masterとslaveのデータベースプロファイルをそれぞれ構成し、半同期機能を有効にします.
最後にデータベース・サービスを再起動すればいいです.
起動が完了したら、次の2つのコマンドでマスターホスト上で半同期レプリケーションの状態を確認できます.
四、Mysqlのコピーフィルタ
前述したプライマリ・スレーブ・レプリケーション、プライマリ・プライマリ・レプリケーション、非同期レプリケーション、セミ同期レプリケーションなどは、ほとんどが同期したすべてのデータベースをレプリケーションしますが、指定した1つまたは2つのデータベースのみをレプリケーションする必要がある場合があります.この場合、指定した1～2つのデータベースを同期するためにデータベース全体を同期すると、プライマリ・サーバの負荷が大きすぎる可能性があります.この場合,Mysqlのレプリケーションフィルタを用いてレプリケーションフィルタを実装し,指定したデータベースのみをレプリケーションするか,指定したデータベースをレプリケーションしないかの実装方法は以下の2つである.
1、Masterのフィルタ変数を修正する
次の2つのグローバル変数は、Masterサーバ上で変更できます.
この2つのグローバル変数は一般的に同時に指定されないため、同時に指定すると干渉衝突を起こしやすい.変更が完了すると、プライマリ・サーバは指定したデータベースに関連する書き込みのみをバイナリ・ログに記録します.しかし、Masterを変更する方法では、他のデータベースが時間ノードベースのリカバリ機能を使用できなくなるという大きな弊害があります.
2、サーバーからのフィルタ変数の変更
2つ目の方法は、サーバからのフィルタ変数を変更し、サーバのSQLスレッドから指定したデータベースまたはテーブルの関連イベントをフィルタし、ローカルに適用することです.
関連変数は次のとおりです.
3、コピーフィルタ例
サーバから同期hellodbのみをコピーするように構成するには、次の手順に従います.
このときmasterで行った変更は、hellodbに関連するイベントのみがslaveにコピー同期され、他のライブラリの変更変更は同期されません.
一、Mysqlの主従レプリケーション
1、環境準備
Linux仮想ホスト2台.Linuxバージョン:7.4 ip:192.168.0.82(master)、192.168.0.89(slave)データベースバージョン:mariadb-server.x86_64 1:5.5.56-2.El 7 mariadb-serverサービスを開始する前に、/etc/myを確保することに注意する.cnfプロファイルの構成はlog-binオプションをオンにします.このオプションは、プライマリ・セカンダリ・レプリケーションのデータ同期が、実際にはバイナリ・ログのバックアップで再現されるため、オンにする必要があります.
マスターサーバのデータベースプロファイルを構成するには、次の手順に従います.
[root@master ~]# vim /etc/my.cnf
log-bin=master.log # master log-bin
innodb-file-per-table=ON
sync_binlog = 1 # ，sync_binlog=0， MySQL binlog ， 。 ， 。 Crash， binlog_cache binlog 。
server_id=1 #mysql server-id ， server ， server-id
slaveサーバのデータベースプロファイルを構成するには、次の手順に従います.
[root@slave ~]# vim /etc/my.cnf
innodb-file-per-table=ON
relay-log=relay.log # master binlog
read-only=ON # ， SUPER
server_id=2
最後にデータベース・サービスを開始します.
2、主従レプリケーションの構築
データベース・サービスのインストールはここで省略し、関連するインストール方法を自分で検索できます.既存のデータベース・サーバでプライマリ・スレーブを構成する場合は、プライマリ・スレーブがデータと一致していることを確認してから、プライマリ・スレーブ・レプリケーションを構成する必要があります.サーバから主にmasterサーバのbinlogログを取得してサーバから再実行するため、データを同期させるため、サーバ自体に関連するデータベースがなければbinlogログの復元実行に失敗する可能性があります.
まずmasterサーバに同期用のアカウントを作成します.
MariaDB [(none)]> grant REPLICATION SLAVE ON *.* TO 'slave'@'192.168.0.89' identified by '123456';
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)
次に、masterサーバで対応するバイナリ・ログの名前とログposの場所を表示します.
MariaDB [(none)]> show master status;
+---------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| master.000003 | 8154 | | |
+---------------+---------
次にslaveサーバでchange master文を実行します.
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='192.168.0.82',MASTER_USER='slave',MASTER_PASSWORD='123456',MASTER_LOG_FILE='master.000003',MASTER_LOG_POS=8154;
MariaDB [hellodb]> start slave; # slave
show slave statusでは、対応するslaveステータスを表示し、対応するslave情報とエラーを表示できます.
MariaDB [hellodb]> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.82
Master_User: slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master.000004
Read_Master_Log_Pos: 733
Relay_Log_File: relay.000002
Relay_Log_Pos: 1014
Relay_Master_Log_File: master.000004
Slave_IO_Running: Yes # slave IO ， yes ， 。
Slave_SQL_Running: Yes # slave SQL ， yes ， 。
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 733
Relay_Log_Space: 1298
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0 # slave master
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
1 row in set (0.00 sec)
ERROR: No query specified
これでマスターコピーが完了します.
二、Mysqlの主なコピー
1、環境準備
Linux仮想ホスト2台.Linuxバージョン:7.4 ip:192.168.0.82(master 1)、192.168.0.89(master 2)データベースバージョン:mariadb-server.x86_64 1:5.5.56-2.El 7は、プライマリ・プライマリ・レプリケーションがbinlogおよびrelay-log機能を2つのサーバ・ノードでオンにし、server_idは異なる値を使用する必要があります.データベースに自動成長idのテーブルが存在する場合、idが競合しないように、master-1の自己成長が奇数、master-2の自己成長が偶数などの自動成長方法をカスタマイズする必要があります.
master 1のプロファイル:
log-bin=master1.log
relay-log=master1-relay.log
innodb-file-per-table=ON
server_id=1
auto_increment_offset=1 # 。 n MySQL
auto_increment_increment=2 # auto_imcrement。 n MySQL n
master 2のプロファイル:
log-bin=master2.log
innodb-file-per-table=ON
relay-log=master2-relay.log
server_id=2
auto_increment_increment=2
auto_increment_offset=2
2、マスターコピーの構築
プライマリ・プライマリ・レプリケーションを構築する前に、サーバ間のデータが同じであることを確認します.まず、2つのサーバノードに同期化を行うためのレプリケーションアカウントを作成します.
#master1
MariaDB [(none)]> GRANT REPLICATION SLAVE ON *.* TO 'master1-slave'@'192.168.0.89' identified by '123456';
Query OK, 0 rows affected (0.01 sec)
MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)
#master2
MariaDB [(none)]> GRANT REPLICATION SLAVE ON *.* TO 'master2-slave'@'192.168.0.82' identified by '123456';
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.01 sec)
次に、対応するbinlog情報をmaster 1およびmaster 2にそれぞれ表示します.
#master1
MariaDB [(none)]> show master status;
+----------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+----------------+----------+--------------+------------------+
| master1.000001 | 492 | | |
+----------------+----------+--------------+------------------+
1 row in set (0.00 sec)
#master2
MariaDB [(none)]> show master status;
+----------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+----------------+----------+--------------+------------------+
| master2.000001 | 492 | | |
+----------------+----------+--------------+------------------+
1 row in set (0.00 sec)
次に、master 1とmaster 2でchange masterを使用して相手をmasterとして指定し、slaveを起動します.
#master1
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='192.168.0.89',MASTER_USER='master2-slave',MASTER_PASSWORD='123456',MASTER_LOG_FILE='master2.000001',MASTER_LOG_POS=492;
Query OK, 0 rows affected (0.08 sec)
MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.01 sec)
#master2
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='192.168.0.82',MASTER_USER='master1-slave',MASTER_PASSWORD='123456',MASTER_LOG_FILE='master1.000001',MASTER_LOG_POS=492;
Query OK, 0 rows affected (0.03 sec)
MariaDB [(none)]> start slave;
3、テストマスターコピー
マスター1とマスター2のslaveステータスをそれぞれ表示します.
#master1
MariaDB [(none)]> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.89
Master_User: master2-slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master2.000001
Read_Master_Log_Pos: 492
Relay_Log_File: master1-relay.000002
Relay_Log_Pos: 527
Relay_Master_Log_File: master2.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 492
Relay_Log_Space: 819
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2
1 row in set (0.00 sec)
ERROR: No query specified
#master2
MariaDB [(none)]> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.82
Master_User: master1-slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master1.000001
Read_Master_Log_Pos: 492
Relay_Log_File: master2-relay.000002
Relay_Log_Pos: 527
Relay_Master_Log_File: master1.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 492
Relay_Log_Space: 819
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
1 row in set (0.00 sec)
ERROR: No query specified
Slave_IO_RunningとSlave_SQL_Runningはyesとして表示され、プライマリ・プライマリ・レプリケーションが正常に開始されたことを示します.
master 1でmydbデータの作成をテストします.
MariaDB [(none)]> create database mydb;
Query OK, 1 row affected (0.00 sec)
マスター2で同期作成mydbをコピーし、マスター2でmydbライブラリのaccountテーブルを作成できるはずです.
MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| hellodb |
| mydb |
| mysql |
| performance_schema |
| test |
+--------------------+
6 rows in set (0.00 sec)
MariaDB [(none)]> use mydb;
MariaDB [mydb]> create table account (id INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,name VARCHAR(30));
Query OK, 0 rows affected (0.01 sec)
このとき、master 1とmaster 2にaccountテーブルにそれぞれデータを挿入します.
#master1
MariaDB [(none)]> use mydb;
MariaDB [mydb]> insert into account(name) values ('charlie'),('jack'),('alice');
Query OK, 3 rows affected (0.01 sec)
Records: 3 Duplicates: 0 Warnings: 0
#master2
MariaDB [mydb]> insert into account(name) values ('Ops'),('IT'),('Manager');
Query OK, 3 rows affected (0.00 sec)
Records: 3 Duplicates: 0 Warnings: 0
挿入が完了したら、master 1とmaster 2に次のデータが表示されるはずです.
MariaDB [mydb]> select * from account;
+----+---------+
| id | name |
+----+---------+
| 1 | charlie |
| 3 | jack |
| 5 | alice |
| 6 | Ops |
| 8 | IT |
| 10 | Manager |
+----+---------+
6 rows in set (0.00 sec)
Mysqlのプライマリ・プライマリ・レプリケーションの同期が正常に行われたことを示します.
三、Mysqlの半同期コピー
MySQL 5から5から、MySQLはプラグイン形式で半同期レプリケーションをサポートします.半同期をどのように理解しますか?まず,非同期,全同期の概念を見てみよう.
非同期レプリケーション:MySQLのデフォルトのレプリケーションは非同期です.プライマリ・ライブラリはクライアントからコミットされたトランザクションを実行した後、すぐに結果をクライアントに返します.ライブラリから受信して処理されたかどうかは気にしません.これにより、プライマリがcrashを落とした場合、プライマリからコミットされたトランザクションがプライマリに転送されない可能性があります.この場合、強制的にプライマリから昇格します.新しいプライマリ上のデータが不完全になる可能性があります.≪フル同期レプリケーション|Full Synchronization Replication|emdw≫:プライマリ・ライブラリがトランザクションを実行した後、すべてのスレーブ・ライブラリがトランザクションを実行してからクライアントに戻ります.すべてのトランザクションがライブラリから実行されるまで待機する必要があるため、フル同期レプリケーションのパフォーマンスには大きな影響があります.半同期レプリケーション:非同期レプリケーションと全同期レプリケーションの間で、プライマリ・ライブラリは、クライアントがコミットしたトランザクションを実行した後、すぐにクライアントに戻るのではなく、少なくとも1つのライブラリから受信しrelay logに書き込まれてからクライアントに戻るのを待っています.非同期レプリケーションに比べて、半同期レプリケーションはデータのセキュリティを向上させ、同時にある程度の遅延をもたらし、この遅延は少なくともTCP/IP往復の時間である.したがって、半同期レプリケーションは、低遅延のネットワークで使用することが望ましい.Mysqlハーフ同期レプリケーションは、Mysql 5.5以降で使用し、関連するサポートプラグインをインストールする必要があります.次に、これまでのプライマリは、レプリケーションの構成環境から半同期レプリケーションを構築しました.
1、半同期レプリケーションの構築
まず、Masterとslaveサーバが動的追加プラグインをサポートしているかどうかを確認します.
MariaDB [(none)]> select @@have_dynamic_loading;
+------------------------+
| @@have_dynamic_loading |
+------------------------+
| YES |
+------------------------+
1 row in set (0.00 sec)
次に、対応するプラグインディレクトリの下にプラグインsemisync_が存在するかどうかをそれぞれチェックします.master.soとsemisync_slave.so:
MariaDB [(none)]> show variables like 'plugin_dir';
+---------------+--------------------------+
| Variable_name | Value |
+---------------+--------------------------+
| plugin_dir | /usr/lib64/mysql/plugin/ |
+---------------+--------------------------+
1 row in set (0.01 sec)
MariaDB [(none)]> quit
Bye
[root@master ~]# ll /usr/lib64/mysql/plugin/ | grep semi
-rwxr-xr-x. 1 root root 41336 8 5 2017 semisync_master.so
-rwxr-xr-x. 1 root root 15984 8 5 2017 semisync_slave.so
次にmasterサーバにプラグインsemisync_をインストールします.master.so,slaveサーバにsemisync_をインストールするslave.soプラグイン:
#master
MariaDB [(none)]> install plugin rpl_semi_sync_master SONAME 'semisync_master.so';
Query OK, 0 rows affected (0.01 sec)
#slave
MariaDB [(none)]> install plugin rpl_semi_sync_slave SONAME 'semisync_slave.so';
Query OK, 0 rows affected (0.00 sec)
インストールが完了すると、mysqlライブラリのpluginテーブルに適切なプラグインが表示されます.
#master
MariaDB [(none)]> select * from mysql.plugin;
+----------------------+--------------------+
| name | dl |
+----------------------+--------------------+
| rpl_semi_sync_master | semisync_master.so |
+----------------------+--------------------+
1 row in set (0.00 sec)
#slave
MariaDB [(none)]> select * from mysql.plugin;
+---------------------+-------------------+
| name | dl |
+---------------------+-------------------+
| rpl_semi_sync_slave | semisync_slave.so |
+---------------------+-------------------+
1 row in set (0.00 sec)
次に、masterとslaveのデータベースプロファイルをそれぞれ構成し、半同期機能を有効にします.
#master
[root@master ~]# vim /etc/my.cnf
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=30000
#slave
[root@slave ~]# vim /etc/my.cnf
rpl_semi_sync_slave_enabled=1
最後にデータベース・サービスを再起動すればいいです.
起動が完了したら、次の2つのコマンドでマスターホスト上で半同期レプリケーションの状態を確認できます.
MariaDB [mydb]> show status like '%semi_sync%';
+--------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients | 1 | # slave
| Rpl_semi_sync_master_net_avg_wait_time | 1127 | #
| Rpl_semi_sync_master_net_wait_time | 1127 |
| 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 | 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 | 1 |
+--------------------------------------------+-------+
14 rows in set (0.00 sec)
MariaDB [(none)]> show variables like '%Rpl%';
+------------------------------------+-------+
| Variable_name | Value |
+------------------------------------+-------+
| rpl_recovery_rank | 0 |
| rpl_semi_sync_master_enabled | ON |
| rpl_semi_sync_master_timeout | 30000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_no_slave | ON |
+------------------------------------+-------+
5 rows in set (0.00 sec)
四、Mysqlのコピーフィルタ
前述したプライマリ・スレーブ・レプリケーション、プライマリ・プライマリ・レプリケーション、非同期レプリケーション、セミ同期レプリケーションなどは、ほとんどが同期したすべてのデータベースをレプリケーションしますが、指定した1つまたは2つのデータベースのみをレプリケーションする必要がある場合があります.この場合、指定した1～2つのデータベースを同期するためにデータベース全体を同期すると、プライマリ・サーバの負荷が大きすぎる可能性があります.この場合,Mysqlのレプリケーションフィルタを用いてレプリケーションフィルタを実装し,指定したデータベースのみをレプリケーションするか,指定したデータベースをレプリケーションしないかの実装方法は以下の2つである.
1、Masterのフィルタ変数を修正する
次の2つのグローバル変数は、Masterサーバ上で変更できます.
binlog_do_db= # ， db
binlog_ignore_db= # ， db
この2つのグローバル変数は一般的に同時に指定されないため、同時に指定すると干渉衝突を起こしやすい.変更が完了すると、プライマリ・サーバは指定したデータベースに関連する書き込みのみをバイナリ・ログに記録します.しかし、Masterを変更する方法では、他のデータベースが時間ノードベースのリカバリ機能を使用できなくなるという大きな弊害があります.
2、サーバーからのフィルタ変数の変更
2つ目の方法は、サーバからのフィルタ変数を変更し、サーバのSQLスレッドから指定したデータベースまたはテーブルの関連イベントをフィルタし、ローカルに適用することです.
関連変数は次のとおりです.
Replicate_Do_DB=
Replicate_Ignore_DB=
Replicate_Do_Table=
Replicate_Ignore_Table=
Replicate_Wild_Do_Table= #
Replicate_Wild_Ignore_Table=
3、コピーフィルタ例
サーバから同期hellodbのみをコピーするように構成するには、次の手順に従います.
MariaDB [(none)]> stop slave; # ， slave
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> set @@global.replicate_do_db=hellodb; # hellodb
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.82
Master_User: master1-slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master1.000005
Read_Master_Log_Pos: 470
Relay_Log_File: slave.000006
Relay_Log_Pos: 527
Relay_Master_Log_File: master1.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: hellodb # slave status db
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 470
Relay_Log_Space: 1318
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
1 row in set (0.00 sec)
このときmasterで行った変更は、hellodbに関連するイベントのみがslaveにコピー同期され、他のライブラリの変更変更は同期されません.