前書き
MySQLレプリケーションは、データベース間でデータと操作を確実にミラーリングします。 従来のレプリケーションでは、プライマリサーバーのログから独自のデータセットにアクションをコピーして適用するセカンダリサーバーでのデータベース書き込み操作を受け入れるように構成されたプライマリサーバーが必要です。 これらのセカンダリサーバーは読み取りに使用できますが、通常はデータ書き込みを実行できません。
グループレプリケーションは、より柔軟でフォールトトレラントなレプリケーションメカニズムを実装する方法です。 このプロセスには、データが正しくコピーされるようにするためのサーバープールの確立が含まれます。 プライマリサーバーで問題が発生した場合、メンバーの選択により、グループから新しいプライマリを選択できます。 これにより、問題が発生した場合でも、残りのノードは動作を継続できます。 メンバーシップネゴシエーション、障害検出、およびメッセージ配信は、Paxos concensus algorithmの実装を通じて提供されます。
このチュートリアルでは、3台のUbuntu 16.04サーバーのセットを使用してMySQLグループのレプリケーションをセットアップします。 この構成では、単一のプライマリレプリケーショングループまたはマルチプライマリレプリケーショングループを操作する方法について説明します。
前提条件
これに従うには、3つのUbuntu 16.04サーバーのグループが必要になります。 これらの各サーバーで、sudo特権を持つroot以外のユーザーをセットアップし、基本的なファイアウォールを構成する必要があります。 initial server setup guide for Ubuntu 16.04を使用してこれらの要件を満たし、各サーバーを準備完了状態にします。
UbuntuのデフォルトリポジトリにあるMySQLのバージョンには、必要なグループレプリケーションプラグインは含まれていません。 ありがたいことに、MySQLプロジェクトは、このコンポーネントを含む最新のMySQLバージョンの独自のリポジトリを保持しています。 installing the latest MySQL on Ubuntu 16.04に関するガイドに従って、グループレプリケーション対応バージョンのMySQLを各サーバーにインストールします。
MySQLグループを識別するUUIDを生成します
MySQL構成ファイルを開いてグループ複製設定を構成する前に、作成するMySQLグループを識別するために使用できるUUIDを生成する必要があります。
mysqlmember1で、uuidgenコマンドを使用して、グループの有効なUUIDを生成します。
uuidgenOutput959cf631-538c-415d-8164-ca00181be227受け取った値をコピーします。 サーバーのプールのグループ名を構成するときに、これをすぐに参照する必要があります。
MySQL構成ファイルでのグループレプリケーションのセットアップ
これで、MySQLの構成ファイルを変更する準備が整いました。 each MySQL serverでメインのMySQL構成ファイルを開きます。
sudo nano /etc/mysql/my.cnfデフォルトでは、このファイルはサブディレクトリから追加のファイルを入手するためにのみ使用されます。 独自の構成beneath、!includedir行を追加する必要があります。 これにより、含まれているファイルの設定を簡単にオーバーライドできます。
まず、[mysqld]ヘッダーを含めて、MySQLサーバーコンポーネントのセクションを開きます。 この下に、グループの複製に必要な設定を貼り付けます。 loose-プレフィックスを使用すると、MySQLは、認識できないオプションを失敗せずに正常に処理できます。 これらの設定の多くをすぐに入力してカスタマイズする必要があります。
/etc/mysql/my.cnf
. . .
!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つのセクションに分割しました。 それではそれらを見ていきましょう。
定型グループのレプリケーション設定
最初のセクションには、変更を必要としないグループ複製に必要な一般設定が含まれています。
/etc/mysql/my.cnf
. . .
# 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を、uuidgenコマンドで以前に生成したUUIDに設定します。 コピーしたUUIDをこの変数の値として貼り付けます。
次に、loose-group_replication_ip_whitelistをすべてのMySQLサーバーIPアドレスのリストにコンマで区切って設定します。 loose-group_replication_group_seeds設定はホワイトリストとほぼ同じである必要がありますが、使用するグループレプリケーションポートを各メンバーの最後に追加する必要があります。 このガイドでは、グループレプリケーションに33061の推奨ポートを使用します。
/etc/mysql/my.cnf
. . .
# 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行をコメントのままにしてください。
/etc/mysql/my.cnf
. . .
# 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
-
バインドするアドレス
-
他のメンバーに報告するアドレス
-
ローカル複製アドレスとリスニングポート
server_idディレクティブは一意の番号に設定する必要があります。 最初のメンバーについては、これを「1」に設定し、追加するホストごとに番号を増やします。 bind-addressとreport_hostを現在のサーバーのIPアドレスに設定して、MySQLインスタンスが外部接続をリッスンし、そのアドレスを他のホストに正しく報告するようにします。 loose-group_replication_local_addressは、IPアドレスに追加されたグループレプリケーションポート（33061）を使用して現在のサーバーのIPアドレスにも設定する必要があります。
/etc/mysql/my.cnf
. . .
# 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インスタンスに適用するには、次のコマンドを使用してeach of your serversでサービスを再起動します。
sudo systemctl restart mysqlMySQL構成ファイルで、デフォルトポート3306で外部接続をリッスンするようにサービスを構成しました。 また、メンバーがレプリケーション調整に使用するポートとして33061を定義しました。
ファイアウォールでこれらの2つのポートへのアクセスを開く必要があります。これは次のように入力することで実行できます。
sudo ufw allow 33061
sudo ufw allow 3306MySQLポートへのアクセスを開いて、レプリケーションユーザーを作成し、グループレプリケーションプラグインを有効にすることができます。
レプリケーションユーザーの構成とグループレプリケーションプラグインの有効化
each of your MySQL serversで、管理ユーザーを使用してMySQLインスタンスにログインし、対話型セッションを開始します。
mysql -u root -pMySQL管理パスワードの入力を求められます。 その後、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)group_replication行は、プラグインがロードされ、現在アクティブであることを確認します。
グループレプリケーションを開始する
各MySQLサーバーでレプリケーションユーザーが構成され、グループレプリケーションプラグインが有効になったので、グループを立ち上げることができます。
ブートストラップの最初のノード
グループを起動するには、a single member of the groupで次の手順を実行します。
グループメンバーは、最初にグループに参加するときに、既存のメンバーに依存して、レプリケーションデータ、最新のメンバーシップリスト、およびその他の情報を送信します。 このため、最初のグループメンバーを起動するために、少し異なる手順を使用して、シードリスト内の他のメンバーからこの情報を期待しないようにする必要があります。
設定されている場合、group_replication_bootstrap_group変数は、ピアからの情報の受信を期待してはならず、代わりに新しいグループを確立して、それ自体をプライマリメンバーに選択する必要があることをメンバーに通知します。 これが適切な唯一の状況は、既存のグループメンバーが存在しない場合だけなので、グループをブートストラップした直後にこの機能をオフにします。
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;このサーバーを唯一のメンバーとしてグループを開始する必要があります。 これは、performance_schemaデータベースのreplication_group_membersテーブル内のエントリを確認することで確認できます。
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)MEMBER_STATEのONLINE値は、このノードがグループ内で完全に機能していることを示します。
次に、テストデータベースとテーブルを作成して、レプリケーションをテストします。
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)このサーバーがグループのメンバーであり、書き込み機能があることを確認しました。 これで、他のサーバーがグループに参加できます。
残りのノードの起動
次に、second serverで、グループレプリケーションを開始します。 既にアクティブなメンバーがいるので、グループをブートストラップする必要はなく、グループに参加するだけです。
START GROUP_REPLICATION;third serverで、同じ方法でグループレプリケーションを開始します。
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)すべてのメンバーは、ONLINEのMEMBER_STATE値を持つ必要があります。 新しいグループの場合、ノードのいずれかが1〜2秒以上RECOVERINGとしてリストされている場合は、通常、エラーが発生したか、何かが正しく構成されていないことを示しています。 /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)変数が空の場合、これは、指定されたプライマリホストがなく、メンバーが書き込みを受け入れることができることを意味します。
次のように入力して、second serverでこれをテストします。
INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");OutputQuery OK, 1 row affected (0.00 sec)2番目のサーバーは、エラーなしで書き込み操作をコミットしました。
third serverで、新しいアイテムが追加されたことを確認するためにクエリを実行します。
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)first serverに戻り、テストして、両方の新しいメンバーからの書き込み操作が複製されたことを確認します。
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)これにより、レプリケーションが各方向で機能し、各メンバーが書き込み操作を実行できることが確認されます。
グループをバックアップする
グループがブートストラップされると、プライマリサーバーを選出するのに十分なメンバーがいる限り、個々のメンバーは可用性に影響を与えることなく参加および離脱できます。 ただし、特定の構成の変更（単一プライマリ環境とマルチプライマリ環境の切り替えなど）が行われた場合、またはグループのすべてのメンバーが離脱した場合、グループを再ブートストラップする必要があります。 これは、最初に行ったのとまったく同じ方法で行います。
first serverで、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」に設定します。
/etc/mysql/my.cnf
[mysqld]
. . .
loose-group_replication_start_on_boot = ON
. . .完了したら、ファイルを保存して閉じます。 メンバーは、MySQLインスタンスが次に起動されたときに、グループへの参加を自動的に試みる必要があります。
結論
このチュートリアルでは、3つのUbuntu 16.04サーバー間でMySQLグループのレプリケーションを構成する方法について説明しました。 単一のプライマリセットアップの場合、メンバーは必要に応じて書き込み可能なプライマリを自動的に選択します。 マルチプライマリグループの場合、すべてのメンバーが書き込みと更新を実行できます。
グループレプリケーションは、メンバーが自由に参加または離脱できる柔軟なレプリケーショントポロジを提供すると同時に、データの一貫性とメッセージの順序に関する保証を提供します。 MySQLグループのレプリケーションは、構成が少し複雑になる場合がありますが、従来のレプリケーションでは不可能な機能を提供します。