予算内でのダウンタイムのないMySQLバックアップ

現在のMySQLバックアップシナリオは、dbを2番目のサーバーに複製し、そのサーバーでmysqldumpを実行して、テーブルまたは行のロックからダウンタ​​イムを削除することです。これはうまく機能していますが、2台目のサーバーの月額は150ドルです（オーストラリアのホスティングは米国よりもはるかに高価です）。

私はこれについて多くの質問をここで読みました。ほとんどの人は、スケジュールされたバックアップの助けが必要です。ダウンタイムなしでmysqldump（4時間ごとが望ましい）が必要です。dbは〜7GB圧縮されていないため、サーバーによってはmysqldumpに時間がかかる場合があります。

同じマシンに複製することを検討しましたが、スレーブが必要なメモリに食い込んで欲しくありません。データベースごとにメモリ使用量を制限できるかどうかわかりませんか？いずれにせよ、これにより、dbのダンプ中にサーバーに負荷がかかります。

私はこれを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）データベースで使用し、良い結果を得ました。データベースに大きな負荷がかかっている場合は、数時間ことがありますが、テーブルをロックせずに機能します。レプリケーションは一般的には優れていますが、素敵な固体ダンプファイルが必要な場合があります。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への高遅延接続を介した複製の問題はあまり見られません。高遅延は、それほど大きな問題ではないはずです。レプリケーションは、スレーブが落ちてもすぐに追いつくことができるように設計されています数時間遅れたいます。つまり、非同期で動作できます。

オーストラリアのホスティングプランでこれだけの発信帯域幅に耐えられる限り。

高レイテンシが重要であるかどうかに対する、より詳細な応答を次に示します

現実的には、データベースを実際にエクスポートするのにかかる時間のみがダウンタイムになります。十分に遅い時間帯に実行してください。問題はないはずです。その予算のIT部門は本当に何を期待していますか？

最大5〜10分で7GBのデータベースをmysqldumpし、読み取り/書き込みロックを解除すると、ダウンタイムが終了するはずです。その後、新しいサーバーへの7GBファイルへの帯域幅効率が最も高い方法を見つけることができます（読み取り：HIGH COMPRESSION）。ファイルを転送して、新しいサーバーのMySQLにインポートするのに十分な時間があります。次に、マスターログ情報を入力し、レプリケーションを開始します。ケーキになるはずです！

MySQLのドキュメントは素晴らしいです：http : //dev.mysql.com/doc/refman/5.0/en/replication.html

データベースごとにメモリ使用量を制限できるかどうかわかりません

もちろんできます-異なる/etc/my.cnfでスレーブを実行するだけです

nice / reniceとtasksetを使用して、マスターとスレーブのスケジューリング優先度/ CPUアフィニティを操作することもできます（Linuxサーバーを想定しています）。

しかし、複製はオーバーネットで行われ、pingは〜220msです

待ち時間はほとんど関係ありません-重要なことは帯域幅です-データベースの帯域幅（セッションデータをレプリケートしていない場合）は、HTTP帯域幅よりも桁違いに小さくなります。

ダウンタイムなしで[データベースの一貫したバックアップを作成する]（4時間ごとが望ましい）が必要です。

しかし、あなたが議論する戦略は、そのような時の回復を許しません。

最も安価なオプションは、同じマシン上のスレーブになると思います。そして、再構成可能な範囲を超えてパフォーマンスに悪影響を与える場合は、現在のホスティングパッケージをアップグレードします。

また、切断されたスレーブの実行を検討することもできます。現在のサーバーでbinログを有効にします。バックアップを取得し、ローカルマシンでバックアップを復元してから、ビンログをローテーションしてコピーし、ローカルDBMSでロールフォワードします。

私のおすすめ：

1-2番目のアカウント/サーバーを保持し、元のアカウント/サーバーのデータベースへのレプリケーションを実装します。

2-2番目のアカウント/サーバーへのレプリケーションを停止します。

3-数日間パフォーマンスを監視します。最も忙しい期間を含めるのに十分な時間を監視してください。

4-重大なパフォーマンスの問題がある場合は、古いセットアップに切り替える準備をしてください。これが、2番目のアカウントを保持した理由です。

5-元のアカウントで容量/アップグレードサーバーを追加購入します。これは、私が信じている2台のサーバーにお金を払うよりも安いはずです。

6-2番目のアカウントをキャンセルします。

幸運を！