バイナリログ(binlogs)には、データベースに対するすべての変更の記録が含まれています。これらはレプリケーションに必要であり、バックアップ後にデータを復元するためにも使用できます。 binlogサーバーは、基本的にバイナリログリポジトリです。マスターサーバーからバイナリログを取得する専用のサーバーのように考えることができますが、スレーブサーバーはマスターサーバーに接続するのと同じように接続できます。
- 実際のマスターサーバーが変更されたことにスレーブが気付くことなく、新しいマスターサーバーに切り替えることができます。これにより、レプリケーションの優先度が高い、より可用性の高いレプリケーション設定が可能になります。
- すべてのスレーブではなく、Maxscaleのbinlogサーバーのみにサービスを提供することで、マスターの負荷を軽減します。
- 中間マスターのバイナリログのデータは、実際のマスターのバイナリログから受信したデータの直接コピーではありません。そのため、グループコミットを使用すると、コミットの並列処理が低下し、その後スレーブサーバーのパフォーマンスが低下する可能性があります。
- 中間スレーブは、すべてのSQLステートメントを再実行する必要があります。これにより、レプリケーションチェーンに遅延と遅延が追加される可能性があります。
このブログ投稿では、スケーラビリティとパフォーマンスを向上させるために、中間マスター(レプリケーションチェーン内の他のスレーブへのスレーブホストリレー)をMaxScaleで実行されているbinlogサーバーに置き換える方法を検討します。 。
基本的に、4ノードのMariaDB v10.4レプリケーションセットアップがあり、1つのMaxScalev2.3がレプリケーションの上に配置されて着信クエリを分散します。次の図に示すように、1つのスレーブのみがマスター(中間マスター)に接続され、他のスレーブは中間マスターから複製して読み取りワークロードを処理します。
上記のトポロジを次のように変換します:
基本的に、中間マスターの役割を削除して、次のように置き換えます。 MaxScaleで実行されているbinlogサーバー。中間マスターは、他のスレーブホストと同様に、標準のスレーブに変換されます。 binlogサービスは、MaxScaleホストのポート5306でリッスンします。これは、すべてのスレーブが後でレプリケーションのために接続するポートです。
この例では、アプリケーションのロードバランサーとして機能するレプリケーションクラスターの上にMaxScaleがすでに配置されています。 MaxScaleがない場合は、ClusterControlを使用してデプロイできます。[クラスターアクション]->[ロードバランサーの追加]->[MaxScale]に移動し、次のように必要な情報を入力します。
始める前に、現在のMaxScale構成をテキストファイルにエクスポートしましょう。バックアップ用。 MaxScaleには、この目的のために--export-configというフラグがありますが、maxscaleユーザーとして実行する必要があります。したがって、エクスポートするコマンドは次のとおりです。
$ su -s /bin/bash -c '/bin/maxscale --export-config=/tmp/maxscale.cnf' maxscale
MariaDBマスターで、MaxScaleで使用される「maxscale_slave」というレプリケーションスレーブユーザーを作成し、次の権限を割り当てます。
$ mysql -uroot -p -h192.168.0.91 -P3306
MariaDB> CREATE USER 'maxscale_slave'@'%' IDENTIFIED BY 'BtF2d2Kc8H';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.roles_mapping TO 'maxscale_slave'@'%';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale_slave'@'%';
MariaDB> GRANT REPLICATION SLAVE ON *.* TO 'maxscale_slave'@'%';
ClusterControlユーザーの場合は、[管理]-> [スキーマとユーザー]に移動して、必要な権限を作成します。
構成を進める前に、バックエンドサーバーの現在の状態とトポロジを確認することが重要です。
$ maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬──────────────────────────────┬───────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_757 │ 192.168.0.90 │ 3306 │ 0 │ Master, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_758 │ 192.168.0.91 │ 3306 │ 0 │ Relay Master, Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_759 │ 192.168.0.92 │ 3306 │ 0 │ Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_760 │ 192.168.0.93 │ 3306 │ 0 │ Slave, Running │ 0-38001-8 │
└────────┴──────────────┴──────┴─────────────┴──────────────────────────────┴───────────┘
ご覧のとおり、現在のマスターはDB_757(192.168.0.90)です。このマスターから複製するようにbinlogサーバーをセットアップするときに、この情報に注意してください。
/etc/maxscale.cnfにあるMaxScale構成ファイルを開き、次の行を追加します。
[replication-service]
type=service
router=binlogrouter
user=maxscale_slave
password=BtF2d2Kc8H
version_string=10.4.12-MariaDB-log
server_id=9999
master_id=9999
mariadb10_master_gtid=true
filestem=binlog
binlogdir=/var/lib/maxscale/binlogs
semisync=true # if semisync is enabled on the master
[binlog-server-listener]
type=listener
service=replication-service
protocol=MariaDBClient
port=5306
address=0.0.0.0
MaxScaleを再起動して、変更をロードします。
$ systemctl restart maxscale
binlogサービスがmaxctrlを介して開始されていることを確認します([状態]列を確認してください):
$ maxctrl show service replication-service
MaxScaleがbinlogサービスの新しいポートをリッスンしていることを確認します:
$ netstat -tulpn | grep maxscale
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 0.0.0.0:3307 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 0.0.0.0:5306 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 127.0.0.1:8989 0.0.0.0:* LISTEN 4850/maxscale
これで、MaxScaleとマスターの間にレプリケーションリンクを確立する準備が整いました。
MariaDBマスターサーバーにログインし、現在のbinlogファイルと位置を取得します。
MariaDB> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| binlog.000005 | 4204 | | |
+---------------+----------+--------------+------------------+
BINLOG_GTID_POS関数を使用してGTID値を取得します:
MariaDB> SELECT BINLOG_GTID_POS("binlog.000005", 4204);
+----------------------------------------+
| BINLOG_GTID_POS("binlog.000005", 4204) |
+----------------------------------------+
| 0-38001-31 |
+----------------------------------------+
MaxScaleサーバーに戻り、MariaDBクライアントパッケージをインストールします。
$ yum install -y mysql-client
maxscale_slaveユーザーとしてポート5306でbinlogサーバーリスナーに接続し、指定されたマスターへのレプリケーションリンクを確立します。マスターから取得したGTID値を使用します:
(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SET @@global.gtid_slave_pos = '0-38001-31';
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.90', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=3306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Binlog Dump
Master_Host: 192.168.0.90
Master_User: maxscale_slave
Master_Port: 3306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 38001
Master_Info_File: /var/lib/maxscale/binlogs/master.ini
Slave_SQL_Running_State: Slave running
Gtid_IO_Pos: 0-38001-31
注:上記の出力は、重要な行のみを表示するために切り捨てられています。
ここで、mariadb2とmariadb3(エンドスレーブ)で、MaxScalebinlogサーバーを指すマスターを変更します。半同期レプリケーションを有効にして実行しているため、最初にそれらをオフにする必要があります:
(mariadb2 & mariadb3)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.95
Master_User: maxscale_slave
Master_Port: 5306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 9999
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-38001-32
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
注:上記の出力は、重要な行のみを表示するために切り捨てられています。
my.cnf内で、将来的に半同期を無効にするには、次の行にコメントを付ける必要があります。
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ON
この時点で、他のスレーブがbinlogサーバーから複製している間、中間マスター(mariadb1)はまだマスター(mariadb0)から複製しています。現在のトポロジは、次の図のように説明できます。
最後の部分は、中間マスター(mariadb1)のマスターポインティングを変更することです。 )その後、それに接続していたすべてのスレーブはもう存在しません。手順は基本的に他のスレーブと同じです:
(mariadb1)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.95
Master_User: maxscale_slave
Master_Port: 5306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 9999
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-38001-32
注:上記の出力は、重要な行のみを表示するために切り捨てられています。
my.cnfでも半同期レプリケーションを無効にすることを忘れないでください:
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ON
maxctrl CLIを使用して、binlogルーターサービスの接続数が増えたことを確認できます:
$ maxctrl list services
┌─────────────────────┬────────────────┬─────────────┬───────────────────┬───────────────────────────────────┐
│ Service │ Router │ Connections │ Total Connections │ Servers │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rw-service │ readwritesplit │ 1 │ 1 │ DB_757, DB_758, DB_759, DB_760 │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rr-service │ readconnroute │ 1 │ 1 │ DB_757, DB_758, DB_759, DB_760 │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ replication-service │ binlogrouter │ 4 │ 51 │ binlog_router_master_host, DB_757 │
└─────────────────────┴────────────────┴─────────────┴───────────────────┴───────────────────────────────────┘
また、一般的なレプリケーション管理コマンドをMaxScale binlogサーバー内で使用できます。たとえば、次のコマンドを使用して、接続されているスレーブホストを確認できます。
(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SHOW SLAVE HOSTS;
+-----------+--------------+------+-----------+------------+
| Server_id | Host | Port | Master_id | Slave_UUID |
+-----------+--------------+------+-----------+------------+
| 38003 | 192.168.0.92 | 3306 | 9999 | |
| 38002 | 192.168.0.91 | 3306 | 9999 | |
| 38004 | 192.168.0.93 | 3306 | 9999 | |
+-----------+--------------+------+-----------+------------+
この時点で、トポロジは予想どおりになっています。
これで、中間マスターセットアップからbinlogサーバーセットアップへの移行が完了しました。