Ubuntu20.04でMySQLグループレプリケーションを構成する方法
序章
MySQLレプリケーションは、あるデータベースから別のデータベースにデータと操作を確実にミラーリングします。 従来のレプリケーションには、プライマリサーバーのログから独自のデータセットにアクションをコピーして適用するセカンダリサーバーとのデータベース書き込み操作を受け入れるように構成されたプライマリサーバーが含まれます。 これらのセカンダリサーバーは読み取りに使用できますが、通常はデータ書き込みを実行できません。
グループレプリケーションは、より柔軟でフォールトトレラントなレプリケーションメカニズムを実装する方法です。 このプロセスには、データが正しくコピーされるようにするためにそれぞれが関与するサーバーのプールを確立することが含まれます。 プライマリサーバーで問題が発生した場合、メンバーの選出により、グループから新しいプライマリを選択できます。 これにより、問題が発生した場合でも、残りのノードが動作を継続できます。 メンバーシップネゴシエーション、障害検出、およびメッセージ配信は、Paxosコンセンサスアルゴリズムの実装を通じて提供されます。
このチュートリアルでは、3台のUbuntu20.04サーバーのセットを使用してMySQLグループレプリケーションを設定します。 MySQLにグループレプリケーションをデプロイするために必要なMySQLインスタンスの最小数は3であり、最大数は9であることに注意してください。 このチュートリアルを実行すると、グループをシングルプライマリまたはマルチプライマリレプリケーショングループとして設定するオプションが表示されます。
注:データベースサーバーは、レプリケーションセットアップで2つの役割のいずれかを持つことができます。データベースサーバーは、プライマリインスタンス(ソースインスタンスとも呼ばれます)のいずれかです。ユーザーはデータを書き込むことができます。 またはreplica(またはセカンダリインスタンス)。これは、ソース上のすべてのデータのコピーを格納します。 歴史的に、これらの役割は、代わりにそれぞれマスターインスタンスおよびスレーブインスタンスと呼ばれてきました。 2020年7月に公開されたブログ投稿で、MySQLチームはこの用語の否定的な起源を認め、データベースプログラムとそのドキュメントをより包括的な言語を使用するように更新する取り組みを発表しました。
ただし、これは継続的なプロセスです。 MySQLのドキュメントとプログラムのバージョン8のコマンドの多くは更新されており、代わりにレプリケーショントポロジ内のサーバーをプライマリとそのセカンダリ(または ]sourceとそのreplicas)、否定的な用語がまだ表示されている場所があります。 このガイドでは、可能な限り、より包括的な用語がデフォルトで使用されますが、やむを得ず古い用語が使用される場合がいくつかあります。
前提条件
このガイドを完了するには、次のものが必要です。
- Ubuntu20.04を実行している3台のサーバー。 それぞれに、root以外の管理ユーザーが必要です。
sudo
特権とUFWで構成されたファイアウォール。 Ubuntu 20.04 の初期サーバーセットアップガイドに従って、各サーバーをセットアップします。 - MySQLが各サーバーにインストールされています。 このガイドは、デフォルトのUbuntuリポジトリから入手できる最新バージョンのMySQLを使用していることを前提としています。これは、この記事の執筆時点ではバージョン8.0.28です。 これをすべてのサーバーにインストールするには、各マシンの Ubuntu20.04にMySQLをインストールする方法に関するガイドに従ってください。
わかりやすくするために、このガイドでは3つのサーバーを member1 、 member2 、およびmember3と呼びます。 このガイド全体の例では、これらのメンバーは次のIPアドレスを持っています。
メンバー | IPアドレス |
---|---|
member1 | 203.0.113.1 |
member2 | 203.0.113.2 |
member3 | 203.0.113.3 |
member1 で実行する必要のあるコマンドは、次のように背景が青色になります。
-
同様に、member2で実行する必要のあるコマンドはすべて赤い背景になります。
-
また、member3で実行する必要のあるコマンドはすべて緑色の背景になります。
-
最後に、3台のサーバーのそれぞれで実行する必要のあるコマンドには標準のバックグラウンドがあります。
-
ステップ1—MySQLグループを識別するためのUUIDの生成
MySQL構成ファイルを開いてグループ複製設定を構成する前に、作成するMySQLグループを識別するために使用できるUUIDを生成する必要があります。
member1 で、 uuidgen
グループの有効なUUIDを生成するコマンド:
- uuidgen
Output168dcb64-7cce-473a-b338-6501f305e561
サーバーのプールのグループ名を構成するときにすぐにこれを参照する必要があるため、受け取った値をコピーします。
ステップ2—MySQL構成ファイルでグループレプリケーションを設定する
これで、MySQLの構成ファイルを変更する準備が整いました。 好みのテキストエディタを使用して、各MySQLサーバーでメインのMySQL構成ファイルを開きます。 ここでは、 nano
:
- sudo nano /etc/mysql/my.cnf
Ubuntuでは、MySQLには、さまざまな構成変更を定義するために使用できるさまざまなファイルがインストールされています。 デフォルトでは、 my.cnf
fileは、サブディレクトリから追加のファイルを調達するためにのみ使用されます。 の下に独自の構成を追加する必要があります !includedir
行。 これにより、含まれているファイルの設定を上書きできます。
まず、次のセクションを含めて新しいセクションを開始します [mysqld]
次の例で強調表示されているように、ヘッダーを作成してから、グループレプリケーションを有効にするために必要な設定を追加します。 これらの設定は、公式MySQLドキュメントで概説されているグループレプリケーションに必要な最小設定から変更されていることに注意してください。 The loose-
プレフィックスを使用すると、MySQLは、正常に認識されないオプションを失敗することなく処理できます。 これらの設定のいくつかをまもなく入力してカスタマイズする必要があります:
. . .
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
[mysqld]
# General replication settings
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
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 = ""
これらの構成オプションのすべてをより明確に説明するために、これらは次のサブセクションに分割されています。 一部のセクションでは、レプリケーショングループを展開する方法についての選択肢が示されているか、独自の構成に固有の詳細を入力する必要があるため、これらを注意深くお読みください。
ボイラープレートグループの複製設定
最初のセクションには、変更を必要としないグループレプリケーションに必要な一般的な設定が含まれています。
. . .
# General replication settings
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
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
. . .
MySQLでのグループレプリケーションの特定の要件の1つは、データをInnoDBストレージエンジンに保存する必要があることです。 MySQLのドキュメントでは、このセクションの最初のコメントされていない行のような方法でエラーを引き起こす可能性のある他のストレージエンジンの使用を明示的に無効にすることを推奨しています。
残りの設定では、グローバルトランザクションIDをオンにし、グループレプリケーションに必要なバイナリログを構成し、グループのSSLを構成します。 この構成では、リカバリとブートストラップに役立つ他のいくつかの項目も設定されます。 このセクションでは何も変更する必要はありません。3つのサーバーすべてで同一である必要があるため、追加した後で先に進むことができます。
共有グループレプリケーション設定
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 = "168dcb64-7cce-473a-b338-6501f305e561"
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は書き込み操作を処理する単一のプライマリサーバー(ほとんどの場合、最初のグループメンバー)を指定します。 マルチプライマリグループを使用すると、任意のグループメンバーが書き込みを実行できます。
マルチプライマリグループを構成する場合は、コメントを解除します。 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アドレスに追加されます。
例として、サンプルIPアドレスを使用したmember1の構成のこの部分を次に示します。
. . .
# 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サーバーでこのプロセスを完了します。 member2の構成は次のとおりです。
. . .
# Host specific replication configuration
server_id = 2
bind-address = "203.0.113.2"
report_host = "203.0.113.2"
loose-group_replication_local_address = "203.0.113.2:33061"
member3の構成は次のとおりです。
. . .
# Host specific replication configuration
server_id = 3
bind-address = "203.0.113.3"
report_host = "203.0.113.3"
loose-group_replication_local_address = "203.0.113.3:33061"
強調表示された各IPアドレスを、構成を編集しているサーバーのIPアドレスに更新してください。
終了したら、共有レプリケーション設定が各ホストで同じであること、およびホスト固有の設定がホストごとにカスタマイズされていることを再確認してください。 終了したら、各ホストでファイルを保存して閉じます。 使用した場合 nano
ファイルを編集するには、を押して編集できます CTRL + X
, Y
、 その後 ENTER
.
これで、各サーバーのMySQL構成ファイルに、MySQLグループレプリケーションをブートストラップするために必要なディレクティブが含まれます。 新しい設定をMySQLインスタンスに適用するには、次のコマンドを使用して、各サーバーでサービスを再起動します。
- sudo systemctl restart mysql
これで、各サーバーのファイアウォールルールを更新して、リモートアクセスの有効化に進むことができます。
ステップ3—各サーバーのUFWルールを更新する
前提条件初期サーバーセットアップガイドに従っていると仮定すると、MySQLをインストールし、 OpenSSH
UFWプロファイル。 これらのファイアウォールは現在、サーバー上の任意のポートへの接続をブロックしているため、これは重要なセキュリティ対策です。 ssh
各サーバーのそれぞれのキーと一致するキーを提示する接続 authorized_keys
ファイル。
MySQL構成ファイルで、デフォルトのポートで外部接続をリッスンするようにサービスを構成しました 3306
. あなたも定義しました 33061
メンバーがレプリケーション調整に使用する必要があるポートとして。
各メンバーサーバーで、このグループの他のメンバーが互いに通信できるように、これらのポートの両方へのアクセスを開く必要があります。 member2のmember1でこれらのポートへのアクセスを開くには、次を実行します ufw
member1 のコマンド:
- sudo ufw allow from member2_server_ip to any port 3306
- sudo ufw allow from member2_server_ip to any port 33061
必ず変更してください member2_server_ip
member2サーバーの実際のIPアドレスを反映します。 次に、 member3 の同じポートを開くには、次のコマンドを実行します。
- sudo ufw allow from member3_server_ip to any port 3306
- sudo ufw allow from member3_server_ip to any port 33061
次に、他の2台のサーバーのファイアウォールルールを更新します。 member2 で次のコマンドを実行し、member1とmember3のIPアドレスをそれぞれ反映するようにIPアドレスを変更してください。
- sudo ufw allow from member1_server_ip to any port 3306
- sudo ufw allow from member1_server_ip to any port 33061
- sudo ufw allow from member3_server_ip to any port 3306
- sudo ufw allow from member3_server_ip to any port 33061
最後に、member3でこれらの2つのコマンドを実行します。 繰り返しになりますが、各サーバーに正しいIPアドレスを入力していることを確認してください。
- sudo ufw allow from member1_server_ip to any port 3306
- sudo ufw allow from member1_server_ip to any port 33061
- sudo ufw allow from member2_server_ip to any port 3306
- sudo ufw allow from member2_server_ip to any port 33061
これらのUFWルールを追加すると、3つのMySQLインスタンスのそれぞれが、他の2つのサーバーでMySQLが使用するポートへのアクセスを許可されます。
MySQLポートへのアクセスが開いた状態で、レプリケーションユーザーを作成し、グループレプリケーションプラグインを有効にできます。
ステップ4—レプリケーションユーザーの設定とグループレプリケーションプラグインの有効化
レプリケーショングループ内の他のサーバーとの接続を確立するには、各MySQLインスタンスに専用のレプリケーションユーザーが必要です。
各MySQLサーバーで、管理ユーザーを使用してMySQLインスタンスにログインし、対話型セッションを開始します。
- sudo mysql
注:このセクションの各コマンドは、各MySQLインスタンスで必ず実行してください。
各サーバーには独自のレプリケーションユーザーが存在するため、作成プロセス中にバイナリロギングをオフにする必要があります。 そうしないと、レプリケーションが開始されると、グループはレプリケーションユーザーをプライマリサーバーから他のサーバーに伝播しようとし、既に配置されているレプリケーションユーザーとの競合を引き起こします。 各サーバーでMySQLプロンプトから次のコマンドを実行します。
- SET SQL_LOG_BIN=0;
今、あなたは実行することができます CREATE USER
レプリケーションユーザーを作成するステートメント。 次のコマンドを実行すると、という名前のユーザーが作成されます repl
. このコマンドは、レプリケーションユーザーがSSLを使用して接続する必要があることを指定します。 また、代わりに安全なパスワードを使用してください password
このレプリケーションユーザーを作成する場合:
- 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 REPLICATION SOURCE TO SOURCE_USER='repl', SOURCE_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
注:8.0.23より古いバージョンのMySQLを使用している場合、これを設定するにはMySQLのレガシー構文を使用する必要があります。
- CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
レプリケーションユーザーを配置すると、 group_replication
グループを初期化する準備をするプラグイン:
- INSTALL PLUGIN group_replication SONAME 'group_replication.so';
次のコマンドを実行して、プラグインがアクティブであることを確認します。
- SHOW PLUGINS;
The group_replication
プラグインは最近追加されたプラグインであるため、リストの一番下に表示されます。
Output+----------------------------+----------+--------------------+----------------------+---------+
| Name | Status | Type | Library | License |
+----------------------------+----------+--------------------+----------------------+---------+
| | | | | |
| . . . | . . . | . . . | . . . | . . . |
| | | | | |
| group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | GPL |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.00 sec)
この出力は、プラグインがロードされ、現在アクティブであることを確認します。 次のステップに進む前に、各MySQLインスタンスでこのセクションの各コマンドを実行したことを確認してください。
ステップ5—グループレプリケーションを開始する
これで、各MySQLサーバーにレプリケーションユーザーが構成され、グループレプリケーションプラグインが有効になりました。これで、グループの起動を開始できます。
最初のノードのブートストラップ
グループを起動するには、グループの単一メンバーで次の手順を実行します。 デモンストレーションの目的で、このガイドはmember1でこれらの手順を完了します
グループメンバーは、最初にグループに参加するときに、レプリケーションデータ、最新のメンバーシップリスト、およびその他の情報を送信するために既存のメンバーに依存しています。 このため、シードリスト内の他のメンバーからこの情報を期待しないように、最初のグループメンバーを起動するために少し異なる手順を使用する必要があります。
設定されている場合、 group_replication_bootstrap_group
変数は、ピアから情報を受け取ることを期待してはならず、代わりに新しいグループを確立して、それ自体をプライマリメンバーに選択する必要があることをメンバーに通知します。 この変数は、次のコマンドでオンにできます。
- SET GLOBAL group_replication_bootstrap_group=ON;
次に、最初のグループメンバーのレプリケーションを開始できます。
- START GROUP_REPLICATION;
その後、設定することができます group_replication_bootstrap_group
変数に戻る OFF
、これが適切な唯一の状況は、既存のグループメンバーがいない場合です。
- 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 | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1 | 3306 | ONLINE | PRIMARY | 8.0.28 | XCom |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
1 row in set (0.00 sec)
The ONLINE
の値 MEMBER_STATE
このノードがグループ内で完全に機能していることを示します。
次に、いくつかのサンプルデータを使用してテストデータベースとテーブルを作成します。 このグループにさらにメンバーが追加されると、このデータは自動的にそれらに複製されます。
名前の付いたサンプルデータベースを作成することから始めます playground
:
- CREATE DATABASE playground;
次に、という名前のサンプルテーブルを作成します equipment
以内 playground
次のコマンドを使用したデータベース:
- CREATE TABLE playground.equipment (
- id INT NOT NULL AUTO_INCREMENT,
- type VARCHAR(50),
- quant INT,
- color VARCHAR(25),
- PRIMARY KEY(id)
- );
このテーブルには、次の4つの列が含まれています。
id
:この列には、自動的に増分する整数値が含まれます。つまり、サンプルデータをテーブルにロードするときに、この列の値を指定する必要はありません。type
:この列には、行が表す遊具の種類を説明する文字列値が含まれますquant
:この列には、特定のタイプの遊具の数量を表す整数値が含まれますcolor
:この列には、特定の機器の色を指定する文字列値が保持されます
また、 id
列は、このテーブルの主キーとして指定されます。 MySQLでは、グループに複製されるすべてのテーブルには、テーブルの主キーとして指定された列が必要です。
最後に、次のコマンドを実行して、1行のデータをテーブルに挿入します。
- 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)
このサーバーがグループのメンバーであり、書き込み機能があることを確認した後、他のサーバーはグループに参加できます。
残りのノードの起動
次に、member2でグループレプリケーションを開始します。 すでにアクティブなメンバーがいるので、グループをブートストラップする必要はなく、このメンバーはすぐに参加できます。
- START GROUP_REPLICATION;
member3 で、同じ方法でグループレプリケーションを開始します。
- START GROUP_REPLICATION;
3台のサーバーのいずれかでメンバーシップリストを再度確認してください。 今回は、出力に3つのサーバーがリストされます。
- SELECT * FROM performance_schema.replication_group_members;
Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1 | 3306 | ONLINE | PRIMARY | 8.0.28 | XCom |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2 | 3306 | ONLINE | SECONDARY | 8.0.28 | XCom |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3 | 3306 | ONLINE | SECONDARY | 8.0.28 | XCom |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)
すべてのメンバーは MEMBER_STATE
の値 ONLINE
. 新しいグループの場合、ノードのいずれかが次のようにリストされている場合 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)
新しいメンバーでデータが利用できる場合は、グループレプリケーションが正しく機能していることを意味します。
ステップ6—新しいグループメンバーの書き込み機能をテストする
次に、新しいレプリケーショングループメンバーからデータベースへの書き込みを試すことができます。 これが成功するかどうかは、単一のプライマリグループまたはマルチプライマリグループのどちらを構成するかによって決まります。
単一のプライマリ環境での書き込みのテスト
単一のプライマリグループでは、一貫性の理由から、非プライマリサーバーからの書き込み操作が拒否されることを期待する必要があります。 レプリケーショングループの任意のメンバーに対して次のクエリを実行することにより、いつでも現在のプライマリを見つけることができます。
- 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
— member1 —現在プライマリサーバーです。 別のメンバーからデータベースに書き込もうとすると、操作は失敗します。
- 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)
変数が空の場合、これは指定されたプライマリホストがなく、すべてのメンバーが書き込みを受け入れることができる必要があることを意味します。
member2 でデータを書き込んで、これをテストします。 equipment
テーブル:
- INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");
OutputQuery OK, 1 row affected (0.00 sec)
member2はエラーなしで書き込み操作をコミットしました。
member3 で、次のクエリを実行して、新しいアイテムが追加されたかどうかを確認します。
- SELECT * FROM playground.equipment;
Output+----+-------+-------+--------+
| id | type | quant | color |
+----+-------+-------+--------+
| 1 | slide | 2 | blue |
| 2 | swing | 10 | yellow |
+----+-------+-------+--------+
2 rows in set (0.00 sec)
これにより、member2の書き込みが正常に複製されたことが確認されます。
次に、以下を実行して、member3の書き込み機能をテストします。 INSERT
声明:
- INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");
OutputQuery OK, 1 row affected (0.02 sec)
member1 に戻り、テストして、両方の新しいメンバーからの書き込み操作が複製されていることを確認します。
- 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)
これにより、レプリケーションが各方向で機能し、各メンバーが書き込み操作を実行できることが確認されます。
ステップ7—グループをバックアップする
グループがブートストラップされると、プライマリサーバーを選択するのに十分なメンバーがいる限り、個々のメンバーは可用性に影響を与えることなく参加および離脱できます。 ただし、特定の構成変更が行われた場合(シングルプライマリ環境とマルチプライマリ環境の切り替えなど)、またはグループのすべてのメンバーが離脱した場合は、最初に行ったのと同じ方法でグループを再ブートストラップする必要があります。
member1 で、 group_replication_bootstrap_group
に可変 ON
:
- SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=ON;
次に、グループを初期化します。
- START GROUP_REPLICATION;
その後、設定することができます group_replication_bootstrap_group
変数に戻る OFF
:
- 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)
このプロセスは、必要に応じてグループを再開するために使用できます。
ステップ8—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台のUbuntu20.04サーバー間でMySQLグループレプリケーションを構成する方法を学びました。 シングルプライマリ設定の場合、メンバーは必要に応じて書き込み可能なプライマリを自動的に選択します。 マルチプライマリグループの場合、すべてのメンバーが書き込みと更新を実行できます。
グループレプリケーションは、メンバーが自由に参加または離脱できるようにすると同時に、データの一貫性とメッセージの順序に関する保証を提供する柔軟なレプリケーショントポロジを提供します。 MySQLグループレプリケーションは、構成が少し複雑になる場合がありますが、従来のレプリケーションでは不可能な機能を提供します。