この状況は簡単に説明できます。 当初、プロジェクトは空のままで、コピーするものは何もありません。 急速な開発の段階では、いくつかの開発者の頭はチップとフリルをねじ込むことだけでなく、昨日の期限までに重大なバグを修正することに専念しています。 そして、プロジェクトが「開始」されたときのみ、システムの主な価値は蓄積されたデータベースであり、その失敗は災害になるという認識に至ります。
このレビュー記事は、プロジェクトがすでにこの点に達しているが、焙煎した雄鶏がまだ突っついていない人向けです。
1.データベースファイルのコピー
MySQLサーバーを一時的にシャットダウンし、単に/ var / lib / mysql / db /フォルダーからファイルをコピーする場合、MySQLデータベースをコピーできます。 サーバーがシャットダウンされていない場合、明らかな理由により、データの損失と破損が発生する可能性があります。 負荷の大きい基地の場合、この確率は100％に近くなります。 また、データベースのダーティコピーから初めて起動すると、MySQLサーバーはデータベース全体のチェックプロセスを開始します。これには数時間かかる場合があります。
ほとんどの「ライブ」プロジェクトでは、データベースサーバーを長時間定期的にシャットダウンすることは受け入れられません。 この問題を解決するには、ファイルシステムのスナップショットに基づいたトリックを使用します。 スナップショットは、特定の時点でのファイルシステムの「写真」のようなもので、実際にデータをコピーすることなく（したがって迅速に）作成されます。 同様に、オブジェクトの遅延コピーは、多くの最新のプログラミング言語で機能します。
アクションの一般的なスキームは次のとおりです。すべてのテーブルがロックされ、データベースファイルキャッシュがリセットされ、ファイルシステムのスナップショットが作成され、テーブルがロック解除されます。 その後、ファイルはスナップショットから静かにコピーされ、その後破棄されます。 そのようなプロセスの「ブロック」部分には、すでに耐えられる秒単位の時間がかかります。 しばらくの間、スナップショットが「生きている」間、ファイル操作のパフォーマンスは低下します。これは、主にデータベースへの書き込み操作の速度に影響します。
ZFSなどの一部のファイルシステムは、スナップショットの削除をネイティブにサポートしています。 ZFSを使用せず、サーバーにLVMボリュームマネージャーがインストールされている場合は、スナップショットを使用してMySQLデータベースをコピーすることもできます 。 最後に、* nixでは、 R1Soft Hot Copyスナップショットドライバーを使用できますが、この方法はopenvzコンテナーでは機能しません（ MySQLバックアッププロセスについてはここで説明します ）。
MyISAMデータベースには、サーバーを停止せずにMyISAMデータベースファイルを「正しく」 コピーする公式の無料mysqlhotcopyユーティリティがあります。 InnoDBにも同様のユーティリティがありますが、より多くの機能がありますが、有料です。
ファイルのコピーは、あるサーバーから別のサーバーにデータベース全体を転送する最も速い方法です。
2.テキストファイルによるコピー
本番データベースからバックアップにデータを読み込むために、ファイルをプルする必要はありません。 クエリでデータを選択し、テキストファイルに保存できます。 これを行うには、SQLコマンドSELECT INTO OUTFILEおよびそのペアのLOAD DATA INFILEを使用します。 アンロードは1行ずつ行われます（通常のSELECTのように、保存する必要な行のみを選択できます）。 テーブル構造はどこにも指定されていません-プログラマーがこれを処理する必要があります。 また、必要に応じて、データの整合性を確保するために、トランザクションにSELECT INTO OUTFILEステートメントを含めるよう注意する必要があります。 実際には、SELECT INTO OUTFILEは、他の方法ではコピーできない非常に大きなテーブルを部分的にバックアップするために使用されます。
ほとんどの場合、Igor Romanenkoによって作成されたmysqldumpユーティリティの方がはるかに便利です。 mysqldumpユーティリティは、別のサーバーでデータベースを完全に復元するために必要なすべてのSQLコマンドを含むファイルを生成します。 個々のオプションを使用すると、このファイルとほとんどすべてのDBMS（MySQLだけでなく）との互換性を実現できます。さらに、CSVおよびXML形式でデータをアップロードする可能性があります。 このような形式からデータを回復するには、 mysqlimportユーティリティがあります。
mysqldumpコンソールユーティリティ。 Webインターフェースを介してバックアップを管理できるアドオンと類似物があります。たとえば、ウクライナのツールSypex Dumper （代表的なzapimirはハブにあります）。
テキストファイルのユニバーサルバックアップユーティリティの欠点は、比較的低速であり、増分バックアップを作成できないことです。
3.増分バックアップ
従来は、10のバックアップを保持することをお勧めします：曜日ごとに1つ、および2週間、1か月、1四半期前のバックアップ-これにより、データが破損した場合に十分な深さまでロールバックできます。
バックアップは、同じサーバーではなく、稼働中のデータベースとまったく同じドライブに保存する必要があります。 火災やその他の災害が発生した場合、近くのデータセンターで数台をレンタルするのが最善です。
これらの要件は、大規模なデータベースでは問題になる可能性があります。 100メガバイトのネットワークを介して100ギガバイトのベースのバックアップをポンプするのに3時間かかりますが、この時間にチャネルは完全に詰まります。
増分バックアップにより、たとえば日曜日にのみ完全バックアップが行われ、残りの日には過去の日に追加または変更されたデータのみが書き込まれる場合、この問題を部分的に解決できます。 問題は、これらの同じ「日中に変更されたデータ」を識別する方法です。
ここで、変更されたInnoDBエンジンを含むPercona XtraBackupシステムは、MySQLバイナリログを分析し、それらから必要な情報を引き出します。 上記の有料のInnoDB Hot Backupには、ほぼ同じ機能があります。
バックアップの一般的な問題は、バックアップが常に遅れることです。 メインサーバーに致命的な障害が発生した場合、時間内に「ロールバック」を行うだけでシステムを復元できます。これは、ユーザーを非常に失望させます。 システムの財務フローが何らかの形で影響を受けた場合、そのような「ロールバック」には文字通りかなりの費用がかかります。
4.レプリケーション
MySQLレプリケーションシステムは、ロールバックを回避するように設計されています。 レプリケーションのアイデアは、「メイン」サーバー（「ウィザード」）に加えて、スレーブMySQLサーバー（「スレーブ」）が常に動作しており、ウィザードから増分バックアップをリアルタイムで受信するという事実に基づいています。 したがって、ロールバック時間はほぼネットワークラグに短縮されます。 マスターがクラッシュした場合、スレーブの1つを「新しいマスター」にすぐに割り当て、クライアントをそのマスターにリダイレクトできます。 さらに、スレーブはデータ読み取り要求（SELECT）を処理できます。 いくつかの計算を実行したり、ウィザードの負荷を軽減したりするために使用できます。 MySQLは「箱から出してすぐに」複製をサポートします。MySQLで複製を設定するプロセスは、ユーザーwhiskによってよく説明されています。 マスターとマスターの構成を実行し、外部ハードウェアおよびソフトウェアシステムを使用して、マスター間の負荷分散を行うことができます 。 CAP定理によって課せられる制限を忘れないでください。
レプリケーションは非常にクールで、意図した目的に使用するだけです。 レプリカはデータベースの完全なコピーですが、バックアップではありません ！ 明らかに、DROP TABLEまたはUPDATE users SET password =“ Haha！”を実行すると、ウィザードで変更がすぐにスレーブにコピーされ、それらをロールバックできなくなります。
レプリケーションは、ウィザードではなくスレーブを停止して、ベースファイルレベルでバックアップと組み合わせることができます。
結論の代わりに
覚えておくべき主なことは、それぞれの場合にバックアップが個別であることです。 一度設定して忘れることはできません。 管理者は、少なくとも月に1回、バックアップからデータベースを最初から復元する必要があります。 開発中のプロジェクトでは、データベース構造が絶えず変化しているため、スクリプトの修正を忘れただけで、遅かれ早かれ一部のデータはバックアップに落ちなくなります。 これがメインベースの落下時に発見された場合、そのようなバックアップの値はゼロに等しくなります。