大規模なデータベースでの誤ったデータ更新を回避するために実行するプラクティスは何ですか？
本番環境への導入前の一般的なアドバイスは、最初にDBをバックアップすることです。このように、新しい更新にデータの損失や論理データの破損の原因となる可能性のある問題がある場合でも、古いレコードを比較して修正するためのバックアップがあります。
ただし、これは、DBサイズが数GBになるまでうまく機能します。 DBサイズが巨大になると、バックアップの完了に長い時間がかかります。コードの配置における論理的な問題による論理的なデータ破損を回避するために、そのような状況で従うべきいくつかのベストプラクティスは何ですか？
私たちのソフトウェアアップグレードのために顧客向けに本番データベースの更新を定期的に担当した人物として、エラーを最小限に抑えるための最善の方法は、更新をできるだけ簡単にすることだと言います。
特定のレコードではなくすべてのレコードを変更できる場合は、それをお勧めします。
つまり、状態の変更が必要なレコードのIDのリストが提供された場合、プログラムのコンテキストで更新が行われている理由を自問する必要があります。更新する必要がある10個のレコードのうち、テーブルのみhas 10個の要素である可能性があります。したがって、概念的に行うすべてのことは、すべてのレコードの状態を更新することであるかどうかを自問する必要があります。
挿入できるのであれば、それが望ましいです。
レコードを追加する行為は自己完結型です。つまり、レコードを追加することの副作用は1つだけであり、それは以前には存在しなかったレコードの存在です。したがって、存在してはならないレコードを追加しない限り、問題はありません。
削除を回避できる場合は、それが望ましいです。
削除を実行している場合は、バックアップがないと回復できないデータを削除することになります。可能であれば、レコードを物理的に削除するのではなく、状態を変更してレコードを無効にできるようにデータを整理してください。余分なデータはパーティションに配置するか、問題がないことを確認してから後で完全に削除することができます。
一貫した更新ポリシーを用意します。
レコードを更新する必要がある場合は、いくつかのことが起こります。
- あなたの記録は存在しません。
- レコードは存在しますが、すでに変更されています。
- レコードが存在し、変更が必要です。
何かが予定通りに進まない場合の行動方針を決定するポリシーが必要です。簡単にするために、特定のテーブルだけでなく、このタイプのany状況でこのポリシーを全面的に一貫して適用する必要があります。これにより、後でデータを回復しやすくなります。一般に、私のポリシーは、後で再実行できるようにスクリプトを記述することです。スクリプトが失敗した場合、適切な調整を行って再実行できることを知っておくのはいいことですが、自分に最も適した独自のポリシーを自由に選択できます。
バックアップ
これは、実稼働環境で更新を実行する前にバックアップを実行することを決して言い訳しません！バックアップがあっても、バックアップを使わなければならないのは失敗だと思います。 最悪の場合のシナリオであっても、データが失われる可能性はありません。
結論
あなたはいつもそれをあなたのやり方で持つことができるとは限らないでしょう。テーブルスキーマはユーザーが決定することはほとんどありません。そのため、実行することが予想される更新の種類は複雑で危険なものになります。ただし、問題がある場合でも、重要なリスクなしに簡単に更新を行うため、これらの点を覚えておくことは役立ちます。
幸運を！
これは広大な領域です。ですから、この質問はかなり短い時間で締め切られると思いますが、私の頭上では（yugeデータベースの元DBAとして）：
マート/リポジトリ
更新用の個別のデータベースと、誰もが使用する個別のデータベースがある場合、リスクを軽減できます。次に、さまざまなチェックが行われた後、データを1つのDBから別のDBにコピーするだけのケースです。マート/リポジトリはそれが時々記述される方法ですが、プライマリ/セカンダリ、マスター/スレーブなどがあるかもしれません。
ソースコード
変更される可能性のあるすべてのものについて、データが更新された方法に関連するソースコードを用意します。これらの数はDBごとに異なりますが、ユーザー、ロール、データフィード、コードモジュールなどごとに1つある場合があります。
作成/更新日
問題が発生した場所を追跡する際に非常に役立つのは、すべての行のデータを作成および更新することです。次に、更新された行が一目でわかります。
[〜＃〜] etl [〜＃〜]
データベースの更新がデータファクトリの一部として行われる場合、フラットファイルから以前のヴィンテージを復元できる場合があります。
バックアップ
もちろん、フルバックアップには多くのスペースが必要ですが、通常のシナリオでは、フルバックアップを定期的に（たとえば、毎週）実行し、部分的なバックアップをより頻繁に（毎日など）実行します。
ポイントインタイムリカバリ
使用しているRDBMSに応じて、一部のポイントインタイムリカバリがサポートされます。これにより、良好な状態が判明した時点までロールバックできます。ただし、これには大量のストレージが必要であり、どれだけ前に戻りたいかによって増加します。
監査
監査テーブルがあると、誰が（または何が）行を更新したかがわかります。これは、調査の開始点として役立ちます。
履歴
一部の重要なテーブルでは、更新時に適切な行のコピーが作成されるため、必要に応じてデータを復元できます。
データ検証
データが保存される前に、基本的なデータタイプのチェックに加えて、基本的な検証チェックが実行されることを確認します。
参照整合性
参照整合性は特効薬ではありませんが、データが適切に構造化されていることを確認するのに役立ちます。
多くの場合、「ワンショット」の更新を行う場合は、運用環境のバックアップを取り、テストサーバーに復元します。次に、一連のテストを作成し、ワンショットを実行します。テストによってデータが変更されたことを確認し、更新が成功し、予想どおりにデータが変更されることを確認します。これはドライまたはトライアルランと呼ばれます。これを行うことをお勧めします。
これはワンショットが成功するという良い感覚を皆に与えます。データは試用日から更新されるため、100％保証することはできませんが、自信と成功要因を高めます。これは、プロダクションのコピーを使用しているために発生する問題についての現実的な考えも提供します。これで、なんらかの理由で更新が失敗した場合、必要に応じて、復元の前にいつでもバックランに進むことができますが、ドライランの問題を見つけて修正する必要がありました。
データベース全体を取得できない場合（本当に大きい場合）、サンプルサイズを小さくしてエクスポートし、実際のデータに対して更新（小規模なドライラン）を実行します。テストが可能な限り完全であることを保証するために、可能であればデータセット全体を使用したいと思います。