MS_SQLServerClustering - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki
- 戻る（冗長化アーキテクチャ、SQL Server）（分散・冗長化）
- SQL Server のクラスタリング
- SQL Server のレプリケーション / SQL Server リンクサーバ機能 / Elastic Scale, Elastic Database Pool
SQL Server のクラスタリング機構。
補足（3つの方式の整理）: 「クラスタリング」と一括りにされるが、
何を冗長化するかが方式ごとに異なる。ここを取り違えると設計を誤る。
方式 冗長化するもの ストレージ データの複製 フェールオーバー クラスタ インスタンス（FCI） SQL Server インスタンス 共有（SAN / 記憶域スペース ダイレクト） しない（1 つのデータを付け替える） 可用性グループ（AlwaysOn AG） データベース（複数まとめて） 各ノードが個別に持つ ログ ブロックを転送して適用 データベース ミラーリング データベース（1 つずつ） 各ノードが個別に持つ ログ レコードを転送して適用 FCI は共有ストレージ自体が単一障害点になるため、
ストレージ側の冗長化が別途必要になる。
AG はストレージを共有しないため、
ストレージ障害・データ破損に対しても冗長性があるのが大きな違い。なお、FCI と AG は組み合わせて使える
（FCI を AG のレプリカにする構成）。
補足（最新化）:
- データベース ミラーリングは非推奨（SQL Server 2012 で非推奨化）。
新規構築では可用性グループを使用する。- Standard Edition でも「基本可用性グループ」が利用可能
（SQL Server 2016 以降）。ただし、
- 1 つの AG につきデータベースは 1 つのみ
- レプリカは 2 つ（プライマリ + セカンダリ）のみ
- 読み取り可能セカンダリは不可（参照系のオフロードはできない）
- 読み取り可能セカンダリや複数セカンダリ、
読み取り専用ルーティングは Enterprise Edition の機能。- SQL Server 2017 以降は Linux でも可用性グループが構成でき、
Pacemaker と組み合わせる。- クラウドでは、Azure SQL Database のように
プラットフォーム側が可用性を提供する PaaS を選ぶことで、
これらの構築・運用自体を不要にできる
（プラットフォーム・アーキテクチャ参照）。
補足（可用性グループを組む前に決めること）:
論点 内容 同期モード 同期コミット（データ損失なし、コミットが遅くなる）か非同期コミット（遅延なし、データ損失の可能性）か フェールオーバー 自動（同期コミットのみ）か手動か クォーラム WSFC の投票構成。偶数ノードならファイル共有監視やクラウド監視を追加 リスナー クライアントの接続先を仮想名に集約する（アプリ側は接続文字列に MultiSubnetFailover=Trueを指定）同期コミットはセカンダリのログ書き込み完了を待つため、
レプリカ間のネットワーク遅延がそのまま更新性能に響く
（SQL Server のファイルの配置のWRITELOGの話と同根）。
-
Always On 可用性グループ | Microsoft Learn
https://learn.microsoft.com/ja-jp/sql/database-engine/availability-groups/windows/always-on-availability-groups-sql-server -
Always On フェールオーバー クラスター インスタンス | Microsoft Learn
https://learn.microsoft.com/ja-jp/sql/sql-server/failover-clusters/windows/always-on-failover-cluster-instances-sql-server
Tags: 移行, データアクセス, SQL Server