MySQLログ・ポイント・ベースのレプリケーション
5809 ワード
MySQLのレプリケーション機能は、高性能なアプリケーションを構築するだけでなく、高可用性、拡張性、災害復旧などの作業の基礎となります.
レプリケーションの主な機能
1、データ分布.MySQLが提供するレプリケーション機能は、大きな帯域幅の要件を必要としないため、異なる物理的な場所でデータを分散することができます.
2、リード操作のロードバランシングレプリケーションとロードバランシング方式により、リード操作を複数のサーバに分散することができ、リード密集型応用に対する性能最適化を実現する.
3、バックアップ・レプリケーションは一定のバックアップの役割を果たすことができますが、バックアップに完全に取って代わることはできません.
4、高可用性とフェイルオーバーのレプリケーションはMySQLの単一の失敗の問題を避けることができ、メインライブラリがダウンタイムした場合、迅速なフェイルオーバーはシステムのダウンタイムを減らすことができる.
ログ・ポイント・レプリケーションの原理に基づく
概して、レプリケーションは次のステップに分けられます.
1、マスターライブラリはデータの更新イベントをバイナリログに記録する.
バイナリ・ログは、通常、タイムスタンプなどの更新に他の情報を追加するイベントで構成されます.トランザクションのコミットを準備するたびに、プライマリ・ライブラリはデータ更新のイベントをバイナリ・ログに記録します.記録が完了すると、プライマリ・ライブラリはストレージ・エンジンにイベントをコミットできることを通知します.
2.ライブラリからメインライブラリのログを自分の中継ログにコピーする.
まず、ライブラリからI/Oスレッドと呼ばれるワークスレッドを起動します.このスレッドは、プライマリ・ライブラリと通常の接続を確立し、プライマリ・ライブラリ上でバイナリ・ダンプ・スレッドを起動します.このバイナリ・ストレージ・スレッドは、プライマリ・ライブラリ上のバイナリ・ログ内のイベントを読み取り、ライブラリから送信します.ライブラリのI/Oスレッドからイベントを受信し、ライブラリからの中継ログに記録します.
バイナリ・ストレージ・スレッドの動作はポーリングではなく、スレッドがプライマリ・ライブラリに追いつくと、プライマリ・ライブラリが信号通知を送信して起動するまでスリープ状態になります.
3.ライブラリから中継ログのイベントを読み出し、ライブラリから再配置する.
メインライブラリの時間が送信されると、ライブラリのI/Oスレッドから中継ログ(relay log)にイベントが書き込まれ、その後、ライブラリ上のSQLスレッドから中継ログのイベントが読み出され、再生され、メインライブラリデータと一致する.I/OスレッドとSQLスレッドのコラボレーションにより、イベントの取得と再生イベントのデカップリングが非同期で実行されることがわかります.5.6まではSQLスレッドが1つしか動作しないため、再生はシリアル化されています.5.6以降、マルチスレッド再生が追加されましたが、マルチスレッドはライブラリベースであり、1つのライブラリでは1つのSQLスレッドしかイベントを再生できません.
レプリケーションの手順
1、複製アカウントの作成
ライブラリから実行されるI/Oスレッドによってプライマリ・ライブラリへの接続が確立されるため、プライマリ・ライブラリにユーザーを作成し、ライブラリからそのユーザーとしてプライマリ・ライブラリに接続してバイナリ・ログを読み込む適切な権限を持つ必要があります.
イントラネットIPを使用してのみログインできるアカウントを作成します.
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO repl@’192.168.xxx.%’ IDENTIFIED BY ‘password’;
このコマンドは、REPLICATION SLAVEとREPLICATION CLIENTの権限を付与しながら、replアカウントを作成します.実際にはREPLICATION SLAVE権限だけでコピーできることに注意してください.REPLICATION CLIENT権限は、SHOW MASTER STATUS、SHOW SLAVE STATUS、SHOW BINARY LOGS文などのレプリケーションの監視と管理を主に許可します.
アカウントが作成されたら、ライブラリホストからこのアカウントを使ってリモートでマスターライブラリにログインしてみるべきです.うまくログインすれば、2台のホストのMySQLが正常に通信でき、アカウントは大丈夫です.
2、マスター、スレーブライブラリの構成
マスター、スレーブライブラリに必要な構成:マスター:
準備:
実際、server_のみidは設定する必要があり、他の構成項目は実際の状況に応じて構成されます.たとえば、スレーブライブラリも他のライブラリのプライマリライブラリである場合、log_slave_updatesは1に設定されています.ライブラリからデータのみを読み込む場合はread_onlyは1に設定されています.
3、初期化データ
mysqldumpまたは他の方法でプライマリ・ライブラリ・データをフル・バックアップし、ライブラリからバックアップをリカバリします.ただし、プライマリ・ライブラリのバックアップでは、現在のバイナリ・ログの名前と座標(オフセット量)を記録します.SHOW MASTER STATUSコマンドで確認できます.
4、コピー開始
データの初期化が完了すると、コピーを開始できます.
mysql-> CHANGE MASTER TO MASTER_HOST=‘ホストIP’,->MASTER_USER = ‘repl’, -> MASTER_PASSWORD = ‘password’, -> MASTER_LOG_FILE=‘メインライブラリ上の現在のバイナリファイル’,->MASTER_LOG_POS=‘ログ座標’;
レプリケーションを開始すると、いつでもCHANGE MASTER TOを使用してレプリケーションの設定を動的に変更でき、スレーブライブラリを再起動する必要はありません.
注意、正しいバイナリログ座標を取得する必要があります.I/Oスレッドは、ログ座標からログの最後まで読み続け、メインライブラリの送信信号が起動するまでスリープ状態に入ります.
設定後、mysql->START SLAVEを使用します.
SHOW SLAVE STATUSコマンドを使用して状況を確認できます.SLAVE_IO_STATUSはWaiting for master to send eventであり、レプリケーションが正常に開始されたことを示します.
スレーブ・ライブラリのステータスの表示
ライブラリからコマンドを実行することで
mysql-> show slave status;
Slave_IO_State: Waiting for master to send event Master_Host: 192.168.136.1 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000010 Read_Master_Log_Pos: 3266 Relay_Log_File: mysql-relay-bin.000002 Relay_Log_Pos: 877 Relay_Master_Log_File: mysql.000010 Slave_IO_Running: Yes Slave_SQL_Running: Yes
…… Exec_Master_Log_Pos: 3266 Relay_Log_Space: 1084
…… Seconds_Behind_Master: 0
…… SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400
主な変数の説明:
Slave_IO_StateはI/Oスレッドの状態であり、Waiting for master to send eventはスレッドがマスターライブラリからイベントの送信を待っていることを示します.
Read_Master_Log_PosはI/Oスレッドのためにマスターライブラリ上のバイナリログがどの位置にあるかを読み出し、単位はバイトです.メインライブラリ上のバイナリログ記録座標と比較すると、現在のI/Oスレッドの遅延が得られます.
Exec_Master_Log_Posは、SQLスレッドがプライマリ・ライブラリ上のバイナリ・ログをバイト単位で繰り返した場所です(Read_Master_Log_Pos-Exec_Master_Log_Pos)は、現在のSQLスレッドの実行の遅延を表すことができます.Read_Master_Log_Posは常にExecより大きいMaster_Log_Pos .
Seconds_Behind_Masterは、SQLスレッドで実行された最後のイベントに記録されたタイムスタンプとI/Oスレッドで取得された最後のイベントに記録されたタイムスタンプを比較することにより、このような差を得る.この値は主従遅延を完全に反映することはできません.この場合、主ライブラリのI/O負荷が大きいか、ネットワークがブロックされている場合、I/Oスレッドはバイナリログのイベントをタイムリーに取得できません.SQLスレッドはI/Oスレッドの足どりに追いつくことができます.この場合、Seconds_Behind_Masterの値は0ですが、主従間には遅延があります.
SQL_Delay 5.6以降に追加された遅延レプリケーションは、プライマリ・ライブラリのイベントを取得した後、SQLスレッドがN秒待ってから再生されることを示します.
SQL_Remaining_Delay SQLスレッドが待機中の場合は、残りの待機時間を表し、他の場合は0になります.
Slave_SQL_Running_State SQLスレッドの状態
GTIDによるレプリケーション
ログ・ポイント・ベースのレプリケーションでは、ライブラリからバイナリ・ログのオフセット量を指定する必要があります.オフセット量にエラーがあると、同期後にデータが一致しないという問題が発生し、エラーが報告されてレプリケーションが終了する可能性があります.この問題を解決するため、MySQLは5.6以降GTIDベースのレプリケーションを発表した.
GTIDは簡単に言えばMySQLがトランザクションのために生成したIDであり、グローバルで一意であり、クラスタ全体で一意である.
スレーブ・ライブラリは、マスター・ライブラリが実行したトランザクションのGTID値を示します.マスター・ライブラリは、スレーブ・ライブラリのGTIDトランザクションが実行されていないことを示します.これらはすべてMySQLのメンテナンスによって行われるため、プライマリ・スレーブ・データの一貫性をよりよく保証できます.
レプリケーションの主な機能
1、データ分布.MySQLが提供するレプリケーション機能は、大きな帯域幅の要件を必要としないため、異なる物理的な場所でデータを分散することができます.
2、リード操作のロードバランシングレプリケーションとロードバランシング方式により、リード操作を複数のサーバに分散することができ、リード密集型応用に対する性能最適化を実現する.
3、バックアップ・レプリケーションは一定のバックアップの役割を果たすことができますが、バックアップに完全に取って代わることはできません.
4、高可用性とフェイルオーバーのレプリケーションはMySQLの単一の失敗の問題を避けることができ、メインライブラリがダウンタイムした場合、迅速なフェイルオーバーはシステムのダウンタイムを減らすことができる.
ログ・ポイント・レプリケーションの原理に基づく
概して、レプリケーションは次のステップに分けられます.
1、マスターライブラリはデータの更新イベントをバイナリログに記録する.
バイナリ・ログは、通常、タイムスタンプなどの更新に他の情報を追加するイベントで構成されます.トランザクションのコミットを準備するたびに、プライマリ・ライブラリはデータ更新のイベントをバイナリ・ログに記録します.記録が完了すると、プライマリ・ライブラリはストレージ・エンジンにイベントをコミットできることを通知します.
2.ライブラリからメインライブラリのログを自分の中継ログにコピーする.
まず、ライブラリからI/Oスレッドと呼ばれるワークスレッドを起動します.このスレッドは、プライマリ・ライブラリと通常の接続を確立し、プライマリ・ライブラリ上でバイナリ・ダンプ・スレッドを起動します.このバイナリ・ストレージ・スレッドは、プライマリ・ライブラリ上のバイナリ・ログ内のイベントを読み取り、ライブラリから送信します.ライブラリのI/Oスレッドからイベントを受信し、ライブラリからの中継ログに記録します.
バイナリ・ストレージ・スレッドの動作はポーリングではなく、スレッドがプライマリ・ライブラリに追いつくと、プライマリ・ライブラリが信号通知を送信して起動するまでスリープ状態になります.
3.ライブラリから中継ログのイベントを読み出し、ライブラリから再配置する.
メインライブラリの時間が送信されると、ライブラリのI/Oスレッドから中継ログ(relay log)にイベントが書き込まれ、その後、ライブラリ上のSQLスレッドから中継ログのイベントが読み出され、再生され、メインライブラリデータと一致する.I/OスレッドとSQLスレッドのコラボレーションにより、イベントの取得と再生イベントのデカップリングが非同期で実行されることがわかります.5.6まではSQLスレッドが1つしか動作しないため、再生はシリアル化されています.5.6以降、マルチスレッド再生が追加されましたが、マルチスレッドはライブラリベースであり、1つのライブラリでは1つのSQLスレッドしかイベントを再生できません.
レプリケーションの手順
1、複製アカウントの作成
ライブラリから実行されるI/Oスレッドによってプライマリ・ライブラリへの接続が確立されるため、プライマリ・ライブラリにユーザーを作成し、ライブラリからそのユーザーとしてプライマリ・ライブラリに接続してバイナリ・ログを読み込む適切な権限を持つ必要があります.
イントラネットIPを使用してのみログインできるアカウントを作成します.
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO repl@’192.168.xxx.%’ IDENTIFIED BY ‘password’;
このコマンドは、REPLICATION SLAVEとREPLICATION CLIENTの権限を付与しながら、replアカウントを作成します.実際にはREPLICATION SLAVE権限だけでコピーできることに注意してください.REPLICATION CLIENT権限は、SHOW MASTER STATUS、SHOW SLAVE STATUS、SHOW BINARY LOGS文などのレプリケーションの監視と管理を主に許可します.
アカウントが作成されたら、ライブラリホストからこのアカウントを使ってリモートでマスターライブラリにログインしてみるべきです.うまくログインすれば、2台のホストのMySQLが正常に通信でき、アカウントは大丈夫です.
2、マスター、スレーブライブラリの構成
マスター、スレーブライブラリに必要な構成:マスター:
# ，
log_bin = mysql-bin
# ID
server_id = 1準備:
log_bin = mysql-bin
#
server_id = 2
#
relay_log = /var/lib/mysql/mysql-relay-bin
#
log_slave_updates = 1
#
read_only = 1実際、server_のみidは設定する必要があり、他の構成項目は実際の状況に応じて構成されます.たとえば、スレーブライブラリも他のライブラリのプライマリライブラリである場合、log_slave_updatesは1に設定されています.ライブラリからデータのみを読み込む場合はread_onlyは1に設定されています.
3、初期化データ
mysqldumpまたは他の方法でプライマリ・ライブラリ・データをフル・バックアップし、ライブラリからバックアップをリカバリします.ただし、プライマリ・ライブラリのバックアップでは、現在のバイナリ・ログの名前と座標(オフセット量)を記録します.SHOW MASTER STATUSコマンドで確認できます.
4、コピー開始
データの初期化が完了すると、コピーを開始できます.
mysql-> CHANGE MASTER TO MASTER_HOST=‘ホストIP’,->MASTER_USER = ‘repl’, -> MASTER_PASSWORD = ‘password’, -> MASTER_LOG_FILE=‘メインライブラリ上の現在のバイナリファイル’,->MASTER_LOG_POS=‘ログ座標’;
レプリケーションを開始すると、いつでもCHANGE MASTER TOを使用してレプリケーションの設定を動的に変更でき、スレーブライブラリを再起動する必要はありません.
注意、正しいバイナリログ座標を取得する必要があります.I/Oスレッドは、ログ座標からログの最後まで読み続け、メインライブラリの送信信号が起動するまでスリープ状態に入ります.
設定後、mysql->START SLAVEを使用します.
SHOW SLAVE STATUSコマンドを使用して状況を確認できます.SLAVE_IO_STATUSはWaiting for master to send eventであり、レプリケーションが正常に開始されたことを示します.
スレーブ・ライブラリのステータスの表示
ライブラリからコマンドを実行することで
mysql-> show slave status;
Slave_IO_State: Waiting for master to send event Master_Host: 192.168.136.1 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000010 Read_Master_Log_Pos: 3266 Relay_Log_File: mysql-relay-bin.000002 Relay_Log_Pos: 877 Relay_Master_Log_File: mysql.000010 Slave_IO_Running: Yes Slave_SQL_Running: Yes
…… Exec_Master_Log_Pos: 3266 Relay_Log_Space: 1084
…… Seconds_Behind_Master: 0
…… SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400
主な変数の説明:
Slave_IO_StateはI/Oスレッドの状態であり、Waiting for master to send eventはスレッドがマスターライブラリからイベントの送信を待っていることを示します.
Read_Master_Log_PosはI/Oスレッドのためにマスターライブラリ上のバイナリログがどの位置にあるかを読み出し、単位はバイトです.メインライブラリ上のバイナリログ記録座標と比較すると、現在のI/Oスレッドの遅延が得られます.
Exec_Master_Log_Posは、SQLスレッドがプライマリ・ライブラリ上のバイナリ・ログをバイト単位で繰り返した場所です(Read_Master_Log_Pos-Exec_Master_Log_Pos)は、現在のSQLスレッドの実行の遅延を表すことができます.Read_Master_Log_Posは常にExecより大きいMaster_Log_Pos .
Seconds_Behind_Masterは、SQLスレッドで実行された最後のイベントに記録されたタイムスタンプとI/Oスレッドで取得された最後のイベントに記録されたタイムスタンプを比較することにより、このような差を得る.この値は主従遅延を完全に反映することはできません.この場合、主ライブラリのI/O負荷が大きいか、ネットワークがブロックされている場合、I/Oスレッドはバイナリログのイベントをタイムリーに取得できません.SQLスレッドはI/Oスレッドの足どりに追いつくことができます.この場合、Seconds_Behind_Masterの値は0ですが、主従間には遅延があります.
SQL_Delay 5.6以降に追加された遅延レプリケーションは、プライマリ・ライブラリのイベントを取得した後、SQLスレッドがN秒待ってから再生されることを示します.
SQL_Remaining_Delay SQLスレッドが待機中の場合は、残りの待機時間を表し、他の場合は0になります.
Slave_SQL_Running_State SQLスレッドの状態
GTIDによるレプリケーション
ログ・ポイント・ベースのレプリケーションでは、ライブラリからバイナリ・ログのオフセット量を指定する必要があります.オフセット量にエラーがあると、同期後にデータが一致しないという問題が発生し、エラーが報告されてレプリケーションが終了する可能性があります.この問題を解決するため、MySQLは5.6以降GTIDベースのレプリケーションを発表した.
GTIDは簡単に言えばMySQLがトランザクションのために生成したIDであり、グローバルで一意であり、クラスタ全体で一意である.
スレーブ・ライブラリは、マスター・ライブラリが実行したトランザクションのGTID値を示します.マスター・ライブラリは、スレーブ・ライブラリのGTIDトランザクションが実行されていないことを示します.これらはすべてMySQLのメンテナンスによって行われるため、プライマリ・スレーブ・データの一貫性をよりよく保証できます.