ホームページ > 記事 > データベース > さまざまな状況における MySQL 移行ソリューション (推奨)

さまざまな状況における MySQL 移行ソリューション (推奨)

怪我咯オリジナル: 2017-04-06 10:36:181260ブラウズ

1. 移行する理由

MySQL 移行は、DBA の日常的なメンテナンスのタスクです。本来の意味での移行は、実際の既存のオブジェクトを削除して、オブジェクトの整合性と継続性を確保することに他なりません。柔らかいビーチと同じように、2 人の無邪気な子供たちが砂の山を別の場所に移動して、心の城を築きました。

本番環境では、次の状況で移行作業が必要になります:

ディスク容量が不十分。たとえば、一部の古いプロジェクトでは、選択したモデルがデータベースに適していない可能性があります。時間が経つにつれて、ハードドライブが不足する可能性が高くなります
ビジネスのボトルネックが発生します。たとえば、このプロジェクトでは、単一のマシンを使用してすべての読み取りおよび書き込みサービスを実行しているため、ビジネスのプレッシャーが増大し、圧倒されてしまいます。 IO 圧力が許容範囲内にある場合は、読み取り/書き込み分離ソリューションが採用されます
マシン上でボトルネックが発生します。マシンのボトルネックは主にディスク IO 機能、メモリ、CPU です。現時点では、ボトルネックの最適化に加えて、
プロジェクトの変換が優れた解決策となります。一部のプロジェクトのデータベースは複数のコンピュータールームにまたがっており、異なるコンピュータールームにノードが追加されたり、あるコンピュータールームから別のコンピュータールームにマシンが移動したりする場合があります。別の例として、異なる企業が同じサーバーを共有している場合、サーバーへの負担を軽減し、メンテナンスを容易にするために移行が実行されます。

一言で言えば、移住は最後の手段です。移行作業を実施する目的は、ビジネスを円滑かつ継続的に実行し続けることです。

2. MySQL 移行計画の概要

MySQL の移行は、データを回避し、拡張し続けることにすぎず、ビジネスの円滑かつ継続的な運用を確保することを前提としたバックアップとリカバリにすぎません。問題は、バックアップとリカバリを迅速かつ安全に実行する方法です。

一方で、バックアップ。マスターノードのスレーブノードまたはスタンバイノードごとにバックアップがあります。このバックアップは完全バックアップまたは増分バックアップの場合があります。オンラインバックアップ方法には、mysqldump、xtrabackup、または mydumper が使用される場合があります。小容量 (10 GB 未満) データベースのバックアップには、mysqldump を使用できます。ただし、大容量のデータベース (数百 GB または TB レベル) では、mysqldump バックアップを使用できない一方で、ロックが生成され、時間がかかりすぎます。この場合、xtrabackup を選択するか、データディレクトリを直接コピーすることができます。データディレクトリを直接コピーする方法。rsync を使用して、異なるマシン間で転送できます。所要時間はネットワークによって異なります。 xtrabackup を使用すると、主にバックアップとネットワーク送信に時間がかかります。完全または指定したライブラリバックアップファイルがある場合、これがバックアップを取得する最良の方法です。スタンバイデータベースがサービスの停止を許容できる場合は、データディレクトリを直接コピーするのが最も速い方法です。スタンバイデータベースがサービスを停止できない場合は、xtrabackup (InnoDB テーブルをロックしない) を使用できます。これは、バックアップを完了するための最良の妥協策です。

一方で、回復。小容量（10GB未満）のデータベースのバックアップファイルについては、直接インポートできます。大容量データベース (数百 GB または TB レベル) のリカバリの場合、バックアップファイルをローカルマシンに取得した後は、リカバリは難しくありません。具体的な回復方法については、セクション 4 を参照してください。

3. 実際の MySQL 移行

移行が必要な理由と移行方法を理解した後、本番環境がどのように動作するかを見てみましょう。アプリケーションシナリオが異なれば、ソリューションも異なります。

具体的な実際の戦闘を読む前に、読者と次の同意があるものと想定してください:

プライバシーを保護するために、この記事内のサーバーIPおよびその他の情報は処理されています。同じコンピューター室にある場合は、代わりにサーバー IP の D セグメントを使用してください。サーバーが別のコンピューター室にある場合は、
アーキテクチャ
メソッドはシナリオごとに示されていますが、各ステップで実行されるコマンドについては詳しく説明しません。これは、一方では記事が長くなりすぎると思うためです。方法を知っていれば、具体的なアプローチが得られます。成功は知識の習得と情報の入手能力にのみ依存します。実際の戦闘時の注意事項については、セクション 5 を参照してください。
3.1 シナリオ 1 ライブラリからの 1 つのマスターと 1 つのスレーブ構造の移行

簡単なものから難しいものまでのアイデアに従って、単純な構造から始めます。プロジェクトAはもともとマスタースレーブ構造でした。 101 はマスターノード、102 はスレーブノードです。ビジネスニーズにより、102 はノード 103 から移行されました。アーキテクチャ図を図 1 に示します。 102 スレーブノードのデータ容量が大きすぎるため、mysqldump を使用してバックアップできません。研究開発とのコミュニケーションを経て、一貫した計画が策定されます。

図 1 マスター - スレーブ構造の移行スレーブライブラリのアーキテクチャ図

具体的な方法は次のとおりです:

R&D が 102 の読み取り業務をメインライブラリに切り替えます

102 の MySQL ステータスを確認します。主に PROCESS LIST に依存します)、マシンのトラフィックを観察し、それが正しいことを確認した後、102 スレーブノードのサービスを停止します。
103 新しい MySQL インスタンスを作成します。完了したら、MySQL サービスを停止します。データディレクトリ全体をバックアップ用に他の場所に移動します
rsync を使用して 102 の mysql データディレクトリ全体を 103 にコピーします。レプリケーションスレーブ、レプリケーションクライアント);
コピーが完了したら、103 を変更します。
設定ファイル内の server_id を 102 のものと同じにしないように注意してください
103 のインスタンスでは、設定ファイル内のデータファイルパスとデータディレクトリの権限に注意してください
103 MySQL インスタンスを入力し、SHOW SLAVE STATUS を使用してスレーブライブラリのステータスを確認します。
Seconds_Behind_Master が 0 になり、この時点で pt-table-checksum を使用して 101 と 103 のデータが一致していることを確認できますが、時間がかかります。 . 時間、マスターノードに影響を与える場合、開発とのデータの整合性を検証できます。
データの整合性を検証するだけでなく、アクセスを防ぐためにアカウントの権限も検証する必要があります。ビジネスが戻された後のエラー ;
上記の手順を完了した後、R&D と調整して読み取りビジネスの一部を 101 から 103 に切り替え、ビジネスステータスを観察できます
ビジネスにとって、移行が成功したことが証明されます。
3.2 シナリオ 2 1 マスター/スレーブ構造で指定されたライブラリを移行します
1 つのマスターと 1 つのスレーブを持つスレーブライブラリのみを移行する方法を理解した後、マスター/スレーブノードを移行する方法を見てみましょう同時に。さまざまな企業が同時に同じサーバーにアクセスするため、単一のデータベースに対する負荷が高くなり、管理が不便になります。したがって、マスターノード 101 とスレーブノード 102 を新しいマシン 103 と 104 に同時に移行することが計画されており、103 がマスターノードとして機能し、104 がスレーブノードとして機能します。そのアーキテクチャ図を図に示します。 2.この移行では、指定されたライブラリの移行のみが必要です。これらのライブラリの容量はそれほど大きくなく、データがリアルタイムではないことが保証されます。

図21 マスタースレーブ構成移行指定ライブラリアーキテクチャ図

具体的な方法は以下の通りです。

103と104は新規インスタンスを作成し、マスターノードとスレーブ関係を確立します。スレーブノードは負荷がありません。

102 データをエクスポートするには、スケジュールされたタスクを設定し、ビジネスのピーク時にエクスポート操作を実行するのが正しい方法です。

102 アカウントを収集し、指定されたライブラリに必要な権限。
102 データをエクスポートした後、rsync を使用して 103 に転送し、必要に応じて圧縮操作を実行します。この時点で、データは自動的に 104 に同期されます。サーバーのステータスと MySQL のステータスを監視します。
103 インポートが完了しました。 104 同期が完了しました。 103 は 102 によって収集されたアカウントを承認します。完了後、データとアカウントの権限を確認するように R&D に通知します。
上記が完了したら、研究開発は協力して、101 と 102 のビジネスを 103 と 104 に移行し、ビジネスのステータスを観察できます
ビジネスに問題がなければ、移行が成功したことを証明します。

3.3 シナリオ 3 マスター/スレーブ構造での指定ライブラリの双方向移行

次に、マスター/スレーブ構造で指定ライブラリを双方向に移行する方法を見てみましょう。また、共有サービスのため、サーバーに大きな負荷がかかり、管理が混乱しています。したがって、マスターノード 101 とスレーブノード 102 を新しいマシン 103、104、105、および 106 に移行することが計画されており、同時に 103 は 104 のマスターノードとして機能し、104 はスレーブノードとして機能します。 103 の 105 は 106 のマスターノードとして機能し、106 は 105 のマスターノードとして機能します。ノードからのアーキテクチャ図は図 3 に示されています。この移行では、指定されたライブラリの移行のみが必要です。これらのライブラリの容量はそれほど大きくなく、データがリアルタイムではないことが保証されます。この移行は、2 回移行される点を除けば、シナリオ 2 と非常によく似ていることがわかります。

図 3-1マスタースレーブ構造の指定ライブラリアーキテクチャ図の双方向移行

具体的な方法は以下の通りです:

103と104は新しいインスタンスを作成し、マスタースレーブ関係を確立します。マスターノードとスレーブノードは負荷がありません ;
102 103 で必要な指定されたライブラリデータをエクスポートします。正しい方法は、スケジュールされたタスクを構成し、ビジネスのピーク時にエクスポート操作を実行することです。ここでの選択は mysqldump です。
102 103 アカウントと権限で必要な指定されたライブラリデータを収集します。
103 で必要な指定されたライブラリデータをエクスポートします。 rsync を使用して 103 に転送し、必要に応じて圧縮操作を実行します。データをインポートすると、サーバーの状態と MySQL の状態を監視するために 104 が自動的に同期されます。103 は、102 で収集されたアカウントに従って認証されます。、完了後、R&D に通知してデータとアカウントの権限を確認します
上記が完了したら、R&D と協力して 101 と 102 のビジネスを 103 と 104 に移行し、ビジネスのステータスを観察します。 105 と 106 は新しいインスタンスを作成し、マスターとスレーブの関係を確立します。このとき、マスターノードとスレーブノードは無負荷です。
102 は、データベースデータの場合は、次のように設定します。ここでは、スケジュールされたタスクを実行し、ビジネスのピーク時に Mysqldump を選択します。
102 指定されたデータベースに必要なアカウントと権限を収集します。
102 必要な指定されたライブラリデータが完了しました。rsync を使用します。 105に転送し、必要に応じて圧縮操作を実行します。
105 データをインポートします。この時点で、データは106に自動的に同期されます。サーバーのステータスとMySQLのステータスを監視します。
105 インポートが完了しました。同期が完了すると、102 によって収集されたアカウントに従って 105 が承認されます。完了後、R&D に通知してデータとアカウントの権限を確認します。
上記が完了したら、R&D と協力して 101 と 102 のビジネスを移行します。 105 と 106 を実行し、ビジネスステータスを観察します。
すべてのビジネスに問題がない場合は、移行が成功したことを示します。
3.4 シナリオ4 1マスタースレーブ構成のマスタースレーブの完全移行
次に、1マスタースレーブ構成のマスタースレーブを完全移行する方法を見てみましょう。シナリオ 2 と似ていますが、ここではすべてのライブラリが移行されます。マスターノード 101 の IO ボトルネックのため、マスターノード 101 とスレーブノード 102 を新しいマシン 103 と 104 に同時に移行し、103 がマスターノードとして機能し、104 がスレーブノードとして機能することを計画しています。移行が完了すると、以前のマスターノードとスレーブノードは破棄されます。アーキテクチャ図を図 4 に示します。この移行は大容量の完全なデータベース移行であり、リアルタイムである必要があります。最初に新しいスレーブデータベースを置き換えてから、新しいマスターデータベースを置き換える戦略が採用されているため、この移行は特別です。したがって、方法は少し複雑になります。
図 4. マスター/スレーブ構造の完全な移行マスター/スレーブアーキテクチャ図

R&D は 102 の読み取りビジネスをメインライブラリにカットします

102 を確認します。 MySQL のステータス (主に PROCESS LIST、MASTER STATUS を参照) を確認し、それが正しいことを確認した後、102 スレーブノードのサービスを停止します。

104 完了したら、新しい MySQL インスタンスを作成します。 MySQL サービスを停止し、データディレクトリ mv 全体をバックアップ用に他の場所にコピーします。ここでの操作は 104 であり、これは将来のスレーブライブラリであることに注意してください。

rsync を使用して、mysql データディレクトリ全体を 102 にコピーします。
コピー中に、104 が Get binlog 権限 (REPLICATION SLAVE、REPLICATION CLIENT) を取得できるように 101 を承認します。
コピーが完了したら、104 設定ファイルの server_id を変更します。102 の設定ファイルと一致しないように注意してください。
104 で MySQL インスタンスを起動し、構成ファイルとデータディレクトリの権限
104 MySQL インスタンスを入力し、SHOW SLAVE STATUS を使用してスレーブデータベースのステータスを確認すると、Seconds_Behind_Master が 0 になった後、Seconds_Behind_Master が減少していることがわかります。、これは同期が完了したことを意味します。この時点で、pt-table-checksum を使用して 101 と 104 の値を確認できます。ただし、時間がかかり、マスターノードに影響を与えます。開発と同時にデータの整合性を検証できます
データの整合性を検証することに加えて、ビジネスのアクセスエラーを防ぐためにアカウントの権限も検証する必要があります
研究開発と協力して切り替えます。前の 102 のスレーブノードを 104 に読み取ります。
102 のデータを使用して 103 を 101 のスレーブノードに変更します。方法は上記と同じです。
次の重要な点では、 104 を 103 のスレーブライブラリに変える必要があります;

103 STOP SLAVE IO_THREAD;
103 STOP SLAVE SQL_THREAD、MASTER_LOG_ FILE と MASTER_LOG_P を覚えておいてくださいOS ;
104上記の MASTER_LOG_FILE および MASTER_LOG_POS まで SLAVE を開始します。
104 SLAVE を再度停止します。
1 03 SHOW MASTER STATUS、MASTER_LOG_FILE を記憶します。 MASTER_LOG_POS
103 104 に binlog へのアクセスを許可します。
104 マスターを 103 に変更します。
104 RESET SLAVE ALL 後、SLAVE STATUS を確認すると、Master_Server_Id は 101 のままですが、
ではありません。
104 MySQL が再起動すると、SLAVE が自動的に再起動します。このとき、IO_THREAD と SQL_THREAD が YES であるかどうかを確認します。
このとき、103 と 104 のステータスを確認します。以前は101のスレーブノードでしたが、現在は103のスレーブノードになりました。

。
3.5 シナリオ 5 デュアルプライマリ構造のコンピューター室間の移行
次に、デュアルプライマリ構造のコンピューター室間の移行を行う方法を見てみましょう。あるプロジェクトではディザスタリカバリのため、クロスマシンルームを使用し、両面書き込み可能なデュアルマスター構造を採用しています。ディスク容量の問題のため、場所 A のマシンを交換する必要があります。マスターノード 1.101 とスレーブノード 1.102 を新しいマシン 1.103 と 1.104 に同時に移行し、1.103 がマスターノードとして機能し、1.104 がスレーブノードとして機能することが計画されています。場所 B の 2.101 と 2.102 は変更されませんが、移行が完了すると、1.103 と 2.101 は互いのデュアルマスターになります。アーキテクチャ図を図 5 に示します。デュアルマスター構造であるため、マスターノードを交換する場合は、両方が同時に書き込みを行う必要があり、一方のノードがサービスを停止する必要があります。
図 5 デュアルマスター構造のマシンルーム間移行アーキテクチャ図

1.103 と 1.104 は新しいインスタンスを作成し、マスターとスレーブの関係を確立します。ノードとスレーブノードは無負荷です。

1.102 MySQL のステータスを確認し (主に PROCESS LIST を確認します)、MASTER STATUS が変化していないことを観察します。マシンのトラフィックを観察し、それが正しいことを確認した後、1.102 スレーブノードのサービスを停止します。

1.103 新しい MySQL インスタンスを作成します。完了したら、MySQL サービスを停止し、データディレクトリ全体を次のディレクトリに移動します。バックアップ用の他の場所;

1.102 を置き換え、rsync を使用して mysql データディレクトリ全体を 1.103 にコピーします。
コピーが完了したら、1.103 構成ファイルを変更します。の server_id が 1.102 のものと同じにならないように注意してください。
1.103 で MySQL インスタンスを起動し、データファイルのパスに注意してください。設定ファイルとデータディレクトリの権限内。
1.103 MySQL インスタンスに入り、SHOW SLAVE STATUS を使用してスレーブライブラリのステータスを確認すると、Seconds_Behind_Master が減少していることがわかります。
Seconds_Behind_Master が 0 になると、同期が完了したことを意味します。 pt-table-checksum を使用して 1.101 と 1.103 のデータが整合していることを確認できますが、時間がかかり、マスターノードに影響を及ぼします。データの整合性は開発と同時に検証できます。同じ方法を使用して 1.104 を 1.103 のスレーブライブラリにします
3.6 シナリオ 6 マルチインスタンスのコンピュータールーム間移行

図 6 マルチインスタンスのマシンルーム間移行アーキテクチャ図

具体的な方法は次のとおりです:

1.113 7936 インスタンスのデータのバックアップには innobackupex を使用する必要があることに注意してください。スレーブ情報パラメータ;

バックアップが完了したら、圧縮ファイルを 2.117 にコピーします。

2.117 は、Innobackupex を使用して復元します。ログ;
2.117 次のパラメータに注意してください:replicate-ignore-db、innodb_file_per_table = 1、read_only = 1、server_id;
1.112認可、2.117 が binlog 権限をプルできるようにする (REPLICATION SLAVE、REPLICATION CLIENT)ステータス
7939 は 2.117 上に構築されています。方法は似ていますが、設定ファイルでは、replicate-wild-do-table を指定する必要があります。
ビジネス後のアクセスエラーを防ぐために、開発チームと協力してデータの整合性を検証し、アカウントの権限を検証します。移動します。
上記の作業を完了したら、R&D と調整して、対応するビジネスを 2.117 の 7938 インスタンスと 7939 インスタンスに移行します。ビジネスのステータスを観察します。
ビジネスに問題がない場合は、移行が成功したことを示します。
4 つの注意点
さまざまなシナリオの移行ソリューションを紹介した後、次の点に注意する必要があります:
データベースの移行に
が含まれる場合は、必ず Event_scheduler パラメーターをオンにしてください。マスターノード;
シナリオで移行するときは、ディスク容量やネットワークジッターなどのサーバーの状態に常に注意を払う必要があります。また、ビジネスの継続的な監視も不可欠です。 CHANGE MASTER TO の LOG FILE と LOG POS の間違いを見つけないよう注意してください。指定が間違っていると、データの不整合やマスターとスレーブの関係の確立が失敗する可能性があります。
ディレクトリ内で実行することを忘れないでください
移行作業はスクリプトを使用して自動化できます。ただし、スクリプトを実行する前によく考えてください。各コマンドのパラメータの意味を理解してください。
マルチインスタンス環境では、MySQL を閉じて、mysqladmin を使用します。 -テーブル
上記の一部のシナリオでは、前のインスタンスでこのパラメーターが 0 だったため、バックアップと送信に時間がかかりました
。
gzip を使用してデータを圧縮します。圧縮が完了すると、gzip はソースファイルを削除することに注意してください。
マスターノードで操作する場合は、すべての操作をスレーブノードまたはスタンバイノードで実行する必要があります。マスターノードがダウンしている可能性があります。
xtrabackup バックアップ InnoDB テーブルはロックされていませんが、MyISAM テーブルはロックされています。したがって、操作する前に、現在のデータベーステーブルが MyISAM ストレージエンジンを使用しているかどうかを必ず確認してください。使用している場合は、別途処理するか、テーブルのエンジンを変更してください。

5 つのヒント

実際の MySQL 移行では、次のテクニックを使用できます:

すべての移行 LOG FILE は、relay_master_log_file (同期されるマスター上の binlog ログ名) に基づいており、LOG POS は、以下に基づいています。 exec_master_log_pos (現在の binlog ログの POS ポイントの同期) が優先されます。
データのコピーには rsync を使用します。これは、expect と nohup と組み合わせて使用できます。 innobackupex を使用してデータをバックアップするときに圧縮するための gzip
innobackupex を使用してデータをバックアップする場合、スレーブデータベースを容易にするために –slave-info パラメーターを追加できます。 –throttle パラメーターを追加すると、IO を制限し、ビジネスへの影響を軽減できます。 –Parallel=n パラメータを追加してバックアップを高速化することもできますが、tar ストリーム圧縮を使用する場合、–Parallel パラメータは無効になることに注意してください。
To Do 項目のリストを作成し、A プロセスを描画し、事前に実行する必要があるコマンドを準備します
フォルダーをローカルにすばやくコピーする良い方法は、rsync を使用して次のパラメーターを追加することです。 no-compress –progress;
異なるパーティション間でデータをすばやくコピーするには、dd を使用できます。または、より信頼性の高い方法を使用して、ハードディスクにバックアップしてからサーバーに置きます。他の場所には、直接
速達
この記事では、移行が必要な理由から始まり、次に移行計画について説明し、次にさまざまなシナリオでの実際の移行について説明し、最後に注意事項と実践的なスキルについて説明します。要約すると、次のような点があります。まず、移行の目的は、ビジネスを円滑かつ継続的に実行することです。
次に、移行の中心となるのは、マスターとスレーブの同期をどのように継続するかです。異なるサーバーと異なるビジネス解決策; 3 番目に、ビジネスの切り替えでは、異なる MySQL サーバー間の読み取りと書き込みの分離の順序と、クロスマシンルームの影響を考慮する必要があります。ビジネス上の要請を考慮する必要があります。

読者は、移行プロセス中にこの記事で提供されるアイデアを参照できます。ただし、各操作が正しく実行されることを確認するには、続行する前に慎重に検討する必要があります。

余談になりますが、「自分に能力があることを証明するために最も重要なことは、すべてを自分のコントロール下に置くことです。」

以上がさまざまな状況における MySQL 移行ソリューション (推奨)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明：

この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

前の記事：MySQL マスター/スレーブレプリケーションの原理と構成を分析する次の記事：MySQL マスター/スレーブレプリケーションの原理と構成を分析する

続きを見る