MySQLでレプリケーションを設定する方法

投稿日: 2022-04-20 2022-04-20
タグ: mysql

このチュートリアルの以前のバージョンは、 EtelSverdlovによって作成されました。

序章

データベースを操作するときは、データの複数のコピーがあると便利です。これにより、データベースサーバーの1つに障害が発生した場合に冗長性が提供され、データベースの可用性、スケーラビリティ、および全体的なパフォーマンスが向上します。複数の個別のデータベース間でデータを同期する方法は、レプリケーションと呼ばれます。

MySQL はリレーショナルデータベース管理システムであり、今日世界で最も人気のあるオープンソースのリレーショナルデータベースです。多数の組み込みレプリケーション機能がインストールされているため、データの複数のコピーを維持できます。

このチュートリアルでは、あるサーバー上のMySQLインスタンスをソースデータベースとして構成し、次に別のサーバー上のMySQLインスタンスをそのレプリカとして機能するように構成する方法の概要を説明します。また、MySQLがレプリケーションを処理する方法の概要も含まれています。

注：これまで、このタイプのデータベースレプリケーションは「マスタースレーブ」レプリケーションと呼ばれていました。 2020年7月に公開されたブログ投稿で、MySQLチームはこの用語の否定的な起源を認め、データベースプログラムとそのドキュメントをより包括的な言語を使用するように更新する取り組みを発表しました。

ただし、これは継続的なプロセスです。 MySQLのドキュメントとプログラムのバージョン8のコマンドの多くは更新され、代わりにレプリケーショントポロジ内のサーバーをソースとそのレプリカとして参照するようになりました。 ]、否定的な用語がまだ表示されている場所があります。このガイドでは、可能な限り、より包括的な source-replica の用語がデフォルトになりますが、やむを得ず古い用語が使用される場合がいくつかあります。

前提条件

このガイドを完了するには、次のものが必要です。

Ubuntu20.04を実行している2台のサーバー。どちらにも、sudo権限を持つ非ルート管理ユーザーと、UFWで構成されたファイアウォールが必要です。 Ubuntu 20.04 の初期サーバーセットアップガイドに従って、両方のサーバーをセットアップします。
MySQLが各サーバーにインストールされています。このガイドは、デフォルトのUbuntuリポジトリから入手できる最新バージョンのMySQLを使用していることを前提としています。これは、この記事の執筆時点では、バージョン8.0.25です。これを両方のサーバーにインストールするには、 Ubuntu20.04にMySQLをインストールする方法に関するガイドに従ってください。

このガイドで概説されている手順では、一方のサーバーへのMySQLインストールをソースデータベースとして指定し、もう一方のサーバーへのMySQLインストールをソースのレプリカとして構成する必要があることに注意してください。わかりやすくするために、ソースデータベースのサーバーで実行する必要のあるコマンドは、次のように青い背景になります。

同様に、レプリカMySQLインスタンスのサーバーで実行する必要のあるコマンドはすべて赤い背景になります。

最後に、このチュートリアルには、既存のデータベースのデータをソースからレプリカに移行する方法に関するオプションの手順が含まれています。このプロセスには、ソースのデータベースのスナップショットを作成し、結果のファイルをレプリカにコピーすることが含まれます。これを行うには、ソースサーバーサーバーにSSHキーを設定してから、ソースの公開キーがレプリカにコピーされていることを確認することをお勧めします。

MySQLでのレプリケーションを理解する

MySQLでは、レプリケーションには、バイナリログと呼ばれる特別なファイルに1つ以上のデータベース内に保持されているデータに加えられたすべての変更を書き留めるソースデータベースが含まれます。レプリカインスタンスが初期化されると、2つのスレッド化されたプロセスが作成されます。 1つ目はIOスレッドと呼ばれ、ソースMySQLインスタンスに接続し、バイナリログイベントを1行ずつ読み取り、レプリカのサーバー上のリレーログと呼ばれるローカルファイルにコピーします。 。 SQLスレッドと呼ばれる2番目のスレッドは、リレーログからイベントを読み取り、それらを可能な限り高速にレプリカインスタンスに適用します。

MySQLの最近のバージョンは、データを複製するための2つの方法をサポートしています。これらのレプリケーション方法の違いは、レプリカが既に処理したソースからのデータベースイベントを追跡する方法に関係しています。

MySQLは、従来のレプリケーション方法をバイナリログファイルの位置ベースのレプリケーションと呼んでいます。このメソッドを使用してMySQLインスタンスをレプリカに変換する場合は、バイナリログ座標のセットをインスタンスに提供する必要があります。これらは、レプリカが読み取る必要のあるソース上のバイナリログファイルの名前と、レプリカが自身のMySQLインスタンスにコピーする必要がある最初のデータベースイベントを表すそのファイル内の特定の位置で構成されます。

レプリカはソースのバイナリログ全体のコピーを受け取り、正しい座標がないと、その中に記録されているすべてのデータベースイベントの複製を開始するため、これらの座標は重要です。これは、特定の時点以降にのみデータを複製する場合、またはソースのデータのサブセットのみを複製する場合に問題を引き起こす可能性があります。

バイナリログファイルの位置ベースのレプリケーションは、多くのユースケースで実行可能ですが、この方法は、より複雑なセットアップでは扱いにくくなる可能性があります。これにより、MySQLの新しいネイティブレプリケーション方式が開発されました。これは、トランザクションベースのレプリケーションと呼ばれることもあります。この方法では、ソースMySQLインスタンスが実行するトランザクションごとにグローバルトランザクション識別子（GTID）を作成するか、データベースによって実行される分離された作業を作成します。

トランザクションベースのレプリケーションの仕組みは、バイナリログファイルベースのレプリケーションに似ています。データベーストランザクションがソースで発生するたびに、MySQLはトランザクションのGTIDを割り当てて、トランザクション自体とともにバイナリログファイルに記録します。次に、GTIDとトランザクションがソースのレプリカに送信され、処理されます。

MySQLのトランザクションベースのレプリケーションには、従来のレプリケーション方法に比べて多くの利点があります。たとえば、ソースとそのレプリカの両方がGTIDを保持するため、ソースまたはレプリカのいずれかが、処理したGTIDとのトランザクションに遭遇した場合、そのトランザクションをスキップします。これは、ソースとそのレプリカ間の一貫性を確保するのに役立ちます。さらに、トランザクションベースのレプリケーションレプリカでは、処理する次のデータベースイベントのバイナリログ座標を知る必要はありません。これは、新しいレプリカの開始やレプリケーションチェーン内のレプリカの順序の変更がはるかに簡単であることを意味します。

これは、MySQLがレプリケーションを処理する方法の一般的な説明にすぎないことに注意してください。 MySQLには、独自のレプリケーション設定を最適化するために微調整できる多くのオプションが用意されています。このガイドでは、バイナリログファイルの位置ベースのレプリケーションを設定する方法の概要を説明します。ただし、別のタイプのレプリケーション環境の構成に関心がある場合は、MySQLの公式ドキュメントを確認することをお勧めします。

ステップ1—ソースサーバーのファイアウォールを調整する

前提条件初期サーバーセットアップガイドに従っていると仮定すると、UFWを使用して両方のサーバーにファイアウォールを構成していることになります。これは両方のサーバーを安全に保つのに役立ちますが、ソースのファイアウォールはレプリカMySQLインスタンスからの接続試行をブロックします。

これを変更するには、レプリカからソースのファイアウォールを介した接続を許可するUFWルールを含める必要があります。これを行うには、ソースサーバーで次ののようなコマンドを実行します。

この特定のコマンドは、レプリカサーバーのIPアドレス（replica_server_ipで表される）からMySQLのデフォルトのポート番号3306への接続を許可します。

sudo ufw allow from replica_server_ip to any port 3306

必ずreplica_server_ipをレプリカサーバーの実際のIPアドレスに置き換えてください。ルールが正常に追加された場合は、次の出力が表示されます。

OutputRule added

その後、レプリカサーバーは着信接続を受信せず、ソースMySQLサーバーへの発信接続はUFWによってブロックされないため、レプリカのファイアウォールルールを変更する必要はありません。ソースMySQLインスタンスの構成を更新して、レプリケーションを有効にすることができます。

ステップ2—ソースデータベースの構成

ソースMySQLデータベースがデータの複製を開始するには、その構成にいくつかの変更を加える必要があります。

Ubuntu 20.04では、デフォルトのMySQLサーバー構成ファイルの名前はmysqld.cnfで、/etc/mysql/mysql.conf.d/ディレクトリにあります。このファイルをソースサーバーでお好みのテキストエディタで開きます。ここでは、nanoを使用します。

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

ファイル内で、bind-addressディレクティブを見つけます。デフォルトでは次のようになります。

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
bind-address            = 127.0.0.1
. . .

127.0.0.1は、 localhost を表すIPv4ループバックアドレスであり、これをbind-addressディレクティブの値として設定すると、MySQLはlocalhost[での接続のみをリッスンするように指示されます。 X199X]アドレス。つまり、このMySQLインスタンスは、インストールされているサーバーから発信された接続のみを受け入れることができます。

他のMySQLインスタンスをこのインスタンスのレプリカに変換していることを忘れないでください。そのため、レプリカは、ソースインストールに書き込まれる新しいデータを読み取ることができる必要があります。これを可能にするには、ソースサーバーのパブリックIPアドレスなど、レプリカが到達できるIPアドレスで接続をリッスンするようにソースMySQLインスタンスを構成する必要があります。

127.0.0.1を送信元サーバーのIPアドレスに置き換えます。そうすると、bind-addressディレクティブは次のようになり、source_server_ipの代わりに独自のサーバーのIPアドレスが使用されます。

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
bind-address            = source_server_ip
. . .

次に、server-idディレクティブを見つけます。これは、MySQLがレプリケーションセットアップでサーバーを区別するために内部的に使用する識別子を定義します。ソースとそのすべてのレプリカを含むレプリケーション環境のすべてのサーバーには、独自のserver-id値が必要です。このディレクティブはデフォルトでコメント化され、次のようになります。

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
# server-id             = 1
. . .

ポンド記号（#）を削除して、この行のコメントを解除します。このディレクティブの値として任意の数値を選択できますが、数値は一意である必要があり、レプリケーショングループ内の他のserver-idと一致することはできないことに注意してください。簡単にするために、次の例では、この値をデフォルトの1のままにします。

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
server-id               = 1
. . .

server-id行の下で、log_binディレクティブを見つけます。これは、MySQLのバイナリログファイルのベース名と場所を定義します。

コメントアウトすると、このディレクティブはデフォルトであるため、バイナリロギングは無効になります。レプリカサーバーは、ソースのデータをいつどのように複製するかを認識できるように、ソースのバイナリログファイルを読み取る必要があるため、この行のコメントを解除して、ソースでバイナリログを有効にします。そうすると、次のようになります。

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
log_bin                       = /var/log/mysql/mysql-bin.log
. . .

最後に、ファイルの一番下までスクロールして、コメントアウトされたbinlog_do_dbディレクティブを見つけます。

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
# binlog_do_db          = include_database_name

ポンド記号を削除してこの行のコメントを解除し、include_database_nameを複製するデータベースの名前に置き換えます。この例は、dbという名前のデータベースを指すbinlog_do_dbディレクティブを示していますが、複製するソースに既存のデータベースがある場合は、[X192Xの代わりにその名前を使用してください]：

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
binlog_do_db          = db

注：複数のデータベースを複製する場合は、追加するデータベースごとに別のbinlog_do_dbディレクティブを追加できます。このチュートリアルでは、引き続き1つのデータベースのみを複製しますが、さらに複製したい場合は、次のようになります。

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
binlog_do_db          = db
binlog_do_db          = db_1
binlog_do_db          = db_2

または、各データベースにbinlog_ignore_dbディレクティブを追加して、MySQLが複製しないデータベースを指定できます。

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
binlog_ignore_db          = db_to_ignore

これらの変更を行った後、ファイルを保存して閉じます。 nanoを使用してファイルを編集した場合は、CTRL + X、Y、ENTERの順に押して編集します。

次に、次のコマンドを実行してMySQLサービスを再起動します。

sudo systemctl restart mysql

これで、このMySQLインスタンスは、他のMySQLサーバーが複製するソースデータベースとして機能する準備が整いました。ただし、レプリカを構成する前に、レプリケーショントポロジが正しく機能することを確認するために、ソースで実行する必要のある手順がいくつかあります。これらの最初のものは、レプリケーションプロセスに関連するアクションを実行する専用のMySQLユーザーを作成することです。

手順3—レプリケーションユーザーの作成

MySQLレプリケーション環境の各レプリカは、ユーザー名とパスワードを使用してソースデータベースに接続します。レプリカは、ソースデータベースに存在し、適切な権限を持つ任意のMySQLユーザープロファイルを使用して接続できますが、このチュートリアルでは、この目的のために専用ユーザーを作成する方法の概要を説明します。

MySQLシェルを開くことから始めます。

sudo mysql

注：パスワードを使用して認証する専用のMySQLユーザーを構成した場合は、代わりに次のようなコマンドを使用してMySQLに接続できます。

mysql -u sammy -p

sammyを専用ユーザーの名前に置き換え、プロンプトが表示されたらこのユーザーのパスワードを入力します。

レプリカサーバーで実行する必要のあるいくつかの操作を含む、このガイド全体の一部の操作には、高度な特権が必要であることに注意してください。このため、前のsudo mysqlコマンドと同様に、管理ユーザーとして接続する方が便利な場合があります。ただし、このガイド全体で特権の低いMySQLユーザーを使用する場合は、少なくともCREATE USER、RELOAD、REPLICATION CLIENT、REPLICATION SLAVEを付与する必要があります。、およびREPLICATION_SLAVE_ADMIN特権。

プロンプトから、新しいMySQLユーザーを作成します。次の例では、 reply_user という名前のユーザーを作成しますが、任意の名前を付けることができます。必ずreplica_server_ipをレプリカサーバーのパブリックIPアドレスに変更し、passwordを選択した強力なパスワードに変更してください。

CREATE USER 'replica_user'@'replica_server_ip' IDENTIFIED WITH mysql_native_password BY 'password';

このコマンドは、reply_userがmysql_native_password認証プラグインを使用することを指定していることに注意してください。代わりに、MySQLのデフォルトの認証メカニズムであるcaching_sha2_passwordを使用することもできますが、これには、ソースとレプリカの間に暗号化された接続を設定する必要があります。この種のセットアップは実稼働環境に最適ですが、暗号化された接続の構成はこのチュートリアルの範囲を超えています。 MySQLのドキュメントには、これを設定する場合に暗号化された接続を使用するレプリケーション環境を構成する方法の説明が含まれています。

新しいユーザーを作成したら、適切な権限をユーザーに付与します。少なくとも、MySQLレプリケーションユーザーはREPLICATION SLAVE権限を持っている必要があります。

GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'replica_server_ip';

これに続いて、FLUSH PRIVILEGESコマンドを実行することをお勧めします。これにより、前述のCREATE USERおよびGRANTステートメントの結果としてサーバーがキャッシュしたメモリが解放されます。

FLUSH PRIVILEGES;

これで、ソースMySQLインスタンスでのレプリケーションユーザーの設定が完了しました。ただし、はMySQLシェルを終了しないでください。次のステップでソースデータベースのバイナリログファイルに関する重要な情報を取得するために使用するため、今は開いたままにしておきます。

ステップ4—ソースからバイナリログ座標を取得する

MySQLでのレプリケーションについてセクションを思い出してください。MySQLは、ソースのバイナリログファイルからデータベースイベントを1行ずつコピーし、レプリカに各イベントを実装することでレプリケーションを実装します。 MySQLのバイナリログファイルの位置ベースのレプリケーションを使用する場合は、ソースのバイナリログファイルの名前とそのファイル内の特定の位置を詳細に示す一連の座標をレプリカに提供する必要があります。次に、レプリカはこれらの座標を使用して、データベースイベントのコピーを開始するログファイル内のポイントを決定し、すでに処理したイベントを追跡します。

この手順では、ログファイルの最新のポイントからデータの複製を開始するようにレプリカを設定するために、ソースインスタンスの現在のバイナリログ座標を取得する方法の概要を説明します。座標の取得中にユーザーがデータを変更しないようにするには、問題が発生する可能性があります。データベースをロックして、座標を取得するときにクライアントがデータを読み書きできないようにする必要があります。間もなくすべてのロックを解除しますが、この手順により、データベースである程度のダウンタイムが発生します。

前の手順の最後から、ソースサーバーのMySQLシェルを開いたままにしておく必要があります。プロンプトから、次のコマンドを実行します。これにより、ソースインスタンス上のすべてのデータベースで開いているすべてのテーブルが閉じられ、ロックされます。

FLUSH TABLES WITH READ LOCK;

次に、次の操作を実行して、ソースのバイナリログファイルの現在のステータス情報を返します。

SHOW MASTER STATUS;

出力には、次の例に似た表が表示されます。

Output+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      899 | db           |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

これは、レプリカがデータベースイベントのコピーを開始する位置です。 Fileの名前とPositionの値を記録します。これらは、後でレプリケーションを開始するときに必要になるためです。

この情報を取得した直後に行うことは、ソースデータベースにレプリカに移行する既存のデータがあるかどうかによって異なります。次の2つのサブセクションのうち、状況に最も適したものにジャンプします。

ソースに移行する既存のデータがない場合

ソースMySQLインスタンスが新規インストールであるか、レプリカに移行する既存のデータがない場合は、この時点でテーブルのロックを解除できます。

UNLOCK TABLES;

まだ作成していない場合は、MySQLシェルを開いたまま、複製するように選択したデータベースを作成できます。手順2の例に従って、次の操作でdbという名前のデータベースが作成されます。

CREATE DATABASE db;

OutputQuery OK, 1 row affected (0.01 sec)

その後、MySQLシェルを閉じます。

exit

その後、次のステップに進むことができます。

ソースに移行する既存のデータがある場合

レプリカに移行するソースMySQLインスタンスにデータがある場合は、mysqldumpユーティリティを使用してデータベースのスナップショットを作成することで移行できます。ただし、データベースは現在もロックされているはずです。同じウィンドウで新しい変更を加えると、データベースは自動的にロック解除されます。同様に、クライアントを終了すると、テーブルは自動的にロック解除されます。

テーブルのロックを解除すると、クライアントがデータベース内のデータを再度変更する可能性があるため、問題が発生する可能性があります。これにより、データスナップショットと取得したばかりのバイナリログ座標が一致しない可能性があります。

このため、ローカルマシンで新しいターミナルウィンドウまたはタブを開く必要があります。これにより、MySQLのロックを解除せずにデータベーススナップショットを作成できます。

新しいターミナルウィンドウまたはタブから、ソースMySQLインスタンスをホストしているサーバーへの別のSSHセッションを開きます。

ssh sammy@source_server_ip

次に、新しいタブまたはウィンドウから、mysqldumpを使用してデータベースをエクスポートします。次の例では、dbという名前のデータベースからdb.sqlという名前のダンプファイルを作成しますが、代わりに独自のデータベースの名前を含めるようにしてください。また、このコマンドは、MySQLシェルではなく、bashシェルで実行してください。

sudo mysqldump -u root db > db.sql

その後、このターミナルウィンドウまたはタブを閉じて、最初のターミナルウィンドウに戻ることができます。これにより、MySQLシェルが開いたままになります。 MySQLプロンプトから、データベースのロックを解除して、データベースを再度書き込み可能にします。

UNLOCK TABLES;

次に、MySQLシェルを終了できます。

exit

これで、スナップショットファイルをレプリカサーバーに送信できます。ソースサーバーでSSHキーを構成し、レプリカのauthorized_keysファイルにソースの公開キーを追加したとすると、次のようなscpコマンドを使用してこれを安全に行うことができます。これ：

scp db.sql sammy@replica_server_ip:/tmp/

必ずsammyをレプリカサーバーで作成した管理用Ubuntuユーザープロファイルの名前に置き換え、replica_server_ipをレプリカサーバーのIPアドレスに置き換えてください。また、このコマンドは、レプリカサーバーの/tmp/ディレクトリにスナップショットを配置することに注意してください。

スナップショットをレプリカサーバーに送信した後、SSHで接続します。

ssh sammy@replica_server_ip

次に、MySQLシェルを開きます。

sudo mysql

プロンプトから、ソースから複製する新しいデータベースを作成します。

CREATE DATABASE db;

テーブルを作成したり、このデータベースにサンプルデータをロードしたりする必要はありません。作成したスナップショットを使用してデータベースをインポートすると、すべて処理されます。代わりに、MySQLシェルを終了します。

exit

次に、データベーススナップショットをインポートします。

sudo mysql db < /tmp/db.sql

これで、レプリカにソースデータベースの既存のデータがすべて含まれます。このガイドの最後のステップを完了して、ソースデータベースで行われた新しい変更の複製を開始するようにレプリカサーバーを構成できます。

ステップ5—レプリカデータベースの設定

あとは、ソースの構成と同じようにレプリカの構成を変更するだけです。 MySQL構成ファイルmysqld.cnfを開きます。今回は、レプリカサーバーでを開きます。

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

前述のように、レプリケーション設定の各MySQLインスタンスには、一意のserver-id値が必要です。レプリカのserver-idディレクティブを見つけてコメントを外し、ソースの値と異なる限り、その値を任意の正の整数に変更します。

/etc/mysql/mysql.conf.d/mysqld.cnf

server-id               = 2

その後、log_binとbinlog_do_dbの値を更新して、ソースマシンの構成ファイルで設定した値と一致するようにします。

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
log_bin                 = /var/log/mysql/mysql-bin.log
. . .
binlog_do_db            = db
. . .

最後に、レプリカのリレーログファイルの場所を定義するrelay-logディレクティブを追加します。構成ファイルの最後に次の行を含めます。

/etc/mysql/mysql.conf.d/mysqld.cnf

. . .
relay-log               = /var/log/mysql/mysql-relay-bin.log

これらの変更を行った後、ファイルを保存して閉じます。次に、レプリカでMySQLを再起動して、新しい構成を実装します。

sudo systemctl restart mysql

mysqlサービスを再起動すると、ソースデータベースからのデータの複製を開始する準備が整います。

ステップ6—レプリケーションの開始とテスト

この時点で、両方のMySQLインスタンスがレプリケーションを許可するように完全に構成されています。ソースからデータの複製を開始するには、レプリカサーバーでMySQLシェルを開きます。

sudo mysql

プロンプトから、次の操作を実行します。これにより、複数のMySQLレプリケーション設定が同時に構成されます。このコマンドを実行した後、このインスタンスでレプリケーションを有効にすると、SOURCE_USERとSOURCE_PASSWORDにそれぞれ続くユーザー名とパスワードを使用して、SOURCE_HOSTに続くIPアドレスに接続しようとします。また、SOURCE_LOG_FILEに続く名前のバイナリログファイルを検索し、SOURCE_LOG_POSの後の位置から読み取りを開始します。

必ずsource_server_ipをソースサーバーのIPアドレスに置き換えてください。同様に、replica_userおよびpasswordは、手順2で作成したレプリケーションユーザーと一致している必要があります。 mysql-bin.000001および899は、手順3で取得したバイナリログ座標を反映している必要があります。

レプリカサーバーで実行する前に、テキストエディタでこのコマンドを入力して、関連するすべての情報をより簡単に置き換えることができます。

CHANGE REPLICATION SOURCE TO
SOURCE_HOST='source_server_ip',
SOURCE_USER='replica_user',
SOURCE_PASSWORD='password',
SOURCE_LOG_FILE='mysql-bin.000001',
SOURCE_LOG_POS=899;

その後、レプリカサーバーをアクティブ化します。

START REPLICA;

すべての詳細を正しく入力すると、このインスタンスは、ソース上のdbデータベースに加えられた変更の複製を開始します。

次の操作を実行すると、レプリカの現在の状態の詳細を確認できます。このコマンドの\G修飾子は、テキストを再配置して読みやすくします。

SHOW REPLICA STATUS\G;

このコマンドは、トラブルシューティングの際に役立つ多くの情報を返します。

Output*************************** 1. row ***************************
             Replica_IO_State: Waiting for master to send event
                  Source_Host: 138.197.3.190
                  Source_User: replica_user
                  Source_Port: 3306
                Connect_Retry: 60
              Source_Log_File: mysql-bin.000001
          Read_Source_Log_Pos: 1273
               Relay_Log_File: mysql-relay-bin.000003
                Relay_Log_Pos: 729
        Relay_Source_Log_File: mysql-bin.000001
. . .

注：レプリカに接続の問題があるか、レプリケーションが予期せず停止する場合は、ソースのバイナリログファイルのイベントがレプリケーションを妨げている可能性があります。このような場合、SET GLOBAL SQL_SLAVE_SKIP_COUNTERコマンドを実行して、前のコマンドで定義したバイナリログファイルの位置に続く特定の数のイベントをスキップできます。この例では、最初のイベントのみをスキップします。

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

その後、レプリカを再起動する必要があります。

START REPLICA;

また、レプリケーションを停止する必要がある場合は、レプリカインスタンスで次の操作を実行することで停止できることに注意してください。

STOP REPLICA;

これで、レプリカはソースからデータを複製しています。ソースデータベースに加えた変更は、レプリカMySQLインスタンスに反映されます。これをテストするには、ソースデータベースにサンプルテーブルを作成し、それが正常にレプリケートされるかどうかを確認します。

ソースマシンでMySQLシェルを開くことから始めます。

sudo mysql

複製することを選択したデータベースを選択します。

USE db;

次に、そのデータベース内にテーブルを作成します。次のSQL操作は、example_columnという名前の1つの列を持つexample_tableという名前のテーブルを作成します。

CREATE TABLE example_table (
example_column varchar(30)
);

OutputQuery OK, 0 rows affected (0.03 sec)

必要に応じて、このテーブルにサンプルデータを追加することもできます。

INSERT INTO example_table VALUES
('This is the first row'),
('This is the second row'),
('This is the third row');

OutputQuery OK, 3 rows affected (0.03 sec)
Records: 3  Duplicates: 0  Warnings: 0

テーブルを作成し、オプションでサンプルデータを追加した後、レプリカサーバーのMySQLシェルに戻り、レプリケートされたデータベースを選択します。

USE db;

次に、SHOW TABLESステートメントを実行して、選択したデータベース内のすべてのテーブルを一覧表示します。

SHOW TABLES;

レプリケーションが正しく機能している場合は、このコマンドの出力にリストされているソースに追加したばかりのテーブルが表示されます。

Output+---------------+
| Tables_in_db  |
+---------------+
| example_table |
+---------------+
1 row in set (0.00 sec)

また、ソースのテーブルにサンプルデータを追加した場合は、次のようなクエリを使用して、そのデータも複製されたかどうかを確認できます。

SELECT * FROM example_table;

SQLでは、アスタリスク（*）は省略形の「すべての列」です。したがって、このクエリは基本的に、example_tableからすべての列を返すようにMySQLに指示します。レプリケーションが期待どおりに機能している場合、この操作はそのデータを出力に返します。

Output+------------------------+
| example_column         |
+------------------------+
| This is the first row  |
| This is the second row |
| This is the third row  |
+------------------------+
3 rows in set (0.00 sec)

これらの操作のいずれかが、ソースに追加したサンプルテーブルまたはデータを返さない場合は、レプリケーション構成のどこかにエラーがある可能性があります。このような場合は、SHOW REPLICA STATUS\G操作を実行して、問題の原因を特定してみてください。さらに、レプリケーションの問題を解決する方法の提案については、MySQLのレプリケーションのトラブルシューティングに関するドキュメントを参照してください。

結論

このチュートリアルを完了すると、1つのソースと1つのレプリカでMySQLのバイナリログファイルの位置ベースのレプリケーション方法を使用するMySQLレプリケーション環境がセットアップされます。ただし、このガイドで概説されている手順は、MySQLでレプリケーションを構成する1つの方法にすぎないことに注意してください。 MySQLには、ニーズに最適化されたレプリケーション環境を作成するために使用できるさまざまなレプリケーションオプションが用意されています。 Galera Cluster など、MySQLの組み込みレプリケーション機能を拡張するために使用できるサードパーティツールも多数あります。

MySQLのレプリケーションの特定の機能についてさらに質問がある場合は、MySQLの主題に関する公式ドキュメントを確認することをお勧めします。 MySQL全般について詳しく知りたい場合は、MySQL関連コンテンツのライブラリ全体を確認することもできます。

getdocs

13036