回答:
ダウンタイムなしでMySQLバックアップを適切に行う場合は、データベースを予備のサーバーに複製する必要があります。非常に強力である必要はありません。マスターデータベースの書き込み負荷に対応する必要があるだけです。このサーバーを本番環境で使用しないでください。複製が追いつかない場合は、より強力なサーバーが必要です。の出力からログファイルと位置を比較することで確認できます
> SHOW MASTER STATUS\G
マスターと
> SHOW SLAVE STATUS\G
奴隷に。MySQL5はからの遅れを示すと思いますSHOW SLAVE STATUS。
あなたの奴隷が追いついていることに満足しているとき、あなたは
SLAVE STOP;スレーブでのレプリケーションを停止しますmysqldump --optスレーブサーバ上。SLAVE START;スレーブ上で再度レプリケーションを開始しますこれを行うと、データベースの一貫したバックアップが作成されます。この方法により、異なるデータベース、さらには同じデータベース内の異なるテーブルが同期しなくなり、バックアップ中に書き込み用にテーブルをロックしてダウンタイムを防ぐことができます。
この設定のすばらしい利点は、ライブサービスに影響を与えない、時間のかかるクエリを実行するために使用できるデータベースのコピーがあることです。
ランダムなヒントのカップル：
mysqldump --opt、それは通常、結果のSQLをインポートする最速の方法だとして、mysqldump各データベースのファイルにデータ/スキーマを抽出するために使用するスクリプトを使用しています。データは、通常のnetbackupバックアップによってテープにバックアップされます。ベルやホイッスルをさらに追加することはできますが、これは単純な基本的なダンプです。
#!/bin/sh
# Find out what databases are in mysql and back them up
# Delete old backups
STARTTIME=` date +%Y%m%d-%H%M `
#BACKUP_DIR="/usr/local/db_backups"
BACKUP_DIR="/var/local/db_backups"
LOGFILE="/var/log/db_backups.log"
USER="root"
PASSWD="<password>"
KEEP="7"
(
echo
echo " ---MySQL backups start ${STARTTIME} ---"
#delete any backup written more than ${KEEP} days ago
echo "Removing files over ${KEEP} days old from ${BACKUP_DIR}:"
/usr/bin/find ${BACKUP_DIR} -mindepth 1 -mtime +${KEEP} -print -delete
echo
echo "Performing today's dumps"
#find each database running in this instance of mysl
for DB in ` echo "show databases;"|mysql -u${USER} -p${PASSWD} mysql |awk " NR>1 {print $1} " `
do
#generate a backup file name based on the data base name
BACKUP_FILE="${BACKUP_DIR}/${DB}-${STARTTIME}.sql"
echo "Processing database ${DB} into file ${BACKUP_FILE}"
# dump the database data/schema into the backup file
mysqldump -u${USER} -p${PASSWD} --add-drop-table ${DB} > ${BACKUP_FILE}
gzip ${BACKUP_FILE}
done
ENDTIME=` date +%Y%m%d-%H%M `
echo
echo " ---MySQL backups complete ${ENDTIME} ---"
echo
) >> ${LOGFILE} 2>&1
私たちの標準的なセットアップは、読み取り専用であるもう一方に複製する2つのデータベースを持つHAクラスターです。
1日1回フルバックアップを実行し、その後、古いバックアップを削除するというお客様ごとのポリシーがあります。通常、1か月の最後の日曜日のバックアップを4つ保持し（週末を生き残るため）、最後の日曜日と最後の最初の日曜日を4つ保持します。その後、年に1〜2個のダンプがアーカイブに保存され、永久に保存されます。
また、ディスクスペースを節約する余裕がある限り、レプリケーションログを保持します。また、誰が何をいつ変更したかを正確に記録するため、デバッグツールとしても非常に役立ちます。
理論上必要なのは、1つのフルバックアップとすべてのレプリケーションログでポイントインタイムリストアを実行できることですが、フルバックアップを頻繁に行うと、リストアの速度が上がります。
バックアップの巧妙なトリックの1つは、mysqlダンプにinnodbテーブルと--single-transactionパラメータを使用することです。これにより、バックアップが実行中にデータベースをブロックしなくなります。
PerconaのXtrabackupを使用しています。InnoDB / XtraDBの非ブロック可能なバックアップソリューション
バックアップの全体的な目的は、復元できるようにすることです。
私はバックアップソリューションとしてCSVダンプを推奨しません。それがあなたに与えるすべては生データです。それ以外にも、特にデータベースに関してはもっとたくさんあります。テーブルの説明、ビュー、ストアドプロシージャに名前を付けます。これらもない場合は、正常に戻すことができません。考慮すべきRDBMSアプリケーションと構成もあります。多数のパッチを適用している可能性があります。それらを同じレベルにするには、回復環境にも適用する必要があります。アプリケーションの要件によって決まる特別な構成を実行している可能性があります。データベースを最適に実行するには、特定のOS設定が必要な場合もあります。これらのすべてを取り戻す必要もあります。また、それらを実行できるバックアップソリューションがない限り、回復時間がさらに遅くなります。
データベースのバックアップ（および一般的なバックアップ）では、これらすべてを処理できる「実際の」バックアップソフトウェアを使用することを常に好みます。
最近では、EC2でMySQLサーバーを管理しています。15分のcronジョブでEBSスナップショットを設定し、3〜5個のスナップショットを保持しました。
「従来の」MySQLサーバーを使用したときは、MySQl-ZRMを介して毎日バックアップしました。バックアップは基本的にmysqldumpであり、顧客のニーズに応じてテープやSANなどに送信されます。
どちらの方法も、データベースを停止せずに実行できます。
MySQLの場合、私のバックアップソフトウェア（Backup Exec）はLinuxシステムのスナップショットをサポートしていないため、automysqlbackup（http://sourceforge.net/projects/automysqlbackup/）を使用します。
正常に動作しますが、このスレッドを監視して提案を探します:)