Ё dcloud詳細: 阿里雲RDS MySQLデータベースバックアップと地域間災害復旧実戦
インターネットプロジェクトをしている人は、誰が何度もスリルのある瞬間を経験したことがないのか?
「生産データベースを誤って削除する」、「機械室の光ケーブルが切断された」、「ウイルス暗号化を脅迫する」など、セグメントのように聞こえる事故は、一度発生すれば、ある会社を直接閉鎖することができる。
多くの人が阿里雲RDS MySQLを購入し、「自動バックアップ」を注文したら万事順調だと思っている。しかし、クラウドルームがある都市全体が極端な自然災害に見舞われたり、アリババクラウドのアカウントが盗まれたり、ハッカーがクラウドバックアップを削除したりした場合、どうすればいいと思いますか?
今日は虚しい概念を話さず、直接ハードコアの干物に乗る。あなたを連れて
ゼロから、本当に命を守るRDS MySQLバックアップと地域間の災害復旧システムを構築する
。全編の実戦演習は、でたらめを言うことはない。
コア災害復旧ロジック: 私たちの目標は何ですか?
着手する前に、まず私たちが実現しようとする「三重の防御ライン」のアーキテクチャを一目見ておきましょう。
プレーンテキスト
【生産データベース】
│
-- 防御線1 --> 【ローカル自動化バックアップ】 (誤削除防止、日常故障防止)
│
-- 防御線2 --> 【地域間バックアップ同期】(防城市級機械室災害)
│
└ -- 防御線3 --> 【異郷異機引き上げ回復】 (実戦演習、バックアップが本当に使えるようにする)
最初のステップ: ローカル自動バックアップの構成 (防御線1: 日常的なセキュリティ)
阿里雲RDSはデフォルトでバックアップをオンにしますが、デフォルトの構成は「十分ではない」または「十分ではない」ことが多いです。手動で最適化する必要があります。
1.バックアップポリシーの調整
阿里雲コンソールにログインし、「クラウドデータベースRDS版」にアクセスします。
左側のメニューで「インスタンスリスト」をクリックして、MySQLインスタンスに入ります。
左側のナビゲーションバーで「バックアップと復元」を見つけて、右側の「バックアップポリシーの設定」をクリックしてください。
2.重要なパラメータは次のように調整します
データバックアップサイクル: 毎日チェックすることを強くお勧めします (デフォルトは数日おきにバックアップされる可能性があります)。わずかなストレージ料金を節約するためにリスクを冒してはいけません。
データバックアップの保持期間：本番環境では最低でも30日を推奨します。業界にコンプライアンス要件 (金融、医療など) がある場合は、より高く調整する必要があります。
バイナリログのバックアップ：必ず有効にしてください！ これが「正確に秒レベルの回復」を実現する鍵です。Binlog保持時間は少なくとも7日間を推奨します。
ステップ2: 地域間バックアップ同期をオンにする (防御線2: 防城市級災害)
もしあなたの生産データベースが「北京」の機械室にあるなら、あなたのローカルバックアップも北京に存在します。万が一、北京全域のクラウドインフラに稀に発生する障害が生じた場合、あなたのバックアップはまったく復旧できません。
このとき、私たちはバックアップを自動的に数千キロ離れた別の都市 (例えば「深セン」や「上海」) に同期する必要がある。
1.地域間バックアップをオンにする
また、 [バックアップ・リカバリ] ページで、 [地域間バックアップ設定] タブに切り替えます。
「修理」をクリックします
設定を変更し、ステータスを「オン」に変更します。
目的地域: あなたの生産室と物理的な距離が遠い都市を選ぶ。例えば杭州で生産して、異郷で北京か深センを選びます。
2.バックアップタイプ選択
「地域間データバックアップ」と「地域間ログバックアップ」にチェックを入れます。
注意: 地域間の同期はローカルでバックアップが完了した後、阿里雲バックグラウンドで非同期的に転送され、あなたの生産データベースのイントラネット帯域幅とパフォーマンスを占有することはありません。
第三ステップ: 実戦演習 ― オフサイトでデータを引き上げて回復する (重点)
バックアップはもっとうまくできていて、回復を練習していなければ、それはただの「雪定中傷のバイナリファイル」である。肝心な時に使えるかどうか分からない。
シーンをシミュレートします
北京の生産倉庫は完全に麻痺しているので、深センの機械室で地域を越えたバックアップで新しいデータベースを引き出す必要がある。
シーンA: 新しい「クローンインスタンス」に戻す (最も安全で、最も推奨)
完全でそのままのデータが必要な場合、またはデータを数日前の特定の時点に復元する必要がある場合に、この方法を使用します。
阿里雲RDSコンソールにログインして、地域を越えてバックアップする目的地都市 (深センなど) に切り替えます。
左側のメニューから「バックアップリカバリ」に入り、「地域間バックアップ」リストをクリックします。
あなたが回復したいそのバックアップファイルを見つけるか、または「任意の時点で回復」をクリックしてください。
重要な選択: 履歴データのリカバリ先: 「新しいインスタンス」を選択します。時間選択: 過去のある年のある月のある日、ある分のある秒まで正確にチェックすることができます。これがBinlogログバックアップの威力です。
「次へ」をクリックすると、一時的な「クローンデータベース」を購入することができます。
支払いが開通すると、阿里雲は自動的にオフサイトのバックアップをダウンロードし、Binlogログを再生します。約10 ~ 30分 (データ量に依存) 、あなたの歴史データを含む新しいデータベースが深センの機械室に生々しく現れた。
シナリオB: バックアップファイルをダウンロードし、ローカルまたは自己構築サーバに手動でリカバリします
会社がクラウドで新しいインスタンスを作るためにお金を使いたくない場合や、ローカルのオフィスネットワークのサーバにデータをダウンロードしてデータ分析を行う必要がある場合は、手動でダウンロードできます。
1.ファイルのダウンロード
「地域間バックアップ」リストで、対応するデータバックアップを見つけ、右側のをクリックします
「ダウンロード」
(ダウンロードアドレスが生成されていないことが通知された場合は、まず「インスタンスバックアップダウンロードアドレスを生成」をクリックし、数分待ってからダウンロードします)。
💡阿里雲RDSが提供する物理バックアップファイルは、通常、 .tar.gzまたはPercona XtraBackupツールを使用してパッケージ化されています。
2.Linuxサーバを構築して実戦を再開する (NRE/XtraBackupを例にとる)
もしあなたがダウンロードしたのは物理バックアップ圧縮パックで、解凍後にPerconaツールを使って回復する必要があるとします。
最初のステップでは、XtraBackupツールをインストールします (バージョンはMySQLバージョンに厳密に対応している必要があります
MySQL 8.0はXtraBackup 8.0を使用する必要があります)。
ステップ2では、解凍と準備コマンドを実行します
バッシュ
#1.きれいなデータディレクトリを作成する
Mkdir-p /var/lib/mysql _ recovery
#2.ダウンロードした解凍ファイル (解凍済みと仮定) データを準備します
Xtrabackup--prepare --target-dir =/var/lib/mysql _ recovery
このステップの役割は、バックアップ時に提出できなかったトランザクションをロールバックし、提出されたトランザクションをディスクに書き込み、データの整合性を保証することです。
ステップ3では、権限を変更し、MySQL構成ファイルを変更します
バッシュ
Chown-R mysql:mysql /var/lib/mysql _ recovery
自分でMySQLを構築します
オンラインf
で、を
Datadir
これを指す
/Var/lib/mysql _ recovery
ディレクトリ、MySQLサービスを再起動すると、データは完全に復活します。
生産環境は血と涙の歴史を避けます。
データとバックアップを同じ阿里雲アカウントの下に置かないでください! 伝説の「従業員が倉庫を削除して走る道」や大江の南北の高周波で発生した「企業の上司の口座番号が盗まれた」と遭遇した場合ハッカーが入った最初のことは、あなたのすべてのRDSとバックアップを完全に解放することです。究極のセキュリティ案: もう一つの完全に独立した、経営幹部が管理している阿里雲アカウントの下で、低コストの軽量サーバまたはOSSストレージを開設し、毎日自動スクリプトを通じてアカウント間でデータベースをバックアップします。
「ローカルストレージ料金」と「地域間転送料金」に注意してください。超過した分は高額な貯金料をいただくことになります。地域間の同期にも少量のネットワーク転送料金がかかります。お金を節約する妙案: ログバックアップ (Binlog) については、業務の書き込みが非常に頻繁であれば、ログの量は非常に怖い。ローカルログの保持時間を適切に3 ~ 5日に短縮し、オフサイトの保持時間を長くして、コストと安全のバランスを取ることができる。
定期的な演習は、第1四半期に一度に多くの技術チームがバックアップスクリプトを書いたとしても、高閣になっている。その結果、1年後に事故に遭遇し、バックアップをダウンロードしたとき、バージョンが互換性がないか、その年のスクリプトにパラメータが書かれていないため、バックアップファイルはすべて壊れていることがわかりました。「回復演習」を技術チームのKPIに書くことは、本当の災害を受け入れることである。
未然にならないように、今夜はあなたの阿里雲RDSバックアップ戦略をチェックしましょう!