すべてのサービスレベル契約を満たす高可用性およびディザスタリカバリ計画の計画と展開は重要な作業であり、SQLServerの本来の長所と短所を非常に明確に理解する必要があります。要件を機能の組み合わせと照合する場合、重要な詳細の一部が見過ごされる可能性があります。この投稿では、ソリューションに忍び寄る可能性のあるいくつかの一般的な歪みと悪い仮定について説明します。最終的には、マークを見逃してしまいます。リカバリポイントとリカバリ時間の目標について。ここで詳しく説明する歪みや自己妄想の例のいくつかは、さまざまな機能に一般化することができ、いくつかは機能固有のものです。
「プロジェクトを最初に立ち上げたときに災害復旧計画をテストしましたが、それが機能することはわかっています」
私は、ディザスタリカバリのアプローチを実際に「正しく」行ったクライアントと協力してきました。しかし、誰もがソリューションの有効性に自信を持った後は、他の災害復旧演習は二度と実行されませんでした。もちろん、その間、データ層とアプリケーションは時間の経過とともに変化し続けます。これらの変更により、アプリケーションにとって重要な新しいオブジェクトとプロセスが導入されます。また、立ち上げ後もすべてが静的なままであっても、人員の離職率とさまざまなスキルセットを考慮する必要があります。今日のスタッフは、ディザスタリカバリの演習を成功させることができますか？そして、最高のスタッフでさえ、継続的な練習が必要です。
「同期データベースミラーリングを使用しているため、データが失われることはありません」
2つのSQLServerインスタンス間で同期データベースミラーリングを使用していて、各インスタンスが別々のデータセンターにあるとします。この例では、データセンター間の数マイルの同期データベースミラーリングセッションであるにもかかわらず、トランザクション遅延が許容可能であると想定します。データベースミラーのフェイルオーバーを手動で制御したいので、目撃者はいません。
ここで、ディザスタリカバリデータセンターがなくなったとしましょう。ただし、プライマリデータセンターは引き続き利用できます。プリンシパルデータベースはミラーデータベースから切断されていますが、接続とデータ変更を引き続き受け入れています。今の「データ損失なし」の要件はどうですか？切断されたプリンシパルに対してトランザクションがさらに1時間実行された場合、プライマリデータセンターも失われた場合の計画は何ですか？
「当社の事業主は、最大12時間のデータを失う可能性があると言っています」
組織内の複数の個人に複数回質問することが重要です。 「12時間のデータ損失は許容できる」と誰かが言った場合は、もう一度尋ねるか、そのデータ損失の結果がどうなるかを尋ねます。他の人にも聞いてください。彼らはあなたにはるかに厳しい要件を与えるかもしれません。リカバリーポイントの目標には、ある程度の交渉と、いくつかの思慮深く慎重な議論が必要であることがわかりました。
「[データベースミラーリングまたは可用性グループ]を使用しているため、災害が発生した場合に必要なものをカバーしています」
データベースミラーリングと可用性グループは確かにデータベースレベルであなたを保護するために使用できますが、他のすべてについてはどうでしょうか？ログインはどうですか？ SSISパッケージ？仕事？非完全復旧モデルデータベース？リンクされたサーバー？
「SQLServer機能XYZを使用しているため、処理中のトランザクションが失われることはありません」
いいえ、ごめんなさい。一部の機能では透過的なリダイレクトが可能ですが、これはフェイルオーバー時に開いているトランザクションを保持および永続化することと同じではありません。現在、この機能を提供するSQLServer機能はありません。
「このアプリケーションのデータ層をサポートするチームはSQLServer機能XYZを嫌っていますが、外部コンサルタントから推奨されたものであるため、これを進めています」
人々がSQLServerの機能に関して特定のバイアスを開発しなかったとしたらいいのですが、そうではないことがよくあります。一緒にいないスタッフにソリューションを強制しようとすると、事前に決定された失敗のリスクがあります。過去に支援したHA/DR演習の一環として、特定の機能に関する人々の過去の経験について常に興味を持っています。たとえば、何百ものフェールオーバークラスターインスタンスを非常にうまく活用している企業もあれば、以前のバージョンのエクスペリエンスが悪いためにそれらを回避している企業もあります。ソリューションを計画するときは、推奨されるソリューションの展開とサポートを最終的に担当するスタッフの歴史や素質を無視することはできません。
「DBAとして、データ層に使用するHA / DRテクノロジーを決定するため、今後は可用性グループを使用します」
データベース管理者は、他のチームとほとんどまたはまったく関与せずにデータベースミラーリングを設定できる可能性があります。現在、可用性グループでは、データベース管理者がすべてを自分で行うことができたとしても、そうするのは賢明ではないかもしれません。結局のところ、ディザスタリカバリの目的で可用性グループを展開する場合は、ディザスタリカバリ操作に関係するすべての人に、ソリューションと、オンラインに正常に戻ってデータをリカバリするために必要な要件を認識しておく必要があります。可用性グループでは、Windows Serverフェールオーバークラスター、クォーラム構成、ノード投票、可用性グループリスナーなどについて検討する必要があります。ソリューションを促進するために他の人が必要になる場合は、他の人が最初の推奨事項に関与していることを確認してください。
「可用性グループを使用しているため、読み取り/書き込みレプリカが停止した場合に読み取り専用の可用性を確保できます」
これは、「whatif」シナリオの一例にすぎません。機能を実装する場合は、障害が発生する可能性のあるさまざまな方法を想像し、それをテストして、要件がまだ満たされていることを確認する必要があります。たとえば、SQL Server 2012可用性グループの非同期読み取り専用レプリカが読み取り/書き込みレプリカが使用できないときに使用可能になると考える場合、Unable to access database 'XYZ' because its replica role is RESOLVING which does not allow connections 本番環境でのメッセージ。
「SQLServerの機能XYZをテストしましたが、フェイルオーバーが高速だったため、復旧時間の目標を簡単に達成できることがわかりました」
ユーザーデータベースレベルの高可用性のためにデータベースミラーリングを使用することにしたとします。迅速なフェイルオーバー（秒単位で測定）が必要であり、テスト中に実際に迅速なフェイルオーバーが見られます。しかし、それは現実的なテストでしたか？かなりのワークロードをプッシュしていましたか？データベースミラーリングの例では、フェイルオーバー操作の最も長い部分がREDO操作用である可能性があります。現実的なワークロードを推進していない場合、フェイルオーバーが実際に「高速」であるとは言えません。
「災害が発生し、データを回収して調整する必要がある場合は、その時が来たらそれを把握します」
これは難しいものです。災害が発生し、セカンダリデータセンターを運用可能にする必要があるとします。セカンダリデータセンターで最も重要なデータベースのサービスを強制することにしました。これで、データ変更の系統が分割されました（プライマリデータセンターの一部の調整されていない行と、セカンダリデータセンターの新しい変更）。最終的に、プライマリデータセンターはオンラインになりますが、HA / DRソリューション全体を再確立する前に、データを回収して調整する必要があります。職業はなんですか？あなたは何ができますか？この議論が簡単なものになることはめったになく、購入したソフトウェアパッケージ、データ層の複雑さ、自由に使えるデータコンバージェンスツールなどのいくつかの要因に依存する可能性があります。実際、話し合いはたいてい非常に難しいので、人々はまったく話し合いません。ただし、データがセカンダリデータセンターを設定するのに十分重要である場合、ディスカッションの重要な部分には、データを回収し、災害発生後にデータを調整するための最善の方法を含める必要があります。
概要
この記事には、ソリューションが要件を完全に満たしていると思い込ませる方法の例がいくつか含まれています。これを行うのは人間の本性ですが、データの損失とビジネスの継続性に関しては、私たちの仕事は、私たち自身の信念と仮定をより積極的にテストすることに依存します。