ビッグデータ：バックアップはそれなしでは機能しません

データベース管理者として働いている間、私は自分のために1つのルールを作成しました。これは多くのDBAが順守しています。 これは、すべてのデータベース管理者の「ゴールデン」ルールです。バックアップがない場合は、データベースに対して深刻なことをしないでください。 データベースパラメータを大幅に変更する場合は、データベースメンテナンス操作などを実行してください。 -常にその前に、バックアップ操作を実行する必要があります。 この原則は長い間機能し、成果を上げました。いくつかの場合でも、特定の時点でデータベースを復元するのに役立ちました。



最近、サイズが20テラバイトのデータウェアハウスをバックアップする手順の開発を任されました。 確立されたバックアッププラクティスを使用して、このような手順を開発すると同時に、RPO（回復ポイント目標）とRTO（回復時間目標）のフレームワークに適合させようとしました。 これらの特性は両方とも時間で測定され、以下を表します。RPOは許容されるデータ損失の許容量、RTOは許容されるダウンタイム、またはデータベースを回復する時間です。 これが最も興味深いことの始まりです-どのように計算または計算しても、開発されたバックアップ手順はこのフレームワークに適合したくありませんでした-バックアップが必要なデータが多すぎました。 最良の場合、多数の予約と条件があるため、データベースは数時間で復元され、このビジネスには余裕がありませんでした。 通常の状況では、データベースに重大な制限や条件が課されていない場合、復元には数日かかります。 これは、許容できる時間内にバックアップを「削除」することが不可能であるという事実によってさらに悪化しました。また、数日かかり、データベースに大きな負荷をかけました。 このデータベースは現在のバージョンの増分バックアップをサポートしていないことをすぐに言わなければなりません。 おそらく、インクリメンタリティーを得ることができれば、ゲームはろうそくの価値があり、この場合、従来のバックアップ手順には生命権があります。



ここでのバックアップ手順が実行不可能であることを認識して、私はこの問題の既存の解決策を探し始めました。 誰もそのような量の情報をバックアップしないことがすぐにわかりました。 このサイズのデータ​​ベースのバックアップコピーを作成できるようにする方法はいくつかあり、時間的に多少関係があります。

増分

データベースが増分バックアップをサポートし、データベース内の永続的な変更のサイズが比較的小さい場合、一定の間隔で増分バックアップ手順を実行しようとすることができます。 ただし、この方法はすべての人に適しているわけではなく、このバックアップをデータベースの2番目のコピーに絶えずロールする必要があるという意味で不便です。 ここでは、増分バックアップが最後の手段である可能性が最も高く、増分を使用すると、データベースの余分な負荷を取り除き、変更されたデータのみをバックアップできます。 それにもかかわらず、多くの条件では、この決定は生命に対する権利を持っていますが、私の意見では最善ではありません。

複製

最も一般的な解決策の1つは、新規および変更されたデータをデータベースの1つ以上のコピーに複製することです。 トランザクションレベルとファイルシステムレベルの両方で、このような複製を可能にする多くのテクノロジがあり、同期または非同期のどちらでも可能です。 このような複製の利点は、データベースのほぼ正確なコピーを取得できることです。 レプリケーション中のエラートラップメカニズムは、原因を迅速かつ簡単に理解し、その結果、迅速に修正できます。 最大の欠点は、これらの技術の重い負荷と高いコストです。 ただし、他の手段を使用してデータベースのバックアップを最新の状態に保つ機能がない場合、レプリケーションは、超大規模データの最もよく使用されるソリューションの1つであり、今後も使用される予定です。

ダブルETL

原則として、データウェアハウスに入る前に、データはETLまたはELT手順を通過します。 略語ETL自体は、データがそれに応じて変換され、データウェアハウスに到達する前に余分なデータが切り捨てられることを示しています。 このプロセスは並列化できます-つまり 1つのデータウェアハウスではなく、2つ以上でデータをロードします。 したがって、必要な数のデータウェアハウスのコピーがあります。 ただし、これにも関わらず、このアプローチには重大な欠点があります。データのロード中にエラーや不整合が発生するため、多くの場合、コピーは同一ではありません。 どのコピーがより正確であるかは必ずしも明確ではありません。 一部のビジネスではこのような矛盾を許容できるかもしれませんが、金融会社について話している場合、この仮定には存在する権利がありません。 エラーの検証と修正のための複雑な手順を開発できますが、原則として、これはプロセス全体を複雑にし、遅くするだけです。 このアプローチを要約すると、限られた数のケースに適用できると言えます。



すでに明らかになっているように、そのようなボリュームをバックアップから復元する方法はどこにも適用されません-数日、さらには数週間かかります。 メインデータベースに障害が発生した場合に機能を復元する主な方法は、データベースの作業用コピーに切り替えることです。 このコピーの関連性を維持するために、いくつかの方法が使用されています。そのうちのいくつかを上記にリストしました。 データベースのコピーを保存し、障害が発生した場合に復元するなど、バックアップの従来のアプローチは、非常に大きなボリュームのデータベースでは機能しません。たとえば、遠くに行く必要はありません。 上記のすべてをまとめると、ヘッダーの適切な場所にコンマを入れたいと思います。バックアップはできません。バックアップなしで作業できます。