MySQLデータコピーの原理と実践

1.データ複製の概要
1.1データ複製定義
データ・レプリケーションにより、あるサービス上のデータが別のサービス上のデータと同期されます.
1.2コピー用途

データ分布

負荷等化

バックアップ

高可用性およびフェイルオーバー

MySQLアップグレードテスト

2.データコピーの動作原理
2.1レプリケーション・ワークフローの説明(マスター・スレーブ・アーキテクチャの例)
MySQLレプリケーションの原理は比較的簡単で、その核心の仕事の概略図は以下の通りです.

メインライブラリは、更新操作をバイナリログファイルに記録する

.

バックアップ上のI/Oスレッドは、マスターライブラリの更新イベントを受信すると、新規のバイナリログを読み出し、自分の中継ログに

を書き込む.

バックアップは中継ログを読み出し、イベントをデータベース上で再生し、自己データベースデータ

を更新する.
2.2主従レプリケーションアーキテクチャに対する考え方
図2.1のMySQLマスターアーキテクチャを見て、読者は中継ログを削除すれば、レプリケーションプロセス全体が簡単になると感じますか?中継ログは、レプリケーション・アーキテクチャでどのような役割を果たしていますか?
バックアップが中継ログの書き込みを削除する場合、バックアップはbinlogイベントデータを読み出すたびに、sqlイベントを直接再生するだけです.中継ログを追加することで、プロセスの複雑さだけでなく、ファイルI/Oを1回以上書き込む操作でシステム性能を消費することができます.
実は中継ログは、バックアップにとってイベントをキャッシュするbufferであり、その役割は、バックアップの2つのコア操作(ホストバイナリログイベントの読み取り、イベントの再生)を非同期でデカップリングすることである.ホストが比較的時間のかかる変更(alter変更テーブルフィールドなど)を実行し、bufferが存在しない場合、バックアップはホスト上の他の新しいバイナリイベントを同期し続けるには、この時間のかかる操作を実行した後でしかありません.これにより、多くのトラブルが発生する可能性があります(たとえば、時間のかかる操作を実行している間にホストが永続的にダウンタイムしてリカバリできない場合、この間にホストに追加された大量のバイナリ・ログは、バックアップが再生できず、大量のデータが失われ、深刻な結果になります).
バックアップ書き込み中継ログには多くのI/O操作があり、同期性能に影響しませんか?通常、中継ログの内容はシステムキャッシュに格納されるので、利用者は心配する必要はありません.
3.データコピー操作
次のように仮定します.

ホストIP:192.168.1.1スペアIP:192.168.1.2

ホスト上MySQLには大量のリアルタイムデータ更新操作(MySQLがコピーしたのは更新操作)

3.1バックアップのコピー権限アカウントを開設する
GRANT REPLICATION SLAVE ON . TO repluser@‘192.168.1.2’ IDENTIFIED BY ‘replpwd’;``` ホスト上で上記のコマンドを実行すると、バックアップにコピー専用のユーザーアカウントを作成できます.アカウント名はrepluser、パスワードはreplpwdです.
3.2ホストはbinlog機能を起動する
デフォルトのmysqlはbinlogを書いていません./etc/myでプロファイルを変更する必要があります.cnfのmysqld構成項目に次の2行の構成を追加します.

log_bin=/data/mysql/mysql-bin
server_id=100

構成の説明:

log_binはbin_を示すlogファイル名およびパス(/data/mysqlディレクトリは必須)

server_id mysqlインスタンスによっては、他のインスタンスに重複しない値を

とすることができる.
構成が完了したらMySQLサービスを再起動し、MySQL端末で次のコマンドを実行してbin_を開くlogが有効かどうか

show master status;

図3.1のようにホストbin_logが起動し、現在bin_logファイル名:mysql-bin.000001 Pos:154
ホストのデータをコピーするには、ホストのbin_を知る必要があります.logファイル名は何ですか、ホストがbinlogを書くposはどこですか.
ホストにデータを挿入するとbin_log posが移動します
3.3スペア中継ログの構成
デフォルトのMySQLはログを中継していません.プロファイルを/etc/myに変更する必要があります.cnfのmysqld構成項目に次の構成を追加します.

server_id=101
relay_log=/data/mysql/mysql-relay-bin
read_only=1

構成の説明:

server_id mysqlインスタンスによっては、他のインスタンスに重複しない値を与える(100がホストで使用されていることに注意)

.

relay_logは、中継ログの名前(/data/mysqlディレクトリが存在する必要がある)

を示す.

read_onlyスペアは読み取り専用に設定されており、スペア書き込み操作によるデータ書き込みの汚れを防止する構成が完了した後、MySQLサービスを再起動すれば

になります.
3.4同期クローンホストの現在のデータスナップショット
MySQL同期データの核心は、2台のマシン上のホストbinを保証することです.log任意の位置pos以前のデータは完全に一致している
ホストがbin_を開いているためlogの前にすでに多くのデータがありました(これらのデータはbinlogに記録されていないので、バックアップはbinlogログを再生することでこれらのデータに同期できません)、最も一般的な方法は:

ホストを読み取り専用に設定(ホスト以降はデータ更新されない)

mysqldumpなどのツールを使用して現在のMySQLデータをコピーし、バックアップ

にインポートします.

現在のホストのbin_を記録logファイルとposの場所(ホストでshow master statusを実行することによって取得)

ホストの読み取り専用設定を閉じる

この時点で、ホストとbin_がスタンバイされます.log位置のようなスナップショットデータ
この文書では、次のコマンドを実行するだけで、より簡単な方法を使用します.

mysqldump --single-transaction  --all-databases  --master-data=2 --host 192.168.1.1 -uroot -p > all_data.sql

この方法は、前の方法に比べて読み取り専用の設定とbin_の記録を省くことができる.logファイルや場所などの操作でbin_を取得する方法logの位置情報は、実はmysqldumpの出力ファイルall_を開きますdata.sqlでは、次の注釈を発見しました.
図3.2に示すように、ホストdumpデータからのその時点におけるホストbin_log情報はdumpの出力ファイルに記録されています.この場合、赤い枠で囲まれた2つの値を記録するだけでいいです.
最後にdump出力ファイルをデータベースにインポート

source all_data.sql;

3.5スペア構成とホストの接続チャネルおよびbin_log情報
sql端末で次のコマンドを実行します.

change master to master_host='192.168.1.1',
master_user='repluser',
master_password='replpwd',
master_log_file='mysql-bin.000002',
master_log_pos=698;

変数の説明:

master_host:ホストIP

master_user:ユーザー名のコピー(前述のホストによる割り当て)

master_password:コピーされたパスワード

master_log_file: bin_logファイル名(mysqldump出力ファイルのコメント内容)

master_log_pos:現在bin_log位置(mysqldump出力ファイルのコメント内容)

この場合、マスターレプリケーションに関するパラメータがスタンバイで構成されていると判断し、次のコマンドをスタンバイで実行するだけで、プライマリレプリケーションを実行できます.

start slave;

このとき、スペアで次のコマンドを実行して、スペアの動作状況を確認します.

show slave status\G;

このうち、次の2つの指標がYesであれば、スタンバイは正常に動作します.

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

4.主従一貫性
MySQLが提供するレプリケーション機能は、100%の信頼性を保証するものではありません.特定の場合、MySQLのマスターデータが一致しない場合があります.この場合、サードパーティ製のツールを使用して、このようなCaseに対応するのに効率的に協力することができます.

pt-table-checksum:プライマリ・スレーブ・データベースが一致しているかどうかを確認する

pt-table-sync:プライマリ・スレーブ・データベースの不一致を修復する

5.まとめ
MySQLのレプリケーション機能は強大で、私達は生産環境の中で実際の需要に基づいて、柔軟に構築することができます:主従、主主主主、一主多従などの多種のレプリケーションモードは業務の需要を満たす