腾讯雲TDSQLデータベース入門: 企業クラスアーキテクチャのバックアップと実戦回復
クラウドサーバとオープンソースMySQLをプレイしたことがある友人は、シングルデータベースは普段は上手に練習しているが、企業クラスの電気商、金融、または高合併のビジネスシーンになって、シングルアーキテクチャが壊れていることを知っているはずだ。企業が本当に必要としているのは、多活、強力な一貫性、災害を自動的に許容できる分散データベースです。
テンセントクラウドの
TDSQL
出てきたのはこれです。これは腾讯自研の企業クラスの分散データベースで、MySQLの性能と完璧に互換性があるだけでなく、基礎に分散アーキテクチャがセットされている。今日、私たちはあいまいなPPT理論については話しません。コアの痛点から直接切り込んで、手を持って企業クラスのデータベースの命脈を練習します --
バックアップとリカバリ
。
第一段階: 基礎を打ち破り、TDSQLの企業レベルの三層構造を理解する
手術 (バックアップ・リカバリ) を行う前に、TDSQLの人体構造を理解しなければならない。そうでなければ、バックアップ・ファイルがどこに保存されているのか、どのようにリカバリされているのかさえ分からない。TDSQLの分散アーキテクチャは、主に次の3つのコアコンポーネントで構成されています
Proxy (ゲートウェイレイヤー): それはゲートウェイです。クライアント、Appがデータベースに接続されている場合、接続されているのはProxyです。Proxyは、要求、SQL解析、ルーティングの配布を担当します。自分がまだ普通のシングルMySQLを使っていると感じます。
Shard/DB (ストレージレイヤー): これは本当に仕事をし、データを保存する場所です。企業レベルのTDSQLは、通常、「1つのマスター2つのバックアップ」の高可用性アーキテクチャを採用しています。マスターノード (Master) がハングアップし、強力な整合性レプリケーション (Multi-Sync) はデータがわずかに失われないようにし、秒レベルで自動的にスペアノード (スレーブ) をトップにします。
ZooKeeper/schedオイラー (管理スケジューリング層): これは脳です。すべてのノードのステータスの監視、構成の配布、バックアップ命令の開始を担当します。
私たちが今日話している「バックアップ」は、経営陣がストレージ層に指示を出して、データを梱包して、オフラインストレージ (通常はテンセントクラウドCOSオブジェクトストレージ) に安全に吐き出す過程である。
第二段階: 企業レベルの全量と増分バックアップの実戦
企業の本番環境では、バックアップ戦略は一般的に次のようになります
定期的な完全バックアップリアルタイム物理ログ (Binlog) バックアップ
。
フル・バックアップ: 通常、午前2:00-4:00などのビジネス・ピーク時には、物理データを完全にエクスポートします。
増分バックアップ: 24時間無停電でBinlogをバックアップします。この2つを組み合わせることで、データベースを過去30日間の任意の1秒の状態 (PITR、時点ベースのリカバリ) に戻すことができます。
1.コンソール構成自動化ポリシー (安心フロー)
腾讯クラウドコンソールにログインし、「分散データベースTDSQL」を検索します。
インスタンスリストでインスタンスIDをクリックし、左側のメニューで「バックアップリカバリ」-> 「バックアップ設定」を見つけます。
ポリシー構成仕様: 全量バックアップサイクル: 企業の本番環境では、少なくとも週に2回 (月曜日、
木曜日未明) 、データの変動が大きいコアビジネスのアドバイスは毎日1回。バックアップ保存日数: 通常は30日に設定されていますが、金融レベルのコンプライアンス要件には通常180日以上かかります。自動バックアップ時間: ビジネスのピークをずらし、「午前」を選択する必要があります。
2.コマンドラインが手動で全量バックアップをトリガーする (緊急フロー)
午後3時に重大な新機能を発表するには、データベーステーブル構造 (DDL) を修正する必要がある。ロールオーバー防止のため、リリース前に一度手動でバックアップする必要があります。
TDSQLの管理ノード (赤兎管理台またはAPI/CLI経由) では、次の手動バックアップロジックを実行できます
バッシュ
# 例: tdsqlツールによるバックアップ・コンポーネント・コマンドの呼び出し
Tdsql_backup -- instance_id = tdsql-abc12345 -- backup_method = スナップショット -- type = full
この時点で、バックグラウンドのバックアップコンポーネント (Backup) は、マスターノードのパフォーマンスに影響を与えないように、直接バックアップノードに行って物理スナップショットを取得し、テンセントクラウドのコールドストレージに非同期的にアップロードします。
第三段階: スリリングな実戦回復 (二種類の災害シーン)
バックアップがどんなにうまくいっても、回復できないのはゼロに等しい。私たちは2つの最も輸送と開発血圧が上昇する災害シーンを直接シミュレーションした。
シーン1: 脅迫ウイルスまたは倉庫全体のハードウェア破損 (倉庫全体のファイルバック) に遭遇しました。
この時、あなたの生産庫は完全に廃棄されたので、完全な歴史版「起死回生」を探す必要があります。
実戦ステップ:
水源を遮断する: 直ちにセキュリティグループまたはProxy層で外部アプリケーションのすべての書き込み要求を遮断し、二次汚染を防止する。
ログバックプロセスを起動する: TDSQLコンソールで、「バックアップ・リカバリ」-> 「インスタンス・ファイルバック」をクリックします。「新規インスタンスバック」を選択します (元の生産インスタンスで直接カバーしないでください!企業の標準的なアプローチは、まず「一時的な新しいインスタンス」に戻って、間違いがないことを検証してから、トラフィックをカットすることです)。バックタイムを選択します。回復したい瞬間まで正確です。
バックグラウンド運転ロジック: この場合、TDSQLのスケジューラはCOSに行って14時から最も近い午前中に完全にバックアップし、解凍して新しいマシンに復元しますそして、午前から14:00までのすべてのBinlog増分ログを再生します。
検証とストリームカット: 数分から数十分後に、新しいインスタンスが準備されます。開発者はデータをチェックし、間違いがないことを確認した後、アプリケーション構成のデータベース接続 (VIP/Proxyアドレス) を修正し、新しいインスタンスをポイントし、webサイトを再びオープンした。
シーン2: 豚のチームメイトの手ぶれが実行されました。
DELETE FROM table;
Where条件が追加されていません (一部テーブルフラッシュバック)
このようなシーンは一番頭が痛いです。データベース全体の99% のデータは正しいですが、このコアテーブルだけが誤って削除されました。倉庫全体のファイルバックをすると、今日を意味します
他のお客様から発生した新しい注文はすべて消去されます。
最適な実戦案:表級抽出法
TDSQL自体は、本番インスタンスで直接ローカルカバーを行うことをお勧めしません。安全な標準的な操作フローは次のとおりです
一時的なライブラリ: シーン1の方法で、データベースを「誤操作の1分前」の状態に戻し、一時的なインスタンスを生成します。
単一テーブルのエクスポート: mysqldumpツールを使ってこの一時的なインスタンスに接続し、誤って削除されたテーブルを個別にエクスポートしますbashmysqldump-h一时ライブラリIP -u admin -p --tables my_database damaged_table > /root/recovered_table.sql
本番ライブラリのインポート: recovered_table.sqlファイルをチェックして、データがきれいであることを確認します。実際の本番環境データベースに接続して、このSQLファイルを入れて、正確な定点修復を実現します。
このような「梁を盗んで柱を変える」操作は、削除されたデータを救っただけでなく、オンラインの他の業務が中断しないことを保証した。
第四段階: 企業レベルのデータベースセキュリティのピット血涙歴
マスターノード (Master) で論理的なバックアップを絶対にしないでください。高同時では、マスター・ライブラリ・ロック・テーブルやCPUが急増し、オンライン事故が発生します。TDSQLの自動バックアップはデフォルトでバックアップノードで行われます。データを手動でエクスポートする場合は、ノードIPを準備してください。
定期的に「災害準備演習」を行う: 多くの会社のバックアップファイルがクラウドに横たわっていて、毎日生成されているように見えて、結果は本当にファイルを返す時にバックアップファイルが破損していることを発見した。企業は四半期ごとか半年ごとに、バックアップファイルを取り出して、テスト環境で本当に回復訓練をして、データがいつでも使えるようにしなければならない。
強力な一貫性を活用: TDSQLインスタンスを購入するときに、必ず「強力な一貫性同期」がオンになっているかどうかを確認します。強い一貫性の下でのみ、プライマリ・バックアップの切り替えとバックアップ・ファイルバックは、真のRPO = 0 (データ・ゼロ損失) を実現します。
まとめ
企業レベルのデータセキュリティを前にして、どんな幸運な心理も自分に穴を掘っている。腾讯雲TDSQLの三層構造と自動回復メカニズムはすでに基礎的に複雑な分散論理をカプセル化している。設計者や運送次元としてやるべきことは
バックアップポリシーを設定し、コアログを守り、「一時ライブラリに戻って再検証」の赤い線の流れを厳格に実行します
。手には食糧があり、心は落ち着いていて、たとえ極端なデータ災害に直面しても、30分以内に談笑の間にシステムを復活させることができる。