Ubuntu16.04でMySQLグループレプリケーションを構成する方法
序章
MySQLレプリケーションは、あるデータベースから別のデータベースにデータと操作を確実にミラーリングします。 従来のレプリケーションには、プライマリサーバーのログから独自のデータセットにアクションをコピーして適用するセカンダリサーバーとのデータベース書き込み操作を受け入れるように構成されたプライマリサーバーが含まれます。 これらのセカンダリサーバーは読み取りに使用できますが、通常はデータ書き込みを実行できません。
グループレプリケーションは、より柔軟でフォールトトレラントなレプリケーションメカニズムを実装する方法です。 このプロセスには、データが正しくコピーされるようにするためにそれぞれが関与するサーバーのプールを確立することが含まれます。 プライマリサーバーで問題が発生した場合、メンバーの選出により、グループから新しいプライマリを選択できます。 これにより、問題が発生した場合でも、残りのノードが動作を継続できます。 メンバーシップネゴシエーション、障害検出、およびメッセージ配信は、Paxosコンセンサスアルゴリズムの実装を通じて提供されます。
このチュートリアルでは、3台のUbuntu16.04サーバーのセットを使用してMySQLグループレプリケーションを設定します。 構成では、単一のプライマリまたはマルチプライマリレプリケーショングループを操作する方法について説明します。
前提条件
フォローするには、3台のUbuntu16.04サーバーのグループが必要です。 これらの各サーバーで、root以外のユーザーを設定する必要があります。 sudo
特権を設定し、基本的なファイアウォールを構成します。 Ubuntu 16.04 の初期サーバーセットアップガイドを使用して、これらの要件を満たし、各サーバーを準備完了状態にします。
UbuntuのデフォルトリポジトリにあるMySQLのバージョンには、必要なグループレプリケーションプラグインが含まれていません。 ありがたいことに、MySQLプロジェクトは、このコンポーネントを含む最新のMySQLバージョン用に独自のリポジトリを維持しています。 最新のMySQLをUbuntu16.04にインストールするガイドに従って、グループレプリケーション対応バージョンのMySQLを各サーバーにインストールします。
MySQLグループを識別するためのUUIDを生成する
MySQL構成ファイルを開いてグループレプリケーション設定を構成する前に、作成するMySQLグループを識別するために使用できるUUIDを生成する必要があります。
mysqlmember1 では、 uuidgen
グループの有効なUUIDを生成するコマンド:
- uuidgen
Output959cf631-538c-415d-8164-ca00181be227
受け取った値をコピーします。 サーバーのプールのグループ名を構成するときに、これをすぐに参照する必要があります。
MySQL構成ファイルでグループレプリケーションを設定する
これで、MySQLの構成ファイルを変更する準備が整いました。 各MySQLサーバーでメインのMySQL構成ファイルを開きます。
- sudo nano /etc/mysql/my.cnf
デフォルトでは、このファイルはサブディレクトリから追加のファイルを調達するためにのみ使用されます。 独自の構成の下を追加する必要があります !includedir
行。 これにより、含まれているファイルの設定を簡単に上書きできます。
まず、MySQLサーバーコンポーネントのセクションを開きます。 [mysqld]
ヘッダ。 この下に、グループレプリケーションに必要な設定を貼り付けます。 The loose-
プレフィックスを使用すると、MySQLは、失敗せずに正常に認識されないオプションを正常に処理できます。 これらの設定の多くをすぐに入力してカスタマイズする必要があります。
. . .
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
[mysqld]
# General replication settings
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_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1
# Shared replication group configuration
loose-group_replication_group_name = ""
loose-group_replication_ip_whitelist = ""
loose-group_replication_group_seeds = ""
# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON
# Host specific replication configuration
server_id =
bind-address = ""
report_host = ""
loose-group_replication_local_address = ""
上記の構成を4つのセクションに分割しました。 今それらを調べてみましょう。
ボイラープレートグループの複製設定
最初のセクションには、変更を必要としないグループレプリケーションに必要な一般的な設定が含まれています。
. . .
# General replication settings
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_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1
. . .
これらの設定は、グローバルトランザクションIDをオンにし、グループレプリケーションに必要なバイナリログを構成し、グループのSSLを構成します。 この構成では、リカバリとブートストラップに役立つ他のいくつかの項目も設定されます。 このセクションでは何も変更する必要がないため、貼り付けてから先に進むことができます。
共有グループレプリケーション設定
2番目のセクションでは、グループの共有設定を設定します。 これを一度カスタマイズしてから、各ノードで同じ設定を使用する必要があります。 これには、グループのUUID、受け入れ可能なメンバーのホワイトリスト、および初期データを取得するために連絡するシードメンバーが含まれます。
をセットする loose-group_replication_group_name
以前に生成したUUIDに uuidgen
指図。 コピーしたUUIDをこの変数の値として貼り付けます。
次に、設定します loose-group_replication_ip_whitelist
すべてのMySQLサーバーのIPアドレスをコンマで区切って一覧表示します。 The loose-group_replication_group_seeds
設定はホワイトリストとほぼ同じである必要がありますが、使用するグループレプリケーションポートを各メンバーの最後に追加する必要があります。 このガイドでは、グループレプリケーションに推奨ポート33061を使用します。
. . .
# Shared replication group configuration
loose-group_replication_group_name = "959cf631-538c-415d-8164-ca00181be227"
loose-group_replication_ip_whitelist = "203.0.113.1,203.0.113.2,203.0.113.3"
loose-group_replication_group_seeds = ""203.0.113.1:33061,203.0.113.2:33061,203.0.113.3:33061"
. . .
このセクションは、各MySQLサーバーで同じである必要があるため、慎重にコピーしてください。
シングルプライマリまたはマルチプライマリの選択
次に、シングルプライマリグループとマルチプライマリグループのどちらを構成するかを決定する必要があります。 MySQLの公式ドキュメントの一部では、この区別は「シングル」レプリケーションと「マルチマスター」レプリケーションとも呼ばれます。 単一のプライマリ構成では、MySQLは書き込み操作を処理する単一のプライマリサーバー(ほとんどの場合、最初のグループメンバー)を指定します。 マルチプライマリグループでは、任意のグループメンバーへの書き込みが可能です。
マルチプライマリグループを構成する場合は、コメントを解除します。 loose-group_replication_single_primary_mode
と loose-group_replication_enforce_update_everywhere_checks
ディレクティブ。 これにより、マルチプライマリグループが設定されます。 単一のプライマリグループの場合は、次の2行にコメントを付けたままにします。
. . .
# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON
. . .
これらの設定は、各MySQLサーバーで同じである必要があります。
この設定は後で変更できますが、MySQLグループを再起動せずに変更することはできません。 新しい構成に切り替えるには、グループ内の各MySQLインスタンスを停止し、新しい設定で各メンバーを起動してから、グループレプリケーションを再ブートストラップする必要があります。 これはデータに影響を与えませんが、ダウンタイムの小さなウィンドウが必要です。
ホスト固有の構成設定
4番目のセクションには、次のような各サーバーで異なる設定が含まれています。
- サーバーID
- バインドするアドレス
- 他のメンバーに報告するアドレス
- ローカルレプリケーションアドレスとリスニングポート
The server_id
ディレクティブは一意の番号に設定する必要があります。 最初のメンバーの場合は、これを「1」に設定し、追加のホストごとに番号を増やします。 設定 bind-address
と report_host
MySQLインスタンスが外部接続をリッスンし、そのアドレスを他のホストに正しく報告するように、現在のサーバーのIPアドレスに接続します。 The loose-group_replication_local_address
また、IPアドレスに追加されたグループレプリケーションポート(33061)を使用して、現在のサーバーのIPアドレスに設定する必要があります。
. . .
# Host specific replication configuration
server_id = 1
bind-address = "203.0.113.1"
report_host = "203.0.113.1"
loose-group_replication_local_address = "203.0.113.1:33061"
各MySQLサーバーでこのプロセスを完了します。
終了したら、共有レプリケーション設定が各ホストで同じであること、およびホスト固有の設定がホストごとにカスタマイズされていることを再確認してください。 終了したら、各ホストでファイルを保存して閉じます。
MySQLを再起動し、リモートアクセスを有効にします
MySQL構成ファイルには、MySQLグループレプリケーションをブートストラップするために必要なディレクティブが含まれています。 新しい設定をMySQLインスタンスに適用するには、次のコマンドを使用して、各サーバーでサービスを再起動します。
- sudo systemctl restart mysql
MySQL構成ファイルでは、デフォルトのポート3306で外部接続をリッスンするようにサービスを構成しました。 また、メンバーがレプリケーション調整に使用する必要があるポートとして33061を定義しました。
ファイアウォールでこれら2つのポートへのアクセスを開く必要があります。これは、次のように入力することで実行できます。
- sudo ufw allow 33061
- sudo ufw allow 3306
MySQLポートへのアクセスを開いた状態で、レプリケーションユーザーを作成し、グループレプリケーションプラグインを有効にすることができます。
レプリケーションユーザーを構成し、グループレプリケーションプラグインを有効にする
各MySQLサーバーで、管理ユーザーを使用してMySQLインスタンスにログインし、対話型セッションを開始します。
- mysql -u root -p
MySQL管理者パスワードの入力を求められます。 その後、MySQLセッションにドロップされます。 最初に行う必要があるのは、レプリケーションユーザーを作成することです。
グループレプリケーションを確立するには、各サーバーにレプリケーションユーザーが必要です。 各サーバーには独自のレプリケーションユーザーが存在するため、作成プロセス中にバイナリロギングをオフにする必要があります。 そうしないと、レプリケーションが開始されると、グループはレプリケーションユーザーをプライマリサーバーから他のサーバーに伝播しようとし、既に配置されているレプリケーションユーザーとの競合を引き起こします。
レプリケーションユーザーにSSLが必要であり、サーバーでのレプリケーション権限を付与してから、権限をフラッシュして変更を実装します。 その後、バイナリロギングを再度有効にして、通常の操作を再開します。 レプリケーションユーザーを作成するときは、必ず安全なパスワードを使用してください。
- SET SQL_LOG_BIN=0;
- CREATE USER 'repl'@'%' IDENTIFIED BY 'password' REQUIRE SSL;
- GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
- FLUSH PRIVILEGES;
- SET SQL_LOG_BIN=1;
次に、を設定する必要があります group_replication_recovery
新しいレプリケーションユーザーと関連するパスワードを使用するチャネル。 次に、各サーバーはこれらの資格情報を使用してグループへの認証を行います。
- CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
レプリケーションユーザーを配置すると、グループレプリケーションプラグインがグループの初期化の準備を行えるようになります。 最新バージョンのMySQLを使用しているため、次のように入力してプラグインを有効にできます。
- INSTALL PLUGIN group_replication SONAME 'group_replication.so';
次のように入力して、プラグインがアクティブであることを確認します。
- SHOW PLUGINS;
Output+----------------------------+----------+--------------------+----------------------+---------+
| Name | Status | Type | Library | License |
+----------------------------+----------+--------------------+----------------------+---------+
| | | | | |
| . . . | . . . | . . . | . . . | . . . |
| | | | | |
| group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | GPL |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.00 sec)
The group_replication
行は、プラグインがロードされ、現在アクティブであることを確認します。
グループレプリケーションを開始する
各MySQLサーバーでレプリケーションユーザーが構成され、グループレプリケーションプラグインが有効になっているので、グループの起動を開始できます。
ブートストラップの最初のノード
グループを起動するには、グループの単一メンバーで次の手順を実行します。
グループメンバーは、最初にグループに参加するときに、レプリケーションデータ、最新のメンバーシップリスト、およびその他の情報を送信するために既存のメンバーに依存しています。 このため、シードリスト内の他のメンバーからこの情報を期待しないように、最初のグループメンバーを起動するために少し異なる手順を使用する必要があります。
設定されている場合、 group_replication_bootstrap_group
変数は、ピアから情報を受け取ることを期待してはならず、代わりに新しいグループを確立して、それ自体をプライマリメンバーに選択する必要があることをメンバーに通知します。 これが適切な唯一の状況は、既存のグループメンバーがいない場合であるため、グループをブートストラップした直後にこの機能をオフにします。
- SET GLOBAL group_replication_bootstrap_group=ON;
- START GROUP_REPLICATION;
- SET GLOBAL group_replication_bootstrap_group=OFF;
グループは、このサーバーを唯一のメンバーとして開始する必要があります。 これは、内のエントリを確認することで確認できます。 replication_group_members
のテーブル performance_schema
データベース:
- SELECT * FROM performance_schema.replication_group_members;
現在のホストを表す単一の行が表示されます。
Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1 | 3306 | ONLINE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
1 row in set (0.00 sec)
The ONLINE
の値 MEMBER_STATE
このノードがグループ内で完全に機能していることを示します。
次に、レプリケーションをテストするためのテストデータベースとテーブルを作成します。
- CREATE DATABASE playground;
- CREATE TABLE playground.equipment ( id INT NOT NULL AUTO_INCREMENT, type VARCHAR(50), quant INT, color VARCHAR(25), PRIMARY KEY(id));
- INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");
コンテンツをチェックして、正しく入力されていることを確認してください。
- SELECT * FROM playground.equipment;
Output+----+-------+-------+-------+
| id | type | quant | color |
+----+-------+-------+-------+
| 1 | slide | 2 | blue |
+----+-------+-------+-------+
1 row in set (0.00 sec)
これで、このサーバーがグループのメンバーであり、書き込み機能があることを確認しました。 これで、他のサーバーがグループに参加できるようになります。
残りのノードを起動します
次に、 2番目のサーバーで、グループレプリケーションを開始します。 すでにアクティブなメンバーがいるので、グループをブートストラップする必要はなく、グループに参加するだけです。
- START GROUP_REPLICATION;
3番目のサーバーで、同じ方法でグループレプリケーションを開始します。
- START GROUP_REPLICATION;
メンバーシップリストをもう一度確認してください。 これで、3つのサーバーが表示されます。
- SELECT * FROM performance_schema.replication_group_members;
Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1 | 3306 | ONLINE |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2 | 3306 | ONLINE |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3 | 3306 | ONLINE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)
すべてのメンバーは MEMBER_STATE
の値 ONLINE
. 新しいグループの場合、ノードのいずれかが次のようにリストされている場合 RECOVERING
1〜2秒以上は、通常、エラーが発生したか、何かが正しく構成されていないことを示しています。 でログを確認してください /var/log/mysql/error.log
何が悪かったかについての追加情報を取得します。
テストデータベース情報が新しいメンバーに複製されているかどうかを確認します。
- SELECT * FROM playground.equipment;
Output+----+-------+-------+-------+
| id | type | quant | color |
+----+-------+-------+-------+
| 1 | slide | 2 | blue |
+----+-------+-------+-------+
1 row in set (0.01 sec)
新しいメンバーでデータが利用できる場合は、グループレプリケーションが正しく機能していることを意味します。
新しいグループメンバーの書き込み機能のテスト
次に、新しいメンバーからデータベースへの書き込みを試みることができます。 これが成功するかどうかは、単一のプライマリグループまたはマルチプライマリグループのどちらを構成するかによって決まります。
単一のプライマリ環境での書き込みのテスト
単一のプライマリグループでは、一貫性の理由から、非プライマリサーバーからの書き込み操作が拒否されることを期待する必要があります。 次のクエリを使用して、いつでも現在のプライマリを見つけることができます。
- SHOW STATUS LIKE '%primary%';
Output+----------------------------------+--------------------------------------+
| Variable_name | Value |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |
+----------------------------------+--------------------------------------+
1 row in set (0.01 sec)
クエリの値は MEMBER_ID
以前と同じようにグループメンバーリストをクエリすることで、ホストと照合できます。
- SELECT * FROM performance_schema.replication_group_members;
Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1 | 3306 | ONLINE |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2 | 3306 | ONLINE |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3 | 3306 | ONLINE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)
この例では、ホストが 203.0.113.1
現在、プライマリサーバーです。 別のメンバーからデータベースに書き込もうとすると、操作が失敗することが予想されます。
- INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");
OutputERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement
グループは現在、単一の書き込み可能なプライマリで構成されているため、これは予想されます。 プライマリサーバーに問題があり、グループを離れると、グループは自動的に新しいメンバーをプライマリとして選択し、書き込みを受け入れます。
マルチプライマリ環境での書き込みのテスト
マルチプライマリ指向で構成されたグループの場合、すべてのメンバーがデータベースへの書き込みをコミットできる必要があります。
の値をチェックすることにより、グループがマルチプライマリモードで動作していることを再確認できます。 group_replication_primary_member
再び変数:
- SHOW STATUS LIKE '%primary%';
Output+----------------------------------+-------+
| Variable_name | Value |
+----------------------------------+-------+
| group_replication_primary_member | |
+----------------------------------+-------+
1 row in set (0.02 sec)
変数が空の場合、これは指定されたプライマリホストがなく、すべてのメンバーが書き込みを受け入れることができる必要があることを意味します。
次のように入力して、2番目のサーバーでこれをテストします。
- INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");
OutputQuery OK, 1 row affected (0.00 sec)
2番目のサーバーは、エラーなしで書き込み操作をコミットしました。
3番目のサーバーで、新しいアイテムが追加されたことを確認するためにクエリを実行します。
- SELECT * FROM playground.equipment;
Output+----+-------+-------+--------+
| id | type | quant | color |
+----+-------+-------+--------+
| 1 | slide | 2 | blue |
| 2 | swing | 10 | yellow |
+----+-------+-------+--------+
2 rows in set (0.00 sec)
これにより、2番目のサーバーの書き込みが正常に複製されたことが確認されます。
次に、次のように入力して、3番目のサーバーで書き込み機能をテストします。
- INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");
OutputQuery OK, 1 row affected (0.02 sec)
最初のサーバーに戻り、テストして、両方の新しいメンバーからの書き込み操作が複製されていることを確認します。
- SELECT * FROM playground.equipment;
Output+----+--------+-------+--------+
| id | type | quant | color |
+----+--------+-------+--------+
| 1 | slide | 2 | blue |
| 2 | swing | 10 | yellow |
| 3 | seesaw | 3 | green |
+----+--------+-------+--------+
3 rows in set (0.01 sec)
これにより、レプリケーションが各方向で機能し、各メンバーが書き込み操作を実行できることが確認されます。
グループをバックアップする
グループがブートストラップされると、プライマリサーバーを選択するのに十分なメンバーがいる限り、個々のメンバーは可用性に影響を与えることなく参加および離脱できます。 ただし、特定の構成変更が行われた場合(シングルプライマリ環境とマルチプライマリ環境の切り替えなど)、またはグループのすべてのメンバーが離脱した場合は、グループを再ブートストラップする必要があります。 これは、最初に行ったのとまったく同じ方法で行います。
最初のサーバーで、 group_replciation_bootstrap_group
変数を入力してから、グループの初期化を開始します。
- SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=ON;
- START GROUP_REPLICATION;
- SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=OFF;
最初のメンバーがグループを開始すると、他のメンバーが参加できます。
- START GROUP_REPLICATION;
追加のメンバーについては、次のプロセスに従ってください。
- START GROUP_REPLICATION;
これで、グループがオンラインになり、すべてのメンバーが利用可能になります。
- SELECT * FROM performance_schema.replication_group_members;
Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1 | 3306 | ONLINE |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2 | 3306 | ONLINE |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3 | 3306 | ONLINE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)
このプロセスは、必要に応じてグループを再開するために使用できます。
MySQLの起動時に自動的にグループに参加する
現在の設定では、メンバーサーバーが再起動しても、起動時にグループに自動的に再参加することはありません。 メンバーが自動的にグループに再参加するようにする場合は、構成ファイルを少し変更できます。
ここで概説する設定は、メンバーが起動時に自動的に参加するようにする場合に役立ちます。 ただし、次の点に注意する必要があります。
まず、この設定は、MySQLインスタンス自体が起動されたときにのみ影響します。 タイムアウトの問題のためにメンバーがグループから削除されたが、MySQLインスタンスがオンラインのままである場合、メンバーは自動的に再参加しません。
次に、グループを最初にブートストラップするときにこの設定を有効にすると、害を及ぼす可能性があります。 参加する既存のグループがない場合、MySQLプロセスは、他の存在しないメンバーに接続して初期化しようとするため、開始に長い時間がかかります。 長いタイムアウトの後でのみ、それはあきらめて正常に開始します。 その後、上記の手順を使用してグループをブートストラップする必要があります。
上記の注意事項を念頭に置いて、MySQLの起動時にノードがグループに自動的に参加するように構成する場合は、メインのMySQL構成ファイルを開きます。
- sudo nano /etc/mysql/my.cnf
内部で、 loose-group_replication_start_on_boot
変数を設定し、「ON」に設定します。
[mysqld]
. . .
loose-group_replication_start_on_boot = ON
. . .
終了したら、ファイルを保存して閉じます。 メンバーは、次にMySQLインスタンスが開始されたときに、自動的にグループへの参加を試みる必要があります。
結論
このチュートリアルでは、3台のUbuntu16.04サーバー間でMySQLグループレプリケーションを構成する方法について説明しました。 シングルプライマリセットアップの場合、メンバーは必要に応じて書き込み可能なプライマリを自動的に選択します。 マルチプライマリグループの場合、すべてのメンバーが書き込みと更新を実行できます。
グループレプリケーションは、メンバーが自由に参加または離脱できるようにすると同時に、データの一貫性とメッセージの順序に関する保証を提供する柔軟なレプリケーショントポロジを提供します。 MySQLグループレプリケーションは、構成が少し複雑になる場合がありますが、従来のレプリケーションでは不可能な機能を提供します。