巨大なMySQL innodbデータベースを効率的にダンプする方法は？

8

データベースの合計サイズが260 GBであり、DBが保存されるルートパーティション自体が300 GBであるUbuntu 10.04のプロダクションMySQLデータベースサーバーを取得しました。など現在、他のディスクはサーバーに接続されていません。

私の仕事は、このデータベースを別のデータセンターにある他のサーバーに移行することです。問題は、最小限のダウンタイムでそれを効率的に行う方法ですか？

私は次のように考えています：

サーバーに追加のドライブを接続し、そのドライブでダンプを取るように要求します。[編集：今は不可能です。]
ダンプを新しいサーバーに転送して復元し、既存のサーバーの新しいサーバースレーブを作成してデータの同期を維持します
移行が必要な場合は、レプリケーションを中断し、読み取り/書き込み要求を受け入れるようにスレーブ構成を更新し、古いサーバーを読み取り専用にして、書き込み要求を受け付けないようにし、アプリ開発者にdbの新しいIPアドレスで構成を更新するように指示します。

これを改善するための提案や、このタスクの代替のより良いアプローチは何ですか？

innodb mysql

— ジャグビル
ソース

9

あなたは、MySQLの正確な同じバージョンで別のDBサーバーへの移行を検討している場合、あなたはしたいことがあり、古いサーバから新しいサーバへ。rsyncdatadir

これは、InnoDBファイルのレイアウトやMyISAMテーブルの存在に関係なく機能します。

ServerAと同じバージョンのmysqlをServerBにインストールします。
ServerAで実行RESET MASTER;して、rsycnプロセスの前にすべてのバイナリログを消去します。バイナリログが有効になっていない場合は、この手順をスキップできます。
ServerAでSET GLOBAL innodb_max_dirty_pages_pct = 0;mysqlから実行し、約10分（これにより、ダーティページがInnoDBバッファープールからパージされます。これにより、mysqlのシャットダウンがより高速に実行されます）データベースがすべてMyISAMである場合は、この手順をスキップできます。
ServerAのrsync / var / lib / mysqlをServerBの/ var / lib / mysqlに
rsyncが1分未満になるまでステップ3を繰り返します
service mysql stop ServerA
もう一度rsyncを実行します
scp ServerA：/etc/my.cnf to ServerB：/ etc /。
service mysql start ServerB上
service mysql start ServerA（オプション）

基本的に、そのようなスクリプトは次のようになります。

mysql -u... -p... -e"RESET MASTER;"
mysql -u... -p... -e"SET GLOBAL innodb_max_dirty_pages_pct = 0;"
RSYNCSTOTRY=10
cd /var/lib/mysql
X=0
while [ ${X} -lt ${RSYNCSTOTRY} ]
do
    X=`echo ${X}+1|bc`
    rsync -r * targetserver:/var/lib/mysql/.
    sleep 60
done
service mysql stop
rsync -r * targetserver:/var/lib/mysql/.
service mysql start

DBA StackExchangeの仲間のメンバーは、mysqlperformanceblog.com FLUSH TABLES WITH READ LOCK;にあるものに基づいては離れるべきだと言っています

私は全体を読み、aの途中でInnoDBテーブルに対するSELECTをFLUSH TABLES WITH READ LOCK;実行しても、何らかの方法で書き込みが発生する可能性があることを学びました。Arlukinのコメントで指摘されているように、LVMはFLUSH TABLES WITH READ LOCKInnoDBで問題なく動作します（彼のコメントに+1）。

LVM以外のすべてのユーザーにとって、で使用するすべてのMyISAMデータベースで問題ありませんFLUSH TABLES WITH READ LOCK;。InnoDBの場合--single-tranaction、mysqldumpsでの使用に固執してください。

— RolandoMySQLDBA
ソース

2

これが、マスター/スレーブ設定を手動で同期する必要がある場合の方法です。本当にうまくいきます。しかし、最新のサーバーではLVMスナップショットを使用しているため、サーバーを停止する必要はありません。LVMスナップショットを実行する直前に、「FLUSH TABLES WITH READ LOCK」を実行して、ファイルをコピーできるようにします。lvm-snapshotは、バックアップ目的ですべてのファイルをコピーする場合にも非常に便利です。そのため、新しいサーバーをLVMでセットアップし、スナップショットを作成できるようにスペースを追加します。

— Arlukin

詳細な回答ありがとうございます。MySQLのバージョンが異なる場合はどうなりますか？古いバージョンはubuntu 10.04を搭載した5.1ですが、新しいバージョンはデフォルトの5.5を搭載した12.04を使用します。そのような場合、どのようなアプローチをお勧めしますか？また、追加のドライブを接続することは問題外であるため、ダンプ/ rsyncまたはその他の方法でリモートからデータを送信する必要があります。

— Jagbir

1

このサイズのデータベースのダンプと復元には数時間かかります。mysqlのバージョンに応じて、バージョン番号が増加し、メジャーリビジョン番号にジャンプがない限り、私はそうします。/ var / lib / mysqlの未加工データベースファイルを取得して新しいサーバーに配置し、権限を設定して、--skip-grant-tablesスイッチでサーバーを起動できるはずです。新しいIPアドレスを反映するユーザーに必要な許可を追加して、通常どおり再起動します。

データベースのサイズが大きすぎて効率的ではないため、データベースのサイズについて説明します。

— ジェームズパークワット
ソース

約50〜90 GBのサイズのデータベースが4つあり、全体のサイズは260 GBになります。それは非効率的かもしれませんが、私は今のところそれと一緒に暮らす必要があります。また、MySQLのバージョンも異なります。その場合、どのようなことを提案しますか？

— Jagbir

mysqlのバージョンが異なる場合は、最初に予行演習を行い、新しいサーバーのバージョン番号が古いサーバーのバージョン番号よりも高い限り、大丈夫です。それが失敗した場合、mysqldump &&リストアを使用してスタックする可能性があります。

— James Park-Watt

1

次の手順に従って、この巨大なInnoDBデータベースを移行できます。

SSHFSをインストールし、リモートサーバーの関連パーティションを本番サーバーにマウントします。
Percona XtraBackupを使用してInnoDBデータベースのホットコピーを取得し、それをSSHFSマウントされたディレクトリに直接保存します
このタスクには数時間かかります。ライブサーバーでのホットコピースクリプトの影響を最小限に抑えるには、reniceを使用して低優先度を設定します。

$ renice -n 5 -p <SCRIPT-PID>
両方のサーバーがMySQLサーバーの同じリリースを実行していることを確認してください。
ホットコピーが完了すると、それを新しいサーバーに復元してレプリケーションプロセスを開始できます。

このプロセス中に速度が低下することがありますが、ダウンタイムはありません。Percona XtraBackupは、mysqldumpに比べて高速でリソース消費の少ないホットコピーを作成します。これは、巨大なInnoDBデータベースに最適です。

使用パターンと統計に応じて、サーバーに最小限のトラフィックがあるときにこのプロセスを実行できます。週末にこれを行うのは良い考えでしょうか？上記はプロセスの概要です。Percona XtraBackupおよびSSHFSのドキュメントを参照する必要がある場合があります。

— Vagarwal
ソース

1

データベースをリモートサーバーに直接ダンプするだけで...

$ mysqldump | ssh user@server 'cat - > dumpfile.sql.gz'

... SQLは適切に圧縮する必要があるため、これらのオプションのいずれかを使用すると、ボックス内のRAMの容量にもよりますが、これを大幅に高速化できます...

$ mysqldump | ssh -C user@server 'cat - > dumpfile.sql.gz'
$ mysqldump | gzip -c | ssh user@server 'cat - > dumpfile.sql.gz'

— 犬の体
ソース