web-dev-qa-db-ja.com

ネットワークを介したMySQLデータベースのバックアップ

サーバー＃1は、Debianで実行されているMySQLデータベースサーバーであり、多数のテーブルと100GBを超える特定のテーブルが1つ含まれています。

サーバー＃2はレプリケーションのMySQLスレーブとして使用されますが、問題が発生したため、サーバーをリセットしてレプリケーションを再初期化する必要があります。

現在、サーバー＃1のハードドライブには、データベース全体のダンプを実行するのに十分なスペースがありません（つまり、100 GB未満の空き容量）。ダウンタイムを必要とするハードウェアをアップグレードする以外に、データベースダンプをサーバー＃1からサーバー＃2にそのまま、破損することなく、サーバー＃1のハードドライブを処理中にいっぱいにすることなく取得するための最良の方法は何でしょうか。

mysqlbackupdatabase
4
calvinf

これは、中間ファイルなしで実行でき、プロセスでレプリケーションポインターをリセットすることもできるため、更新を見逃すことはありません（また、再同期する必要があります）。

  1. スレーブのレプリケーションを停止します

    スレーブ> mysql 'スレーブ停止;'

  2. --master-data=1フラグを使用して、マスターをスレーブにダンプします

    master> mysqldump -e --master-data = 1 --single-transaction $ DATABASE | ssh -C user @ slave'mysql $ DATABASE '

  3. スレーブでレプリケーションを開始します

    スレーブ> mysql 'スレーブ開始'

--master-data=1により、mysqldumpはダンプの先頭にCHANGE MASTER TO ...設定を発行して、レプリケーションbinlogを設定し、ダンプが取得されたときのマスターbinlogの正確なポイントにオフセットします。

-eは、拡張出力形式を使用します。基本的に、挿入ステートメントごとに複数の値のセットが使用されます。これは、ネットワーク上でも、スレーブに適用される場合でも、より効率的です。

--single-transationは、LOCK TABLESを使用するのではなく、ダンプ全体でトランザクションを開くようにmysqlに指示します。

5
Dave Cheney

迅速で汚い方法（サーバー＃1から開始）：

mysqldump -u root -p bigdb | bzip2 -c | ssh -T user@server2 "cat > backup.sql.bz2"
6
Sekenre

リモートホストからmysqlデータベースをダンプできます。mysqldumpで--Hostまたは-h引数を使用するだけです。

server2# mysqldump -h server1 -u root -p --opt | gzip > database.sql.gz
server2# zcat database.sql.gz | mysql -u root -p

明らかにディスクへのダンプをスキップすることもできますが、インポートはダンプよりも遅くなる傾向があります。 server2のCPUがボトルネックであり、ディスクが高速である場合は、gzipの手順をスキップして、マスターサーバーのダウンタイムを最小限に抑えることができます。

明らかに、私の答えは、レプリケーションの詳細を記録し、レプリケーションの一貫したダンプがあることを確認するための詳細をスキップします。これらはMySQLのマニュアルで扱われているためです。

1
David Pashley

サーバー間にファイアウォールがない場合は、明らかにNFSです。ファイアウォールがある場合は、NFSが機能するための追加のトラフィックを許可するために、ファイアウォールを再構成する必要がある場合があります。

同様の解決策は、もう少し複雑ですが、server1でsmbmountを使用し、server2でsmbdを使用することです。

ファイアウォールをいじりたくない場合（またはサーバー間で暗号化されていないデータを送信したくない場合）は、sshfsをお勧めします。

0
kubanczyk

厳密にmyisamテーブルを使用している場合は、mysqlをシャットダウンし、server1からserver2にデータファイルをcpします。また、mysqlを維持し、グローバル読み取りロックを使用して読み取り専用にしてから、テーブルをcpすることもできます。

明確にするための編集と追加：

Server1のテーブルをstdoutにmysqldumpし、server2に接続されたmysqlにパイプすることもできます。ただし、100 GBのテーブルでは、時間がかかる可能性があり、一貫性が必要な場合は読み取り専用にする必要があります。

0
cs168

レプリケーションがオプションではなく、ローカルサーバーに十分なディスク容量がない場合の最善の策は、ダウンタイムが発生し、ライブデータベースファイルから完全同期を実行することです。

  1. MySQLを正常にシャットダウンします
  2. MySQLパーティションを読み取り専用として再マウントします（これは、何かをコックした場合に役立ちます）
  3. Rsync、wgetなどを使用して、データセットのコピー全体を取得し、それを2番目のサーバーに転送します
  4. MySQLパーティションを読み取り/書き込みとして再マウントします
  5. MySQLを再起動します

ネットワーク接続の速度にもよりますが、新しいディスクをインストールするよりもダウンタイムが少なくなる可能性があります。

または、一時的なUSB大容量ストレージデバイスをサーバーに追加し、それを使用して完全なデータベースダンプを取得することを検討してください。これにより、ダウンタイムがゼロになります。

0
Moo

ボックスが互いに妥当な物理的距離内にある場合は、USBドライブを接続し、そこでデータベースダンプを実行できます。

これがnix-boxで実行される場合、別の代替手段はssh/pipesである可能性がありますが、ストレージに使用しているバックエンドによっては、mysqlprocessを実行したままにしようとすると、大きなテーブルでテーブルロックが問題になる可能性があります。

Mysqlbox2から、次のようになります。

ssh mysqlbox1 "mysqldump <options for username/pw/tables-to-dump>" > /path/to/spacious/fs/dbdump
0
Kjetil Joergensen