1. 概要 SQL Server 高可用性
高可用性 SQL Server 高可用性とは、ハードウェア障害、ソフトウェアの問題、または計画的なメンテナンスが発生した場合でも、最小限のダウンタイムでシステムを稼働させ続ける能力を指します。高可用性の重要性はいくら強調してもしすぎることはありません。データベースが利用できなくなると、企業は収益の損失、生産性の低下、顧客満足度の低下など、即座に深刻な影響を受けることになります。
高可用性（HA）と災害復旧（DR）はしばしば同じ意味で使われますが、それぞれ異なる障害シナリオに対応します。HAは、サーバーやインスタンスのクラッシュなどの局所的な障害によるダウンタイムを最小限に抑えることに重点を置いているのに対し、DRはデータセンター全体またはリージョン全体に影響を及ぼす大規模な災害からの復旧を目的としています。
2 つの重要な指標が HA 計画を導きます。
- 目標復旧時間（RTO）は、障害発生後の最大許容ダウンタイムを定義します。
- 回復ポイント目標 (RPO) は、許容可能な最大のデータ損失を指定します。
可用性は一般的に「9」の単位で測定されます。99.9% (3つの9) では年間 8.76 時間のダウンタイムが許容され、99.99% (4つの9) では 52.6 分が許容され、99.999% (5つの9) では年間のダウンタイムがわずか 5.26 分に制限されます。
2. SQL Server 高可用性ソリューションの概要
2.1 HAソリューションのカテゴリー
SQL Server 高可用性ソリューションは、いくつかの側面で分類できます。
- インスタンス レベルの保護とデータベース レベルの保護: フェールオーバー クラスター インスタンスなどのインスタンス レベルの保護は、すべてのデータベースとサーバー オブジェクトを含むインスタンス全体を保護し、Always On 可用性グループなどのデータベース レベルの保護は、特定のデータベースを保護します。
- 同期データ移動と非同期データ移動: 同期データ移動ではデータ損失はゼロになりますが、遅延が発生する可能性があります。一方、非同期移動ではパフォーマンスが最適化されますが、データ損失が発生する可能性があります。
- 自動フェイルオーバーと手動フェイルオーバー: 自動フェイルオーバーでは手動介入なしでダウンタイムが最小限に抑えられますが、手動フェイルオーバーではより高度な制御が可能になりますが、管理者のアクションが必要になります。
2.2 一般的なHAソリューション
SQL Server 8 つの主要な高可用性ソリューションを提供し、それぞれが特定のシナリオに対応します。
- Always On 可用性グループ
- 包含可用性グループ
- 分散可用性グループ
- フェールオーバー クラスター インスタンス
- SQL Server Replication
- ログ出荷
- データベースミラーリング
- マネージドインスタンスリンク
3. Always On 可用性グループ
Always On可用性グループは SQL Serverのプレミアデータベースレベルの高可用性と災害復旧ソリューションは、 SQL Server 2012。これにより、クエリのオフロード用に読み取り可能なセカンダリ レプリカを提供しながら、データベースのグループを 1 つのユニットとしてまとめてフェールオーバーできるようになります。
他社とのちがい
- 合計最大 9 つのレプリカ (プライマリ 1 つ + セカンダリ 8 つ) をサポート
- 同期コミットモードで最大 5 つのレプリカ (プライマリ 1 つ + セカンダリ 4 つ)
- 同期モードでデータ損失ゼロの自動フェイルオーバー
- クエリのオフロードのための読み取り可能なセカンダリレプリカ
- セカンダリレプリカへのバックアップオフロード
- 自動接続ルーティングのための可用性グループ リスナー
- 読み取りクエリの負荷分散のための読み取り専用ルーティング
- 複数のデータベースがグループとして一緒にフェイルオーバーします
実装手順
- Windows Server フェールオーバー クラスタリング (WSFC) または Linux Pacemaker クラスターを構成する
- すべてのAlways On可用性グループ機能を有効にする SQL Server インスタンス
- データベースが完全復旧モデルを使用し、完全バックアップを持っていることを確認する
- 各レプリカにデータベースミラーリングエンドポイントを作成する
- 可用性グループを作成し、データベースを追加する
- プライマリレプリカとセカンダリレプリカを希望のモードで構成する
- 可用性グループ リスナーを作成して構成する
- 読み取り可能なセカンダリを使用する場合は読み取り専用ルーティングを構成する
- フェイルオーバー手順をテストし、アプリケーションの接続性を検証する
以下のためにベスト
- 最大限の稼働時間を必要とするミッションクリティカルなデータベース
- ローカルHAと地理的DRの両方を必要とする組織
- 読み取りスケール機能を必要とする環境
- レポートクエリのオフロードのメリットを享受できるアプリケーション
- データ損失ゼロ保護を必要とするデータベース
- 協調フェイルオーバーを必要とするマルチデータベースアプリケーション
メリット
- 同期コミットモードでデータ損失ゼロ
- 自動フェイルオーバーによりダウンタイムを最小限に抑えます（通常は数秒）
- 読み取り可能なセカンダリはプライマリの負荷を軽減します
- 共有ストレージの要件なし
- WindowsとLinuxの両方のプラットフォームをサポート
- 災害復旧のための地理的分布
- バックアップ操作をセカンダリにオフロードできる
- アプリケーション接続文字列はフェイルオーバー後も変更されません
デメリット
- 完全な機能を使用するにはエンタープライズエディションが必要です
- Standard Edition は Basic AG に制限されます (データベース 1 つ、セカンダリ 1 つ、読み取り可能なセカンダリなし)
- 複雑な構成と管理
- クラスタリング インフラストラクチャ (WSFC または Pacemaker) が必要
- インスタンスレベルのオブジェクト（ログイン、ジョブ）は手動で同期する必要がある
- 同期モードではトランザクションの遅延が発生する可能性があります
- 複数サーバーのライセンス費用
参考情報
4. 包含型可用性グループ
包含型可用性グループ（導入） SQL Server 2022 では、インスタンス レベルのオブジェクトをレプリカ間で自動的に同期することで従来の Always On 可用性グループを拡張し、ログイン、ジョブ、その他のサーバー レベルのオブジェクトを手動でレプリケーションする必要がなくなります。
他社とのちがい
- インスタンスレベルのオブジェクト（ログイン、ユーザー、ロール）の自動同期
- SQL Server エージェントジョブはすべてのレプリカに複製されます
- データベース権限は自動的に同期されます
- Always On AGのすべての機能が含まれています
- 完全な環境レプリケーションによる簡素化されたフェイルオーバー
- WindowsとLinux両方のプラットフォームをサポート
実装手順
- 確保 SQL Server すべてのインスタンスで2022以降
- WSFC または Pacemaker クラスター インフラストラクチャを構成する
- すべてのインスタンスでAlways On機能を有効にする
- CONTAINED オプションを使用して包含可用性グループを作成する
- 包含されているAGにデータベースを追加する
- AGコンテキスト内でログインとジョブを作成する
- リスナーを構成してフェイルオーバーをテストする
以下のためにベスト
- 簡素化されたAG管理を望む組織
- フェイルオーバーのテストや操作が頻繁に行われる環境
- 多くのインスタンスレベルのオブジェクトを必要とするアプリケーション
- New SQL Server 2022年以降の展開
- フェイルオーバー後の構成の削減を求めるチーム
メリット
- ログインとジョブの手動同期が不要になります
- より高速で信頼性の高いフェイルオーバー
- 管理オーバーヘッドの削減
- アプリケーションはフェイルオーバー後すぐに動作します
- 簡素化された災害復旧手順
- 従来のAG特典がすべて含まれます
デメリット
- 必要 SQL Server 2022以降
- 完全な機能を使用するにはエンタープライズエディションが必要です
- 既存の従来の AG を包含型 AG に変換できない
- すべてのレプリカは包含AG機能をサポートする必要があります
- 従来のAGに比べて複雑さが増す
参考情報
5. 分散可用性グループ
分散可用性グループ（導入） SQL Server 2016 年には、「可用性グループの可用性グループ」アーキテクチャが有効になり、独立した 2 つの AG を別々のクラスター間で接続して、高度な災害復旧および移行シナリオを実現できるようになりました。
他社とのちがい
- 2つの独立した可用性グループを接続する
- 各AGは独自の独立したクラスターを維持します
- クロスプラットフォームサポート（WindowsからLinuxまで）
- 共有クラスタメンバーシップなしのクラスタ間レプリケーション
- 1つのAGが主として機能し、もう1つが副として機能
- 同期モードと非同期モードの両方をサポート
- 地域や大陸をまたぐ地理的分布
実装手順
- 最初の可用性グループ（プライマリ DAG）を作成して構成する
- 2 番目の可用性グループ (セカンダリ DAG) を作成して構成する
- 2つのAGをリンクする分散型AGを作成する
- AG間のデータ同期を構成する
- アプリケーション接続のために各 AG にリスナーを設定する
- フェイルオーバーポリシーとテスト手順を構成する
- クラスタ間の通信とレプリケーションを検証する
以下のためにベスト
- 独立したデータセンターにまたがるマルチリージョンの災害復旧
- Windows から Linux へ、またはその逆のクロスプラットフォーム移行
- オンプレミスを Azure に接続するハイブリッド クラウド シナリオ
- 移行期間の延長を必要とするメジャーバージョンアップグレード
- 複数の独立したフェイルオーバークラスターを持つ組織
- 大陸をまたぐレプリケーションを必要とするグローバル企業
メリット
- サイト間のクラスタ依存関係を分離します
- 真の地理的分散を実現
- クロスプラットフォームのシナリオをサポート
- 各AGは独立してフェイルオーバーできる
- 複雑な移行プロジェクトに最適
- 共有クラスタインフラストラクチャは不要
- 異なる Windows ドメインまたは Linux ディストリビューションにまたがって使用できます
デメリット
- エンタープライズエディションが必要です
- 構成と管理の複雑さが高い
- クラスタリングとAGテクノロジーの両方に対する深い理解が必要
- 標準的なAGよりもトラブルシューティングが難しい
- リージョン間シナリオの追加レイテンシ
- フェイルオーバー手順を慎重に計画する必要がある
参考情報
6. フェールオーバー クラスター インスタンス (FCI)
フェールオーバークラスタインスタンスは、共有ストレージとWindows Serverフェールオーバークラスタリングを使用してインスタンスレベルの高可用性を提供し、システム全体の自動フェールオーバーを可能にします。 SQL Server すべてのデータベースとサーバー レベルのオブジェクトを含むインスタンス。
他社とのちがい
- インスタンスレベルの保護（すべてのデータベースが同時にフェイルオーバー）
- 共有ストレージを使用したアクティブ/パッシブ構成
- 透過的なフェイルオーバーのための仮想ネットワーク名 (VNN)
- アクティブノードに障害が発生した場合の自動フェイルオーバー
- データ損失ゼロ（データの単一コピー）
- サーバーレベルのオブジェクトが含まれています（ログイン、ジョブ、リンク サーバー）
- すべてをサポート SQL Server 回復モデル
実装手順
- Windows Server フェールオーバー クラスター (WSFC) を構成する
- 共有ストレージ（SAN、SMB、Storage Spaces Direct）をセットアップする
- クラスタクォーラム設定を構成する
- インストールを開始する SQL Server 最初のノードのフェールオーバー クラスター インスタンスとして
- FCIにノードを追加する
- 仮想ネットワーク名とIPアドレスを構成する
- クラスタノード間のフェイルオーバーをテストする
- VNN を使用するようにクライアント アプリケーションを構成する
以下のためにベスト
- 既存の共有ストレージインフラストラクチャを持つ組織
- インスタンスレベルの保護を必要とする環境
- 単一データセンター内でのローカル高可用性
- すべてのデータベースを同時にフェイルオーバーする必要があるアプリケーション
- サーバーレベルのオブジェクトを保護する必要があるシナリオ
- Windows のみの環境 (FCI では Linux はサポートされていません)
メリット
- 完全なインスタンスレベルの保護
- データ損失ゼロを保証
- 自動フェイルオーバー機能
- ログインやジョブを同期する必要はありません
- データの単一コピーによりストレージコストが削減されます
- すべての復旧モデルをサポート
- フェイルオーバー後もアプリケーション接続文字列は変更されない
デメリット
- 高価な共有ストレージインフラストラクチャが必要
- 共有ストレージは単一障害点である
- 読み取りスケール機能なし（アクティブノードは 1 つだけ）
- 保管上の制約により地理的な分布が制限される
- 標準エディションは2ノードに制限されます
- Windowsのみ（Linuxはサポートされていません）
- AG と比較してフェイルオーバー時間が長い (通常は数分)
- 複雑なストレージ構成と管理
参考情報
- SQL Server フェールオーバー クラスター: DBA 向け完全ガイド
- Microsoft 公式ドキュメント: Always On フェールオーバー クラスター インスタンス (SQL Server)
7. SQL Server Replication
SQL Server レプリケーションは、複数のサーバー間でデータをコピーして配布するデータ配布テクノロジであり、単純な一方向配布から複雑なマルチマスター構成までさまざまなトポロジをサポートしますが、主に純粋な高可用性ソリューションではなくレポートに使用されます。
他社とのちがい
- 4つのレプリケーションタイプ: スナップショット、トランザクション、マージ、ピアツーピア
- きめ細かなデータ選択（特定のテーブル、列、行）
- 単一のパブリッシャーからの複数の購読者をサポート
- 双方向およびマルチマスタートポロジーが利用可能
- 柔軟なスケジュールと同期オプション
- マージレプリケーションの競合解決
- WHERE述語によるフィルタリング機能
実装手順
- ディストリビューター サーバーを構成する (パブリッシャーとは別または同じにすることができます)
- Publisherデータベースに出版物を作成する
- 要件に基づいてレプリケーションタイプを選択する
- 複製する記事（テーブル、ビュー、ストアド プロシージャ）を選択します
- 必要に応じてフィルタリングとデータ変換を構成する
- サブスクライバーデータベースを設定する
- サブスクリプションを作成する（プッシュまたはプル）
- スナップショットでサブスクリプションを初期化する
- レプリケーションエージェントとレイテンシを監視する
以下のためにベスト
- 複数のレポートサーバーにデータを配布する
- レポートワークロードを使用した読み取りスケールのシナリオ
- リモートサイトへの部分的なデータ配信
- 複数のソースからのデータ統合
- 時々接続されるシナリオ（マージレプリケーション）
- 災害復旧戦略における支援的役割
メリット
- 複製されたデータのきめ細かな制御
- 複数の加入者をサポート
- 柔軟なトポロジーオプション
- 特定のテーブルまたは列を複製できます
- フィルタリングによりネットワークトラフィックが削減される
- 異機種間レプリケーションをサポート（SQL Server オラクルへ）
- スタンダードエディションで動作します
デメリット
- 自動フェイルオーバー機能なし
- 複雑な構成と管理
- レプリケーション競合の可能性（マージおよびピアツーピア）
- データ同期の遅延
- スキーマの変更には慎重な調整が必要
- 主要なHAソリューションとして設計されていない
- トラブルシューティングは難しい
- ピアツーピアにはエンタープライズエディションが必要です
参考情報
8. ログシッピング
ログシッピングは、自動化されたトランザクションログのバックアップ、コピー、復元プロセスを通じて、ウォームスタンバイ型の災害復旧および高可用性ソリューションを提供し、同期されたセカンダリデータベースを維持するためのシンプルで費用対効果の高いアプローチを実現します。
他社とのちがい
- SQL エージェントによる自動バックアップ、コピー、および復元ジョブ
- 複数のセカンダリサーバーのサポート
- 設定可能なバックアップと復元の間隔
- スタンバイモードでは、セカンダリへの読み取り専用アクセスが可能
- エラー回復保護のための遅延ログ復元
- 集中監視用の監視サーバー
- トランザクションログ圧縮のサポート
実装手順
- プライマリデータベースが完全復旧モデルを使用していることを確認する
- プライマリデータベースの完全バックアップを作成する
- NORECOVERY でセカンダリ サーバーにバックアップを復元する
- プライマリ データベースでログ配布を構成する
- すべてのサーバーからアクセス可能な共有バックアップフォルダを指定する
- プライマリでバックアップジョブスケジュールを構成する
- セカンダリでコピーおよび復元ジョブを構成する
- オプションで監視サーバーを構成する
- フェイルオーバー手順をテストする
以下のためにベスト
- 費用対効果の高い災害復旧ソリューション
- Standard Editionライセンスを持つ組織
- 数分間のデータ損失を許容するシナリオ
- 手動フェイルオーバーに適した環境
- エラー保護のニーズのための遅延回復
- STANDBYモードを使用したワークロードのレポート
- 複雑なインフラストラクチャを必要としないシンプルな DR 要件
メリット
- シンプルな構成と操作
- 低価格（スタンダードエディション対応）
- 複数のセカンダリサーバーをサポート
- 設定可能な遅延により論理エラーを防止
- スタンバイモードでの読み取り専用レポート
- 高いネットワーク遅延を許容する
- プライマリサーバーへの影響は最小限
- 確立された実績のある技術
デメリット
- 自動フェイルオーバー機能なし
- データベースごとに個別に設定する必要がある
- 同期遅延（数分～数時間）
- バックアップ間隔に基づく潜在的なデータ損失
- 手動フェイルオーバーによりRTOが増加する
- 必要 SQL Server すべてのサーバーでエージェントが実行中
- ログの復元中にセカンダリ データベースにアクセスできない
- アプリケーションはフェイルオーバー後に接続文字列の変更を必要とする
参考情報
9. データベースミラーリング
データベースミラーリングは、廃止されたデータベースレベルの高可用性ソリューションであり、それ以降は機能強化が行われていません。 SQL Server 2012 ではサポートされていませんが、現在のバージョンでは引き続き利用可能です。Microsoft は、すべての新規展開において Always On 可用性グループへの移行を強くお勧めします。
他社とのちがい
- プリンシパルサーバーとミラーサーバーのアーキテクチャ
- 自動フェイルオーバーのためのオプションの監視サーバー
- 2つの動作モード：高安全性と高性能
- 同期および非同期操作のサポート
- 自動ページ修復機能
- データベースレベルの保護
- データ転送の暗号化サポート
実装手順
- データベースが完全復旧モデルを使用していることを確認する
- 完全バックアップを作成し、NORECOVERY でミラー サーバーに復元します。
- プリンシパルとミラーにミラーリングエンドポイントを作成する
- 認証用の証明書を構成する
- サーバー間のミラーリングセッションを確立する
- オプションで自動フェイルオーバー用の監視サーバーを構成する
- 動作モードの設定（高安全性または高パフォーマンス）
- フェイルオーバー手順をテストする
以下のためにベスト
- すでにデータベースミラーリングを使用しているレガシーシステム
- 移行が可能になるまで既存の構成を維持する
- 他のシナリオは推奨されません（機能は非推奨です）
メリット
- 監視機能を備えた高安全性モードでの高速自動フェイルオーバー
- 高安全性モードではデータ損失ゼロ
- パートナーからの自動ページ修復
- 単一データベースの可用性グループよりもシンプル
- 送信時の暗号化をサポート
- ダウンタイムを最小限に抑えたローリングアップグレード
デメリット
- 廃止予定日 SQL Server 2012年（削除される可能性があります）
- データベースごとの構成とフェイルオーバー
- 読み取り可能なミラーなし（読み取りスケール機能なし）
- 各データベースは独立してフェイルオーバーします
- フェイルオーバー後には接続文字列の更新が必要
- 2台のサーバー（プリンシパルとミラー）に制限
- 機能強化や新機能はありません
- MicrosoftはAlways On AGへの移行を推奨
参考情報
10. マネージドインスタンスリンク
マネージドインスタンスリンクは、 SQL Server 分散型可用性グループ テクノロジを使用した Azure SQL Managed Instance により、災害復旧、移行、クラウド統合のシナリオでほぼリアルタイムのデータ レプリケーションが可能になります。
他社とのちがい
- 分散型AGテクノロジーを使用したほぼリアルタイムのレプリケーション
- 一方向レプリケーション（SQL Server 2016年から2019年までAzureへ
- フェイルバック機能付き双方向レプリケーション（SQL Server 2022 +）
- リンクごとに 1 つのデータベース (複数のリンクをサポート)
- Azure SQL Managed Instance 上の読み取り可能なレプリカ
- ライセンス不要のパッシブDRレプリカオプション
- ダウンタイムを最小限に抑えたオンライン移行
実装手順
- 準備 SQL Server 環境（VPN または Azure への ExpressRoute）
- Azure SQL Managed Instance を構成する
- Always On AG機能を有効にする SQL Server
- データベースミラーリングエンドポイントを作成する
- 証明書の交換 SQL Server およびMI
- SSMS またはスクリプトを使用してマネージド インスタンス リンクを作成する
- レプリケーションと同期を検証する
- 読み取りスケールで使用する場合は読み取り専用ルーティングを構成する
- フェイルオーバー手順をテストする
以下のためにベスト
- クラウドベースのセカンダリを使用したハイブリッド災害復旧
- Azure SQL Managed Instance へのオンライン移行
- 分析とレポートを Azure にオフロードする
- ハイブリッドクラウド戦略を採用している組織
- Azure サービス統合が必要なシナリオ
- ライセンス不要のパッシブDRによるコスト最適化
メリット
- 最高のパフォーマンスと最小限のダウンタイムでAzureへの移行を実現
- ビジネスクリティカル層への真のオンライン移行
- 双方向フェイルオーバー SQL Server 2022件以上
- ライセンス不要のパッシブDRレプリカによりコストを削減
- 完全な移行なしでAzureサービスとの統合
- Azure レプリカを使用した読み取りスケール機能
- Azure側での自動バックアップ
- Azure リージョンへの地理的分散
デメリット
- リンクごとに1つのデータベースの制限
- MIのフェイルオーバーグループでは使用できません
- システムデータベースは複製されません
- インスタンスレベルのオブジェクトは手動で同期する必要がある
- SQL Server 2016-2019 片道のみ（フェイルバックなし）
- Azure マネージド インスタンスのコスト
- ネットワーク接続要件 (VPN/ExpressRoute)
- 機能の制限（ファイル テーブル、ファイル ストリームはサポートされていません）
参考情報
11. 高可用性ソリューションの比較
11.1 機能比較表
| 機能 | 常時オンAG | AGを封じ込めた | 分散型AG | FCI | Replication | ログ出荷 | ミラーリング | MIリンク |
|---|---|---|---|---|---|---|---|---|
| エディション | Ent/Std | Ent/Std | 耳鼻咽喉科 | Ent/Std | Ent/Std | Ent/Std | Ent/Std | Ent/Std |
| 保護レベル | データベース | データベース+インスタンス | データベース | インスタンス | データベース/オブジェクト | データベース | データベース | データベース |
| データ同期 | 同期/非同期 | 同期/非同期 | 同期/非同期 | 共有 | 非同期 | 非同期 | 同期/非同期 | 非同期 |
| 自動フェイルオーバー | はい | はい | はい | はい | いいえ | いいえ | はい | いいえ |
| 読み取りスケール | はい | はい | はい | いいえ | はい | 限定的 | いいえ | はい |
| RTO | SECONDS | SECONDS | SECONDS | MINUTES | マニュアル | マニュアル | SECONDS | マニュアル |
| RPO | ゼロ/最小 | ゼロ/最小 | ゼロ/最小 | Zero | 最小限の | MINUTES | ゼロ/最小 | 最小限の |
| サポート状況 | 有効 | 有効 | 有効 | 有効 | 有効 | 有効 | 非推奨の | 有効 |
11.2 HAソリューションの選択
ソリューションを選択するときは、次の要素を考慮してください。
- 予算上の考慮事項は、ソリューションの選択に大きな影響を与えます。エンタープライズエディションの要件はライセンス費用に影響し、インフラストラクチャのニーズは、FCI向けの高価な共有ストレージから可用性グループ向けの汎用サーバーまで多岐にわたります。
- 複雑さは大きく異なります。ログ配布では最も簡単な実装が提供されますが、分散可用性グループでは広範な専門知識が必要になります。
- RTO要件はテクノロジーの選択を左右します。数秒のダウンタイムには、自動フェイルオーバー機能を備えたAlways On可用性グループまたはFCIが必要です。数分の許容範囲であれば、ログ配布などの手動フェイルオーバーソリューションが利用可能です。
- RPO 要件も同様に重要です。データ損失ゼロは同期ソリューションを必須とし、分単位の許容範囲はログ シッピングを可能にします。
- インフラストラクチャの制約、読み取りスケールのニーズ、地理的な分散要件、クラウド ハイブリッド シナリオはすべて、最適なソリューションの選択に影響を与えます。
12. ベストプラクティス SQL Server 高可用性
12.1 計画と設計
各データベースについて、RTO（目標復旧時間）とRPO（目標復旧時点）を綿密に分析し、ビジネス要件を評価します。最も高度なオプションに安易に頼るのではなく、要件に合った適切なソリューションを選択します。階層型アプローチを用いて、ローカルの高可用性と地理的な災害復旧の両方を計画します。ネットワーク図、フェイルオーバー手順、復旧ランブックなど、アーキテクチャを包括的に文書化します。
12.2 実装ガイドライン
フェイルオーバー手順を定期的にテストし、スケジュールされたテストと障害のシミュレーションを通じて検証する SQL Server 高可用性ソリューションとチームの準備。 SQL Serverの組み込みツール SQL Server プロファイラー およびDMV。同期の遅延、フェイルオーバーイベント、およびヘルスの低下に関する包括的なアラートを設定します。 SQL Server バックアップ戦略 HA実装後も、バックアップは論理的な破損や偶発的な削除に対する最後の防御線であり続けるため、システムは常に最新の状態に維持する必要があります。累積的なアップデート、セキュリティパッチ、ファームウェアアップデートを適用し、システムを最新の状態に保ちましょう。実際のリストアやアプリケーションテストを通じて定期的にリカバリ手順を検証し、以下のようなシナリオへの対処方法を把握しておく必要があります。 データベースがリカバリモードで停止している.
12.3 監視と保守
などのツールを活用する SQL Server 活動モニター, SQL Server パフォーマンスモニタ、およびダイナミック管理ビューを広範囲に使用してヘルスモニタリングを実行し、 DBCCチェックDB データベースの整合性を定期的に検証してください。Always Onダッシュボードを活用して、可用性グループの健全性を視覚的に評価してください。特に非同期レプリカとログ配布については、同期の遅延を注意深く監視してください。 SQL Server 延長イベント パターンの原因を分析します。通常運用時のパフォーマンスベースラインを確立し、潜在的な問題を示す逸脱を監視します。定期的にキャパシティプランニングのレビューを実施し、インフラストラクチャが増大するワークロードをサポートできるようにします。
13。 よくある質問
Q: 高可用性と災害復旧の違いは何ですか？ SQL Server?
A: 高可用性は、データセンター内のローカル障害によるダウンタイムを最小限に抑えます。通常は自動フェイルオーバーと数秒または数分のRTO（目標復旧時間）によって実現されます。災害復旧は、地域的な大災害からデータセンターを保護します。通常は手動フェイルオーバーとより長いRTO（目標復旧時間）によって実現されますが、施設全体に影響を及ぼす事象もカバーします。
Q: 高可用性 (HA) ソリューションと読み取りスケール ソリューションの違いは何ですか?
A：高可用性ソリューションは、稼働時間と自動フェイルオーバー機能に重点を置き、障害発生時にもデータベースへのアクセスを維持します。一方、リードスケールソリューションは、読み取り専用ワークロードを複数のデータベースレプリカに分散することでクエリパフォーマンスを向上させ、スループットと応答時間を重視します。これらは異なる目的を持ちますが、Always On可用性グループのような同じテクノロジーを使用することで、両方のメリットを同時に享受できます。読み取り可能なセカンダリレプリカは、リードスケール機能を提供すると同時に、高可用性のためのフェイルオーバーターゲットとしても機能します。
Q：どちらですか SQL Server 私のニーズに最適な高可用性ソリューションは何ですか?
A：最適なソリューションは、RTOとRPOの目標値、予算、エディションの可用性、インフラストラクチャ、専門知識によって異なります。Always On可用性グループはほとんどのエンタープライズシナリオに適していますが、ログシッピングはコスト重視の環境に適しています。比較表に基づいて要件を評価してください。
Q: Always On 可用性グループには Enterprise Edition が必要ですか?
A: Standard Editionは、Basic Availability Groupsをサポートしますが、グループごとにデータベース1つ、セカンダリレプリカ1つ、読み取り可能なセカンダリレプリカなしという制限があります。複数のデータベース、8つのセカンダリ、読み取り可能なレプリカを含むフル機能を使用するには、Enterprise Editionが必要です。
Q: ログシッピングは SQL Server スタンダードエディション？
A: はい、ログシッピングはスタンダードエディションで完全にサポートされているため、エンタープライズエディションのライセンスを持たない組織にとって、費用対効果の高い魅力的な災害復旧ソリューションとなります。
Q: Always On 可用性グループとデータベース ミラーリングの違いは何ですか?
A: データベースミラーリングは非推奨となり、読み取り可能なセカンダリアクセスなしで個々のデータベースレベルで動作します。Always On 可用性グループは、データベースのグループ、最大8つのセカンダリ、読み取り可能なレプリカ、および拡張監視をサポートします。Microsoft は Always On への移行を推奨しています。
Q: フェールオーバー クラスター インスタンスと可用性グループはどのように選択すればよいですか?
A: 共有ストレージインフラストラクチャを使用したインスタンスレベルの保護には、FCI をお選びください。データベースレベルの保護、読み取りスケール機能、共有ストレージを使用しない地理的分散には、可用性グループをお選びください。包括的な保護を実現するために、多くの組織ではこれらを組み合わせています。
Q: 複数の SQL Server 高可用性ソリューションですか?
A: はい、ソリューションを組み合わせることは一般的です。FCIは可用性グループのレプリカとして機能し、インスタンスレベルのローカルHAとデータベースレベルの地理的DRを提供します。ログ配布は可用性グループを補完し、リモート保護を強化することができます。組み合わせた構成を十分にテストしてください。
Q: 同期レプリケーションと非同期レプリケーションの違いは何ですか?
A: 同期レプリケーションは、セカンダリAcknowledgementを待ってコミットするため、データ損失は発生しませんが、遅延が発生する可能性があります。非同期レプリケーションは待機なしで処理を進めるため、パフォーマンスは最適化されますが、フェイルオーバー時にデータ損失が発生する可能性があります。
Q: バックアップは必要ですか？ SQL Server 高可用性は構成されていますか?
A: もちろんです。高可用性はハードウェア障害からの保護には役立ちますが、論理的な破損、誤った削除、あるいはすべてのコピーに複製される悪意のある行為からは保護できません。ポイントインタイムリカバリとコンプライアンス要件を満たすには、バックアップが不可欠です。
Q: バックアップは必要ですか？ SQL Server 高可用性は構成されていますか?
A: もちろんです。高可用性はハードウェア障害から保護しますが、データベースの破損、誤った削除、悪意のある行為から保護することはできません。ポイントインタイムリカバリとコンプライアンス要件を満たすには、バックアップが不可欠です。データベースファイルが破損し、バックアップが利用できない、または破損している場合は、専門的なバックアップが役立ちます。 SQLデータベース修復ソフトウェア 破損した MDF、NDF、およびバックアップ ファイルからデータを回復するのに役立ちます。
Q: Contained Availability Group とは何ですか? また、通常の Availability Group とどう違うのですか?
A: 包含型可用性グループ（Contained Availability Groups）は、 SQL Server 2022では、ログイン、ジョブ、メタデータなどのインスタンスレベルのオブジェクトが自動的に同期されます。通常の可用性グループはデータベースオブジェクトのみを同期するため、インスタンスオブジェクトのレプリケーションは手動で行う必要があります。
Q: データを複製できますか？ SQL Server Azure SQL Managed Instance に移行しますか?
A: はい、マネージドインスタンスリンクは、 SQL Server およびAzure。 SQL Server 2016-2019は一方向のレプリケーションをサポートしていますが、 SQL Server 2022+ では、災害復旧、移行、ハイブリッド シナリオ向けに、フェイルバックを備えた双方向レプリケーションが可能になります。
Q: どうなるのでしょうか SQL Server フェイルオーバー中のエージェントジョブ?
A: 従来の可用性グループでは、セカンダリレプリカにジョブを手動で作成する必要があります。包含型可用性グループ（SQL Server 2022年以降はジョブが自動的に同期されます。フェールオーバークラスターインスタンスには、インスタンスレベルの保護の一部としてジョブが含まれます。
14. 結論
SQL Server 部門データベースからミッションクリティカルなエンタープライズシステムまで、多様な要件に対応する包括的な高可用性ソリューションを提供します。各ソリューションはそれぞれ異なる機能とトレードオフを備えており、データベース管理者は情報に基づいた意思決定を行うために、これらを理解する必要があります。
Always On 可用性グループは、最新のデプロイメントにおける主力テクノロジーであり、Contained Availability Groups は管理を簡素化し、Distributed Availability Groups は高度なクロスプラットフォームシナリオを実現します。フェールオーバークラスタインスタンスは引き続きインスタンスレベルの保護ニーズに対応し、ログシッピングはコスト重視のシナリオにおいて依然として有効です。Managed Instance Link は、オンプレミス環境とクラウド環境を連携させるハイブリッド環境の可能性を広げます。 SQL Server Azure を使用。
特定のビジネスニーズに適したソリューションは、成功の重要な要素です。万能なアプローチは存在しません。組織は、RTOとRPOの要件、予算の制約、インフラストラクチャの能力、そして管理の専門知識を慎重に評価する必要があります。多くの場合、最適なアーキテクチャは、包括的な保護のために複数のソリューションを組み合わせたものです。HA戦略が、より広範なクラウド導入計画とどのように整合しているかを検討し、詳細な実装ガイダンスについては専用の記事を参照し、HA戦略を確実に実行してください。 SQL Server インフラストラクチャは、ビジネスに必要な信頼性を提供します。
著者について
袁勝 10年以上の経験を持つ上級データベース管理者（DBA）です。 SQL Server 環境およびエンタープライズデータベース管理に精通しており、金融サービス、医療、製造業など、様々な組織において数百件のデータベース復旧シナリオを解決してきました。
ユアンの専門は SQL Server データベースの復旧、高可用性ソリューション、パフォーマンス最適化など、幅広い分野に精通しています。彼は、マルチテラバイト規模のデータベースの管理、Always On可用性グループの実装、ミッションクリティカルなビジネスシステム向けの自動バックアップおよび復旧戦略の開発など、豊富な実務経験を有しています。
Yuanは、技術的な専門知識と実践的なアプローチを通じて、データベース管理者やITプロフェッショナルが複雑な問題を解決するのに役立つ包括的なガイドの作成に重点を置いています。 SQL Server 効率的に課題に取り組みます。常に最新の SQL Server リリースと Microsoft の進化するデータベース テクノロジを活用し、定期的にリカバリ シナリオをテストして、推奨事項が実際のベスト プラクティスを反映していることを確認します。
について質問があります SQL Server 回復または追加のデータベーストラブルシューティングガイダンスが必要ですか？Yuanは歓迎します フィードバックと提案 これらの技術リソースを改善するためです。