序文
以下のコンテンツは、MySQL5.7の公式ドキュメントに基づいています。
Mysqlレプリケーション
1つのMySQLデータベースサーバー（ソース）から1つ以上のMySQLデータベースサーバー（レプリカ）にデータをコピーできます。デフォルトでは、レプリケーションは非同期であり、パフォーマンスが向上します。ソースから更新を受信するためにレプリカを永続的に接続する必要はありません。構成に応じて、データベース内のすべてのデータベース、選択したデータベース、さらには選択したテーブルをコピーできます。
MySQLでのレプリケーションの利点は次のとおりです。
- スケールアウトソリューション-パフォーマンスを向上させるために、負荷を複数のコピーに分散します。この環境では、すべての書き込みと更新はレプリケーションソースサーバー（プライマリサーバー）で実行する必要があります。ただし、読み取りは1つ以上のレプリカ（スレーブサーバー）で発生する場合があります。このモデルは、書き込みパフォーマンスを向上させることができますが（ソースは更新専用であるため）、レプリカの読み取り速度を大幅に向上させることができます。
- データセキュリティ-データがコピーにコピーされており、コピーによってコピープロセスが一時停止される可能性があるため、対応するソースデータを破棄することなく、コピーに対してバックアップサービスを実行できます。
- 分析-ソース上でリアルタイムデータを作成でき、ソースのパフォーマンスに影響を与えることなく、コピーに対して情報分析を実行できます。
- リモートデータ配布-レプリケーションを使用して、ソースに永続的にアクセスしなくても、リモートサイトで使用するデータのローカルコピーを作成できます。
MySQL 5.7は、さまざまなレプリケーション方法をサポートしています。従来の方法は、ソースバイナリログ内のイベントのコピーに基づいており、ログファイルとその場所をソースとコピーの間で同期する必要があります。グローバルトランザクション識別子（GTID）に基づく新しい方法であり、トランザクションであるため、ログファイルやこれらのファイル内の場所を処理する必要がなく、多くの一般的なレプリケーションタスクが大幅に簡素化されます。レプリケーションにGTIDを使用すると、ソースでコミットされたすべてのトランザクションがレプリカにも適用されている限り、ソースとレプリカの間の整合性を確保できます。
MySQLのレプリケーションは、さまざまなタイプの同期をサポートしています。元のタイプの同期は一方向の非同期レプリケーションであり、1つのサーバーがソースとして機能し、1つ以上の他のサーバーがレプリカとして機能します。これは、NDBクラスターの同期レプリケーション機能とは逆です。MySQL 5.7では、組み込みの非同期レプリケーションに加えて、準同期レプリケーションもサポートしています。準同期レプリケーションの場合、トランザクションを実行したセッションに戻る前に、少なくとも1つのレプリカがトランザクションイベントを受信して記録したことを確認するまで、ソースブロックでコミットが実行されます。MySQL5.7は遅延レプリケーションもサポートしているため、レプリカはソースで指定された時間の後コピーを作成します。同期レプリケーションが必要なシナリオでは、NDBクラスターを使用してください
レプリケーション形式には、SQLステートメント全体をレプリケートするステートメントベースのレプリケーション（SBR）と、変更された行のみをレプリケートする行ベースのレプリケーション（RBR）の2つのコアタイプがあります。3番目のタイプのハイブリッドハイブリッドレプリケーション（MBR）を使用することもできます。
レプリケーションを使用して、パフォーマンス、さまざまなデータベースのバックアップのサポートなど、さまざまな問題を解決したり、システム障害を軽減するためのより大きなソリューションの一部として使用したりできます。
バイナリログファイルの場所に基づくレプリケーション
このセクションでは、バイナリログファイルの場所の方法に基づくMySQLサーバー間のレプリケーションを紹介します。このレプリケーション方法では、ソースMySQLインスタンス（データベースの変更はこのインスタンスから発生します）が更新と変更を「イベント」としてバイナリログに書き込みます。バイナリログの情報は、記録されたデータベースの変更に応じて、さまざまなログレコード形式で保存されます。ソースからバイナリログを読み取り、レプリカのローカルデータベースのバイナリログでイベントを実行するようにレプリカを構成します。
各コピーは、バイナリログの内容全体のコピーを受け取ります。コピーは、バイナリログのどのステートメントを実行するかを決定する責任があります。特に指定しない限り、ソースバイナリログのすべてのイベントはコピーで実行されます。必要に応じて、特定のデータベースまたはテーブルに適用されるイベントのみを処理するようにレプリカを構成できます。
各コピーは、バイナリログ座標を記録します。ソースから読み取られて処理されたファイルの名前と、ファイル内のファイルの場所です。これは、複数のコピーをソースに接続して、同じバイナリログの異なる部分を実行できることを意味します。レプリカがこのプロセスを制御するため、ソースの動作に影響を与えることなく、サーバーから単一のレプリカを接続および切断することができます。同様に、各コピーは現在の位置をバイナリログに記録するため、コピーを切断して再接続し、処理を再開できます。
ソースと各レプリカに一意のIDを構成する必要があります（server_idシステム変数を使用）。さらに、コピーごとに、ソースホスト名、ログファイル名、およびファイル内の場所に関する情報を構成する必要があります。コピーでCHANGEMASTER TOステートメントを使用して、MySQLセッションでこれらの詳細を制御できます。
注：コピーソースはマスターデータベース（マスター）を表し、コピーはスレーブデータベース（スレーブ）を表します。
関連する構成をコピーする
以下では、バイナリログファイルレプリケーションに基づく基本的な構成を紹介します。これを読むと、明確に理解して構成できます。
レプリケーションソース構成を設定します
バイナリログファイルの場所に基づいてレプリケーションを使用するようにソースを構成するには、バイナリログが有効になっていることを確認し、一意のサーバーIDを確立する必要があります。
レプリケーショントポロジ内の各サーバーは、server_idシステム変数を使用して指定できる一意のサーバーIDで構成する必要があります。このサーバーIDは、レプリケーショントポロジ内の各サーバーを識別するために使用され、1から（2 32）-1までの正の整数である必要があります。次のステートメントを発行することにより、server_idの値を動的に変更できます。
SET GLOBAL server_id = 2;
デフォルトのサーバーIDが0の場合、ソースはレプリカからの接続を拒否し、レプリカはソースへの接続を拒否するため、この値をレプリケーショントポロジで使用することはできません。これに加えて、各サーバーIDがレプリケーショントポロジ内の他のサーバーによって使用される他のすべてのサーバーIDと異なる限り、サーバーIDを整理および選択する方法を選択できます。以前にサーバーIDに値0を設定した場合は、サーバーを再起動して、新しいゼロ以外のサーバーIDでソースを初期化する必要があることに注意してください。それ以外の場合は、バイナリロギングを有効にするか、再起動が必要なその他の構成変更を行う必要がない限り、サーバーを再起動する必要はありません。
バイナリログはソースからそのコピーに変更をコピーするための基礎であるため、バイナリログはソースで有効にする必要があります。log-binオプションを使用してソースでバイナリロギングが有効になっていない場合、レプリケーションを実行できません。バイナリロギングが有効になっていないサーバーでバイナリロギングを有効にするには、サーバーを再起動する必要があります。この場合、MySQLサーバーをシャットダウンし、my.cnfまたはmy.iniファイルを編集してください。[mysqld]構成ファイルセクションで、log-binおよびserver-idオプションを追加します。これらのオプションがすでに存在しているがコメントアウトされている場合は、これらのオプションのコメントを解除し、必要に応じて変更してください。たとえば、ログファイル名プレフィックスを使用してバイナリロギングmysql-binを有効にし、サーバーIDを1に設定するには、次の行を使用します。
[mysqld]
log-bin=mysql-bin
server-id=1
変更を加えたら、サーバーを再起動します。
注
次のオプションは、このプロセスに影響します。
InnoDBがトランザクションで使用されるレプリケーション設定で最大の耐久性と一貫性を得るには、ソースファイルで使用する必要があります
innodb_flush_log_at_trx_commit=1
和
sync_binlog=1
ソースでskip_networkingシステム変数が有効になっていないことを確認してください。この変数を有効にすると、ネットワーク接続が無効になり、コピーはソースと通信できなくなり、コピーは失敗します。
レプリケーション用のユーザーを作成する
各レプリカは、ソースに接続するためにMySQLのユーザー名とパスワードを使用する必要があるため、ソースにユーザーアカウントが必要であり、レプリカを使用して接続できます。コピーを設定する場合、ユーザー名は、コマンドMASTER_USERのオプションCHANGE MASTERTOで指定されます。アカウントにREPLICATIONSLAVE権限が付与されている限り、この操作には任意のアカウントを使用できます。コピーごとに異なるアカウントを作成するか、コピーごとに同じアカウントを使用してソースに接続するかを選択できます。
レプリケーション専用のアカウントを作成する必要はありませんが、レプリケーションのユーザー名とパスワードは、レプリケーションメタデータリポジトリにプレーンテキストで保存されることに注意してください。したがって、他のアカウントへの危害の可能性を最小限に抑えるために、コピープロセスの権限のみを持つ別のアカウントを作成することをお勧めします。
新しいアカウントを作成するには、CREATEUSERコマンドを使用します。アカウントにレプリケーションに必要な権限を付与するには、次のGRANTステートメントを使用します。アカウントがレプリケーションのみを目的として作成されている場合、アカウントに必要なのはREPLICATIONSLAVE権限のみです。たとえば、新しいユーザーを設定するには、そのユーザーがexample.comドメイン内の任意のホストからの接続を複製できるように、ソースで次のステートメントを発行します。
mysql> CREATE USER 'repl'@'%.example.com' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.example.com';
コピーソースのバイナリログ座標を取得します
正しいポイントでコピープロセスを開始するようにコピーを構成するには、ソースの現在の座標をバイナリログに書き留める必要があります。
ソースをシャットダウンしてデータスナップショットを作成する場合は、このプロセスをスキップして、代わりにバイナリログインデックスファイルのコピーをデータスナップショットとともに保存することを選択できます。この場合、ソースは再起動時に新しいバイナリログファイルを作成します。したがって、コピーがコピーを開始する必要があるソースのバイナリログ座標は、コピーされたバイナリログインデックスファイルにリストされているファイルの次の、ソース上の次のバイナリログファイルである新しいファイルの開始です。
ソースのバイナリログ座標を取得するには、次の手順に従います。
1.コマンドラインクライアントを使用してソースに接続し、ソースでセッションを開始し、次のFLUSH TABLES WITH READ LOCKステートメントを実行して、すべてのテーブルをフラッシュし、書き込みステートメントを防止します。
mysql> FLUSH TABLES WITH READ LOCK;
注：読み取りロック付きのFLUSH TABLESは、テーブルのCOMMIT操作を防ぎます。つまり、書き込み操作の送信を防ぎます。
2.ソースの別のセッションで、SHOW MASTER STATUSステートメントを使用して、現在のバイナリログファイルの名前と場所を確認します。
mysql > SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 73 | test | manual,mysql |
+------------------+----------+--------------+------------------+
[ファイル]列にはログファイルの名前が表示され、[位置]列にはファイル内の位置が表示されます。この例では、バイナリログファイルはmysql-bin.000003であり、場所は73です。これらの値を記録します。後でコピーを設定するときに必要になります。これらは、コピー元の新しい更新をコピーが処理する必要があるコピーされた座標を表します。
ソースが以前に実行されていて、バイナリロギングが有効になっていない場合、SHOW MASTERSTATUSまたはmysqldump--master-dataによって表示されるログファイル名と場所の値は空です。この場合、後でソースログファイルと場所を指定するときに使用する必要がある値は空の文字列（ ''）です。
これで、コピーが正しい場所のバイナリログから読み取りとコピーを開始するための情報が得られました。
＃設定をコピー
次のセクションでは、コピーを設定する方法について説明します。
1.各コピーには、server_idシステム変数で指定された一意のサーバーIDが必要です。複数のレプリカを設定する場合は、各レプリカに一意のserver_id値を設定する必要があります。この値は、ソースレプリカや他のレプリカとは異なる必要があります。レプリカサーバーのサーバーIDが設定されていない場合、または現在の値がソースサーバーまたは他のレプリカサーバーに選択した値と競合する場合は、変更する必要があります。デフォルトのserver_id値は0です。これは、レプリカがソースへの接続を拒否することを意味します。
次のステートメントを発行することにより、server_idの値を動的に変更できます。
SET GLOBAL server_id = 21;
server_idが以前にデフォルト値を0に設定している場合は、サーバーを再起動して、新しいゼロ以外のサーバーIDでレプリカを初期化する必要があります。それ以外の場合は、サーバーIDを変更する必要がある他の構成変更を行わない限り、サーバーIDを変更するときにサーバーを再起動する必要はありません。たとえば、サーバーでバイナリロギングが無効になっていて、コピーでバイナリロギングを有効にする場合は、サーバーを再起動してこの機能を有効にする必要があります。
レプリカサーバーをシャットダウンする場合は、構成ファイルの[mysqld]セクションを編集して、一意のサーバーIDを指定できます。例えば：
[mysqld]
server-id=21
バイナリロギングを有効にしなくても、コピーを複製できます。ただし、コピーのバイナリログレコードは、データのバックアップとクラッシュリカバリに使用できます。バイナリロギングが有効になっているレプリカは、より複雑なレプリケーショントポロジの一部として使用することもできます。レプリカでバイナリロギングを有効にする場合は、構成ファイルの[mysqld]セクションでlog-binオプションを構成します。以前に使用されたことのないサーバーでバイナリロギングを開始するには、サーバーを再起動する必要があります。
2.レプリカサーバーでソース構成を設定します
レプリケーションソースと通信するようにレプリカを設定するには、レプリカに必要な接続情報を構成します。これを行うには、コピーに対して次のステートメントを実行し、オプション値をシステムに関連する実際の値に置き換えます。
mysql> CHANGE MASTER TO
-> MASTER_HOST='source_host_name',
-> MASTER_USER='replication_user_name',
-> MASTER_PASSWORD='replication_password',
-> MASTER_LOG_FILE='recorded_log_file_name',
-> MASTER_LOG_POS=recorded_log_position;
3.レプリケーションスレッドを開始します。
mysql> START SLAVE;
このプロセスを実行した後、レプリカサーバーはソースに接続し、ソースで発生したすべての更新に自己取得スナップショットをコピーします。