MySQLのマスタースレーブまたはマスターマスターの関係を設定する準備をしています。現在、MySQL実稼働サーバーは1つしかありません。もちろん、スレーブに接続している間、多くのダウンタイムは必要ありません。
空のスレーブを接続して、マスターからのデータが同一になるまで「ゆっくり」同期させる方法はありませんか?
マスターでmysqldumpを使用してトランザクションダンプを取得し、それをスレーブにインポートできることに気付きましたが、スレーブがダンプをインポートするまでに、多くの新しい行が書き込まれ、スレーブはこれらをどのように取得しますか?
ここで明らかな何かが欠けていることを願っていますが、広範囲にわたるグーグルは、「これにより将来のダウンタイムが少なくなるため、現在のダウンタイムはそれほど悪いことではないかもしれません」などのアドバイスを提供します。しかし、私はそれを本当に避けたいと思います。
関連 MyISAMの質問 ですが、私はInnoDBを使用しています。
100%InnoDBを使用している場合は、幸運です。 XtraBackup を使用すると、ダウンタイムやテーブルのロックなしでマスターデータベースの完全バックアップを作成できます。これは、FLUSH TABLES WITH READ LOCK
または--master-data
オプションを実行したときに取得する種類と同じ、一貫性のあるスナップショットスタイルのバックアップになります。
XtraBackupツールは、スレーブでレプリケーションを開始するために必要なMASTER_LOG_POSおよびMASTER_LOG_FILE情報を含む追加のファイルもバックアップディレクトリにドロップします。
バックアップが完了したら、バックアップでXtraBackupの--prepare
オプションを実行し、それをスレーブにロードし、スレーブMySQLプロセスをバックアップして開始し、必要な新しいMASTER_LOG_POS値とMASTER_LOG_FILE値を通知する必要があります。
スレーブを起動する前に、my.cnfにskip-slave-start
が必要になります。
また、mysql
スキーマはデフォルトでMyISAMであることに注意してください(メモリが正しく機能する場合はMyISAMのみになります)。そのため、実行中にこれらのテーブルに変更を加えないように注意する必要があります。バックアップ。そのルールを守っている限り、マスター情報は正しいままです。
多くの場合、スレーブで my.cnfのmysql
スキーマを無視 にして、SELECT権限を持つユーザーのみを作成することをお勧めします。 Percona(およびその前のMaatkit)が提供するツールを使用している場合でも、一貫性のない非同期のスレーブは検出が難しく、対処するのが困難です。
編集:
InnoDBを使用しているとおっしゃっていましたが、完全を期すために、MyISAMテーブルを使用している場合は別の方法があります。スナップショット付きのボリュームマネージャーがある場合( [〜#〜] zfs [〜#〜] または [〜#〜] lvm [〜#〜] )、 FLUSH TABLES WITH READ LOCK
の後にSHOW MASTER STATUS
を実行し、スナップショットを作成してUNLOCK TABLES
を実行できます。ダウンタイムはかなり最小限に抑える必要があります。比較のために、昨夜、データベースの1つをバックアップするためにこれを行ったcronジョブは、データベースが「ダウン」しているビットであるスナップショットを作成するのに6秒かかり、スナップショットからバックアップサーバーにファイルをコピーするのに27分かかりました。
Mysqlレプリケーションを「最初から」開始することはできません。
代わりに、データベースをダンプするときに--master-data=2
パラメーターを指定してmysqldumpを使用できます(つまり、次のようになります)。
mysqldump --master-data=2 --all-databases --opt -p > myinitialdump.sql
このコマンドは、ダンプ中に影響を受けるデータベース内のすべてのテーブルをロックし、次のようにコメントアウトされた方法でレプリケーション座標をダンプのヘッダーに書き込みます。
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000018', MASTER_LOG_POS=106;
インポートが完了したら、マスターのホスト名と認証データを指定して「changemasterto」コマンドを手動で実行できます。レプリケーションはダンプの時点で解除されます。
Mysqldumpプロセスは、ロックの競合のためにそれ自体で「ダウンタイム」が発生することに注意してください。ダンプの期間全体にわたって、すべてのテーブルに読み取りロックが設定されます(FLUSH TABLES WITH READ LOCKコマンドが実行するのと同様)。したがって、ダンプが完了しない限り、テーブルへの書き込み要求は返されません。また、MySQL構成で low_priority_updates を指定した場合、またはダンプの前にSET GLOBAL LOW_PRIORITY_UPDATES = 1を発行した場合を除き、書き込み要求は後続の読み取り要求もブロックする可能性があります。