予算内でダウンタイムレスのMySQLバックアップ
私の現在のMySQLバックアップシナリオは、dbを2番目のサーバーに複製し、そのサーバーでmysqldumpを実行して、テーブルまたは行のロックからダウンタイムを取り除くことです。これはうまく機能していますが、2番目のサーバーの費用は月額150ドルです（オーストラリアのホスティングは米国よりもはるかに高価です）。
私はこれについてここでたくさんの質問を読みました、ほとんどの人はスケジュールされたバックアップの助けを必要としています、そしてそれは私が必要としているものではありません。ダウンタイムなしでmysqldumpを実行する必要があります（できれば4時間ごと）。 dbは最大7GBの非圧縮であるため、サーバーによってはmysqldumpに時間がかかる場合があります。
同じマシンに複製することを検討しましたが、スレーブが必要なメモリを大量に消費することを望んでいませんでした。データベースごとにメモリ使用量を制限できるかどうかわかりませんか？いずれにせよ、これはサーバーがデータベースをダンプしている間にサーバーに負荷をかけます。
私はこれを読んだばかりです http://www.zmanda.com/quick-mysql-backup.html 見た目は良さそうですが、年間300ドルで大丈夫なので、かなり節約できます。
残念ながら、AmazonのRDSに複製することはできませんが、マイクロRC2インスタンスに複製することはできますが、複製はネット経由で行われ、pingは約220ミリ秒です。
ここで数人の人がLVMスナップショットについて話しているのを見ました。これは良いオプションかもしれません。私はこのオプションについて多くを知りません。
ご意見をいただければ幸いです。
Innodbテーブルを使用する場合は、
http://www.percona.com/docs/wiki/percona-xtrabackup:start
これにより、データベースのダンプが取得され、ツールからもロックせずにインポートできます。 myisamテーブルがあると、それらがロックされると思います。
Innodbまたは完全にトランザクション型の別のバックエンドを使用している場合は、mysqldump --single-transaction ...を使用できます。私はこれをかなり大きな（〜100GB）データベースで使用しましたが、良い結果が得られました。データベースに大きな負荷がかかっている場合は、時間かかることがありますが、テーブルをロックしなくても機能します。一般的にはレプリケーションの方が優れていますが、Niceソリッドダンプファイルが必要な場合もあります。 mysqlレプリケーションスレーブもダンプできることに注意してください。
Mysqldumpページから（トランザクションにリークする操作に関する警告に注意してください）：
· --single-transaction
This option sends a START TRANSACTION SQL statement to the server
before dumping data. It is useful only with transactional tables
such as InnoDB, because then it dumps the consistent state of the
database at the time when BEGIN was issued without blocking any
applications.
When using this option, you should keep in mind that only InnoDB
tables are dumped in a consistent state. For example, any MyISAM or
MEMORY tables dumped while using this option may still change
state.
While a --single-transaction dump is in process, to ensure a valid
dump file (correct table contents and binary log coordinates), no
other connection should use the following statements: ALTER TABLE,
CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE. A
consistent read is not isolated from those statements, so use of
them on a table to be dumped can cause the SELECT that is performed
by mysqldump to retrieve the table contents to obtain incorrect
contents or fail.
米国では、高遅延接続を介して安価なVPSに複製する際の問題はあまり見られません。高遅延は、それほど問題にはならないはずです。レプリケーションは、スレーブが時間遅れた場合でも迅速に追いつくことができるように設計されています。つまり、非同期で動作できます。
オーストラリアのホスティングプランでそれだけの発信帯域幅に耐えられる限り。
データベースごとにメモリ使用量を制限できるかどうかわかりません
もちろんできます-別の/etc/my.cnfでスレーブを実行する必要があります
Nice/renceとタスクセット（Linuxサーバーであると想定）を使用して、マスターとスレーブのスケジューリング優先度/ CPUアフィニティーを操作することもできます。
ただし、レプリケーションはネット経由で行われ、pingは約220ミリ秒です。
レイテンシーはほとんど関係ありません-重要なことは帯域幅です-そしてデータベース帯域幅（セッションデータを複製していないと仮定）はHTTP帯域幅よりも数桁小さいです。
ダウンタイムなしで[データベースの一貫したバックアップを作成する]（できれば4時間ごと）必要があります
しかし、あなたが議論する戦略は、その時のようなものでは回復を許しません。
最も安価なオプションは同じマシン上のスレーブだと思います-そしてそれが再構成できるものを超えてパフォーマンスに悪影響を及ぼしている場合は、現在のホスティングパッケージをアップグレードしてください。
切断されたスレーブの実行を検討することもできます。現在のサーバーでbinログを有効にします。バックアップを取得し、ローカルマシンでバックアップを復元してから、ローテーションされたビンログをコピーして ローカルDBMSでロールフォワード 。
私のおすすめ：
1-2番目のアカウント/サーバーを保持し、元のアカウント/サーバーのデータベースへのレプリケーションを実装します。
2-2番目のアカウント/サーバーへのレプリケーションを停止します。
3-数日間パフォーマンスを監視します。最も忙しい期間を含めるのに十分な時間監視するようにしてください。
4-重大なパフォーマンスの問題がある場合は、古いセットアップに切り替える準備をしてください。これが、2番目のアカウントを保持した理由です。
5-元のアカウントで容量の追加/サーバーのアップグレードを購入します。これは、私が信じている2台のサーバーに支払うよりも安いはずです。
6-2番目のアカウントをキャンセルします。
幸運を！
現実的には、データベースを実際にエクスポートするのにかかる時間だけがダウンタイムになります。十分に遅い時間帯にそれを行ってください。問題はないはずです。その予算のIT部門は本当に何を期待していますか？
最大5〜10分で7GBのデータベースをmysqldumpし、読み取り/書き込みロックを解除すると、ダウンタイムが終了します。次に、新しいサーバーへの7GBファイルへの最も帯域幅効果的な方法を見つけることができます（読み取り：高圧縮）。ファイルを転送して新しいサーバーのMySQLにインポートするのに十分な時間があります。次に、マスターログ情報を入力して、レプリケーションを開始します。ケーキのはずです！
MySQLのドキュメントはfantastic： http://dev.mysql.com/doc/refman/5.0/en/replication.html ==