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