データベース

データベースのバックアップ：運営中のウェブサイトへの影響を最小限に抑える

データベースのバックアップはコンテンツを保存しますが、CPU、RAM、I/O、ネットワークに並列で負荷をかけます。適切な時間制御、適切なダンプツール、整頓されたデータベースによって、私は影響を最小限に抑え、レスポンスタイムを短く保ち、タイムアウトを減らします。.

中心点

バックアップが本番のシステムに与える影響を最小限に抑えるために、次のような重要な記述があります。.

タイミングバックアップのスケジュールをピーク時以外に組み、負荷のピークを避ける。.
テクノロジー並列ダンプツールと単一トランザクションはロックを減らす。.
クリーンアップデータベースをスリムに保ち、不要なメタデータを削除する。.
キャッシングRedis/Memcachedとエッジ・キャッシングがDBの呼び出しを減らす。.
モニタリングバックアップ中のCPU、I/O待ち、遅いクエリをチェックする。.

バックアップがウェブサイト運営に負担をかける理由

バックアップの仕事は、訪問者と競合する リソース. .MySQL ダンプを作成するとき、サーバーはデータを圧縮します。 CPU とダイナミック・ページの遅延が発生する。同時に、大きなテーブルを読み込むと高いディスクI/Oが発生します。これはHDDに蓄積されますが、プロセスは依然としてSSDの帯域幅ウィンドウを奪い合います。古典的なmysqldumpはロックテーブルを長く実行し、WordPressのクエリを待たせ、好ましくないケースではタイムアウトを引き起こします。共有ホスティング環境では、CPU時間とRAMに制限があるため、これはより顕著になります。.

MySQLダンプ: ロック、I/O、CPUを制御

ロッキングを下げる -シングル・トランザクション テーブルがInnoDBを使用している場合。この一貫性のあるスナップショットは、ダンプがデータをストリームしている間、読み取りクエリを実行し続ける。さらに、lz4やzstdなど、スループットとパックレートの比率が良い適切な圧縮方法を使用すると、CPUを節約できます。RAMが少ないシステムでは、ジョブがスワップしないように、極端に高い圧縮レベルは避ける。特にアクティブなサイトでは、大きなブロックを避けてI/O負荷を分散するために、ダンプをテーブルごとに分割する[2][6]。.

レプリカのバックアップ：プライマリの負荷を軽減する

可能であれば、ダンプまたはスナップショットバックアップを リードレプリカ, そのため、プライマリ・サーバーは邪魔されずにトランザクションを処理できる。メリットは明らかです。本番の負荷は低いままなので、ユーザーに影響を与えることなく、より積極的にスレッドを回転させることができます。バックアップ中に遅延が大きくなった場合は、スレッドを一時停止するか、制御された方法で実行を中止します。ポイント・イン・タイムのリストアを後できれいに実行するために、ビンログやGTIDの位置を記録しています。レプリカを 読み取り専用, 私はバージョンとパラメータのドリフトをチェックし、一貫したステータスがバックアップされるように、DDLフェーズの短いメンテナンスウィンドウを計画します。そのため、スレッド、I/O、圧縮を控えめに調整しています。.

物理的バックアップとスナップショット

論理的なダンプに加えて、大量のデータには物理的な手続きも使う。以下のようなツールがある。 Percona XtraBackup またはMySQL Enterprise Backup ホットバックアップ をファイル・レベルで、通常はロング・ロックなしで実行する。SQLのシリアライズが不要なためCPU負荷は軽減されるが、連続的な読み取りI/Oが発生する。一時ファイル用に十分なディスク容量を計画し 用意する-ステップでリストアする。あるいは ファイルシステムのスナップショット (LVM/ZFS)：MyISAMには短いフリーズやターゲットFTWRLが有効で、クラッシュリカバリのあるInnoDBは一貫した画像を提供する。後で正確な時間を知るために、スナップショットのbinlog座標を記録する。非常に大規模なインスタンスの場合、毎日スナップショットを大量に取得し、1時間ごとにビンログを取得するか、細かい変更のために小さなダンプを取得する。.

スケジューリング：トラフィックを低下させることなくバックアップを実行

で段階的に仕事をスケジューリングしている。ロートラフィックは、通常、夜間やキャンペーン期間外である。グローバルなオーディエンスに対しては、最大のターゲットグループに負担がかからないように時間帯をずらす。WordPressの場合は、キャッシュウォーマーや検索インデクサーと競合しないようにcronジョブを設定する。複数のバックアップ（ファイルとDB）が並行して実行されている場合は、時間的に切り離します。私の方法夜間のバックアップオーケストレーションは、多くの場合、実運用における数秒から数分の追加負荷で決定される。.

堅牢なジョブ管理：重複を避ける

互いの仕事が邪魔にならないように、私は次のように使っている。 ロック とクリーンなオーケストレーション: flock は複数回の起動を防ぎ、systemd timer は RandomizedDelaySec スタートの波を均等にする、, Persistent=true はピークを発生させることなく、ミスランを取り戻します。各バックアップの前に、私はメトリクス（負荷、I/O待ち、オープン接続）をチェックし、閾値に達したら制御された方法で中止する。シグナル（SIGINT/SIGTERM）のトラップは、一時ファイルとロックの整理を確実にする。長時間の実行の場合は、ハートビートを準備しておき、早い段階でハングアップを認識し、必要であればジョブを再起動する。.

データのクリーンアップ：無駄のないDB、高速ダンプ

確保する前に表スパムコメントの削除、投稿のリビジョンを5-10に制限、期限切れのトランジェントの削除、古いセッションの破棄。プロジェクトでは、1GBのデータベースが衛生ステップの後、約380MBに縮小され、ダンプの実行速度とI/Oの使用量が明らかに減少しました。また、インデックスを最適化し、使用していないプラグインを削除し、シリアル・メタデータ・クラスタを削減しました。これらのステップにより、バックアップとリストアの時間が短縮され、エラーウィンドウが最小化された。クラウド・アップロードも短縮され、利用可能なクラウド・アップロード容量が増加した。 帯域幅 を守る。.

ファイルとデータベース間の整合性

ワードプレスでは、DBをバックアップするだけでなく アップロード. .一貫性を維持するために、私は2段階で作業を進める。まずデータベースのダンプを行い、次にアップロードされたファイルの最初のrsyncを実行する。その間にアップロードされた新しいファイルを同期するために使用する。あるいは、完全にアトミックなステータスが必要な場合（マイグレーションなど）、数秒間メンテナンスモードに切り替えます。ダンプから一時テーブル、キャッシュ、セッションテーブルを除外して、ボリュームとリストアのリスクを減らしています。.

バックアップタイプの比較

目的に応じて、データベースを中心とした実行に頼ったり、完全なバックアップに頼ったりと、負荷は大きく異なる。.

タイプ	標準サイズ	所要時間	CPU/I/O負荷	ウェブサイトへの影響
データベースのみ	50-500 MB	~10秒～2分	ロー	ほとんど目立たない
フルバックアップ	1-50 GB	~5～30分	中～高	明確に測定可能

コンテンツが多いサイトでは、データベースのバックアップをより頻繁に、しばしば1時間ごとに行い、トラフィックの少ないウィンドウではフルバックアップをスケジュールする。データベースのみのジョブが短時間できれいに実行されれば、データベースのバックアップの影響は低いままだ。プロシージャを混在させたい場合はセキュリティ戦略スナップショット、ダンプ、インクリメンタル方式への有用なアプローチ。重要なことに変わりはない：推測ではなく、リストアをテストすること。.

保管、セキュリティ、アクセス

バックアップは使い物にならなかったり、安全でなければ意味がない。私は 3-2-1ルール (3つのコピー、2つのメディアタイプ、1つはオフサイト）。私はデフォルトでアーカイブを暗号化しキー理想的なのは、秘密の店舗かオフラインで、別々に行うことです。例えば、1時間ごとに48時間、毎日14日間、毎週12週間、毎月12ヶ月間など、予算とコンプライアンスに合わせて保存期間を設定する。ステージング環境については、データ保護を考慮する：PIIを再編集するか、アクセスを厳しく制限する。定期的なキーのローテーションとテストデクリプションにより、不測の事態を防ぎます。.

リソースの管理：優先順位、制限、帯域幅

でバックアップジョブをスロットルします。 優先順位, 可能な場合：nice/ioniceまたはプラグインの設定はウェブサーバーを優先します。限られたスレッドと適度な圧縮レベルは、CPUが焼き切れるのを防ぎます。共有ホスティング環境では、アップリンクレートが詰まるのを避けるため、大きなアーカイブを同時にアップロードしません。エクスポートが別のバックアップ・サーバーで実行される場合は、アップロード帯域幅の制限によってライブ・リクエストへのプレッシャーを軽減します。また、プロセスがOOMキルに陥らないように、PHPのメモリにも注意を払っています。.

比例感覚による微調整：限界とDBパラメータ

で細かな制限を設定している。 cgroups またはsystemdのユニットパラメータ（CPU quota、IOWeight）を使ってバックアップにハードキャップをかける。ネットワーク側では、単純なトラフィックシェイパーが、アップロードがウェブリクエストを置き換えるのを防いでいる。データベース側では、本番環境では保守的なままです。 innodb_flush_log_at_trx_commit 或いは sync_binlog ダンプを高速化するためにこれを変更することはない。InnoDBのI/O容量を適度に増やしたり、ストレージ・バックエンドに空気があるときにリード・アヘッドに切り替えたりすることは意味があります。私は分析とメンテナンスのジョブ（OPTIMIZE、ANALYZE）を厳密にスケジュールしています。外側バックアップ・ウィンドウ。.

モニタリング：メトリクス、ログ、しきい値

バックアップ中に見る CPU, RAM、I/O 待機、オープン接続。長期間にわたるCPU使用率の合計が70 %を超える場合は、設定が過剰であることを示しています。低速のクエリログは、バックアップ印刷のために1000ミリ秒を超えるリクエストを必要とするかどうかを示しています。アプリケーション側で再試行が発生した場合は、スレッドまたは圧縮レベルを緩めます。アラーム付きのダッシュボードは、ユーザーが待ち時間に気づく前に、ピークを緩和するのに役立ちます。.

アラート、自動キャンセル、レプリケーションラグ

私はハードリミットを定義する：超える I/O待機 閾値に達するか、レプリケーションのラグが急激に増加した場合、ジョブは整然とシャットダウンされます。レプリカのダンプのラグカーブを追跡し、カーブが急上昇したらワーカーを動的にスロットルする。開始と終了の時間、量、スループット、圧縮の度合い、チェックサムなどを記録し、傾向を把握するようにしている。これによって、バックアップに予定以上の時間がかかったり、DRウィンドウ（RTO）が破れたりした場合に、早期に気づくことができます。.

キャッシュ、CDN、エッジ：ライブ運用におけるDB負荷の軽減

私はRedisかMemcachedを使っている。 クエリ-ダンプの実行中に負荷をかける。エッジキャッシングは、トラフィックミックスとTTLに応じて、場合によってはDBコールを約1.5倍から4.7倍削減する。CDNは静的アセットをオリジンから遠ざけるので、I/OとCPUのリザーブは維持される。私は、キャッシュウォーマーがバックアップと正確に並行して起動しないことを確認している。誰であれパフォーマンス負荷最大のレバーを素早く見つける。.

クラウドとコンテナ環境

時点では マネージドDB (クラウドサービスなど）、私は自動スナップショットとバックアップウィンドウを使用します。たとえプロバイダーが多くのクッションを提供してくれても、スナップショットはI/Oを発生させる。そのため、私はバックアップウィンドウをピークの外に置き、レプリカ上でエクスポートジョブ（例えばオブジェクトストレージで論理的に）を計画する。IOPSの上限とバースト消費量、そして災害シナリオのためのクロスリージョンコピーに注意している。Kubernetesでは、私はバックアップをCronJobsにカプセル化します。 リソース要求/制限 と優先順位があります。ボリュームスナップショットは、ストレージドライバが一貫性のあるイメージをサポートしていれば、影響を軽減する。アンチアフィニティとノードラベルは、バックアップのワークロードを使用率の低いノードにシフトするのに役立ちます。.

テスト・リストア：カウントのリストア

バックアップは リストア. .私は定期的にステージング環境でリストアをインポートし、時間、メモリ、エラーイメージを測定している。並列リストアツール（myloader、MySQL Shell）は、リストアプロセスを著しく高速化する[2][6]。ポイントインタイムリストアでは、私はビンログもバックアップしています。実践的なリストア経路がなければ、すべてのバックアップは誤った安全性のままです。.

検証、チェックサム、RTO/RPO

バックアップはすべて チェックサム とトライアルリストア。アップロード後にアーカイブを再度チェックし、トランスポートエラーを除外します。ランダムなサンプルをステージング用に比較する：コアテーブルの行数、ランダムな記事、ユーザーアカウント。ここから、私は以下を導き出した。 RTO (回復時間）と RPO (最大データ損失)をダッシュボードの目標値として表示しています。もし目標値を下回った場合は、頻度を上げたり、ツールを最適化したり（例：mydumperスレッド、zstdレベル）、バックアップをレプリカに移したりします。.

実例と提言

ケース1：中規模店舗 ヒント 午後には、データベースのみのダンプを22:00-08:00の間に1時間ごとに、日中は3-4時間ごとに、フルバックアップを毎日03:00に予定しています。22:00～08:00の間、1時間ごとにデータベースのみのダンプを行い、日中は3～4時間おき、毎日03:00にフルバックアップを行うようスケジュールしている。結果：ダンプがプルしているときでも、レスポンスタイムは短い。マーケティングのピーク時には一時的にフルバックアップを停止しています。.

ケース2：177GBのDBと多数のエディターを持つ大規模な雑誌。mydumperをzstdで8-16スレッドに設定、, -シングル・トランザクション とテーブル単位の分割[4][6]がある。Binlogはインクリメンタルな変更を保存し、フルバックアップはタイムスロットに切り替える。エッジキャッシュは読み込みアクセスを大幅に削減するため、エクスポートが中断されることはほとんどない。リストアプロセスはレポに文書化されており、毎月リハーサルを行っている。.

ケース3：グローバルトラフィックのあるクラウド上のマネージドDB。夜間にメインリージョンでプロバイダー側のバックアップウィンドウを使い、リードレプリカから論理エクスポートを取り出し、低コストのストレージにエクスポートする。IOPSバジェットとネットワーク帯域幅は限られているので、アップロードをスロットルし、高圧縮レベルを避ける。クロスリージョンコピーはピークを避けるために時間遅延を付けて実行する。.

簡単にまとめると

データベースのバックアップは稼働中のシステムに負担をかけますが、私はその影響を次のように考えています。 タイミング, 適切なツールや整頓されたテーブルを使用する。並列ダンプ、単一トランザクション、適切な圧縮により、実行時間が大幅に短縮される [2][6]。頻繁なデータベースのみのバックアップと、トラフィックの少ないウィンドウでの毎日のフルバックアップは、保護と速度のバランスをとる。モニタリングとキャッシングにより、リクエストは流動的であり続ける。リストアセーフとリソースのコントロールを行う者は、ウェブサイトを遅くすることなくコンテンツを保護します。.