グローバル読取りロックを取得し、read_only システム変数を操作して、バックアップするサーバーの読取り専用状態を変更することで、レプリケーション設定のソースサーバーまたはレプリカサーバーをバックアップできます:
サーバーを読み取り専用にします (検索のみが処理され、更新はブロックされます)。
バックアップを実行します。
サーバーを通常の読み取り/書き込み状態に戻します。
このセクションの手順では、バックアップするサーバーを、サーバーからデータを取得するバックアップ方式 (mysqldump など) に安全な状態に変換しています (セクション4.5.4「mysqldump — データベースバックアッププログラム」を参照してください)。 バイナリバックアップを作成するために、ファイルを直接コピーする方法でこれらの手順の使用を試みてはいけません (サーバーが変更後データをまだメモリー内にキャッシュしていてディスクにフラッシュしていない可能性があるため)。
次の手順では、ソースおよびレプリカに対してこれを実行する方法について説明します。 ここで説明する両方のシナリオでは、次のレプリケーションセットアップを想定します。
ソースサーバー S1
ソースとして S1 を持つレプリカサーバー R1
S1 に接続されたクライアント C1
R1 に接続されたクライアント C2
いずれのシナリオでも、グローバル読取りロックを取得して read_only 変数を操作するステートメントは、バックアップ対象のサーバーで実行され、そのサーバーのレプリカには伝播されません。
シナリオ 1: 読取り専用ソースを使用したバックアップ
次のステートメントを実行して、ソース S1 を読取り専用状態にします:
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;S1 が読み取り専用状態のときは、次の属性が true になります。
サーバーが読取り専用モードであるため、C1 によって S1 ブロックに送信される更新のリクエスト。
C1 から S1 に送信されたクエリー結果のリクエストは成功しました。
S1 でのバックアップの作成は安全です。
R1 でバックアップを作成することは安全ではありません。 このサーバーはまだ実行中で、バイナリログを処理中であったり、クライアント C2 から着信する要求を更新したりする可能性があります。
S1 が読み取り専用のときに、バックアップを実行してください。 たとえば、mysqldump を使用できます。
S1 でのバックアップ操作が完了したあとに、これらのステートメントを実行することで S1 を通常の動作状態に戻します。
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;S1 でのバックアップの実行は安全ですが (バックアップに関するかぎり)、S1 のクライアントは更新の実行をブロックされるため、パフォーマンスに最適ではありません。
この戦略は、レプリケーション設定でのソースのバックアップに適用されますが、非レプリケーション設定で単一のサーバーに使用することもできます。
シナリオ 2: 読取り専用レプリカによるバックアップ
次のステートメントを実行して、レプリカ R1 を読取り専用状態にします:
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;R1 が読取り専用状態の間は、次のプロパティが適用されます:
ソース S1 は引き続き動作するため、ソースでのバックアップは安全ではありません。
レプリカ R1 は停止しているため、レプリカ R1 上のバックアップは安全です。
これらのプロパティは、一般的なバックアップシナリオの基礎を提供: バックアップの実行中に 1 つのレプリカがビジー状態になっていても、ネットワーク全体には影響せず、バックアップ中もシステムが実行中であるため、問題は発生しません。 特に、クライアントはソースサーバーで更新を実行できますが、レプリカのバックアップアクティビティによる影響は受けません。
R1 は読取り専用ですが、バックアップを実行します。 たとえば、mysqldump を使用できます。
R1 でのバックアップ操作が完了したら、次のステートメントを実行して、R1 を通常の操作状態にリストアします:
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;replca は、通常の操作に復元されたあと、ソースバイナリログからの未処理の更新をキャッチアップすることによって、ソースと再度同期します。