SQLServerでの常時接続の高可用性グループの構成
この記事では、常時オンをインストールして構成する方法についてのステップバイステップガイドを紹介します。 Windows Server2019で実行されているSQLServerの可用性グループ、フェールオーバーシナリオ、およびその他の関連トピックについて説明します。
常に可用性グループに MIcrosoftSQLServerで高可用性を提供します。 Always Onは、MSSQL2012リリースに登場しました。
SQL Serverの可用性グループは何に使用できますか？
- MSSQLの高可用性と自動フェイルオーバー;
- ノード間のSELECTクエリの負荷分散（セカンダリレプリカは読み取り可能である可能性があります）。
- セカンダリレプリカからのバックアップ;
- データの冗長性。各レプリカは、可用性グループデータベースのコピーを保持します。
Always Onは、WindowsServerフェールオーバークラスターに基づいています （WSFC）。 WSFCは、可用性グループノードを監視し、自動フェイルオーバーを提供します。 MS SQL Server 2017以降、AlwaysOnはWSFCなしで使用できます。 およびLinux ホストも。 Linuxベースのクラスターを構築する場合、WSFCの代わりにPacemakerを使用できます。
常時オンは標準で利用できます エディションですが、いくつかの制限があります：
- 2つのレプリカ（プライマリとセカンダリ）に制限されています。
- セカンダリレプリカを使用してデータを読み取ることはできません。
- セカンダリレプリカを使用してMSSQLをバックアップすることはできません。
- 可用性グループごとに1つのデータベースのみがサポートされます。
エンタープライズには制限はありません 版。
ここでMSSQLServerのライセンスの側面について読むことができます。用語を考えてみましょう。
- 常に可用性グループ レプリカとデータベースのセットです。
- レプリカ 可用性グループのSQLServerインスタンスです。レプリカはプライマリまたはセカンダリの場合があります。各レプリカには、1つ以上のデータベースが含まれる場合があります。
AlwaysOnはWSFCに基づいています。各可用性グループノードは、Windowsフェールオーバークラスターのメンバーである必要があります。各SQLServerインスタンスは、複数の可用性グループを持つことができます。各可用性グループには、最大8つのセカンダリレプリカを含めることができます。
プライマリレプリカに障害が発生した場合、クラスターは新しいプライマリレプリカに投票し、AlwaysOnはセカンダリレプリカの1つをプライマリレプリカにします。ユーザーはリスナーに接続するため （特別なクラスターIPアドレスと対応するDNS名）Always Onを使用すると、書き込みクエリを再度実行できるようになります。リスナーは、セカンダリレプリカ間でSELECTクエリのバランスを取る役割も果たします。
まず、AlwaysOnが使用するすべてのノードでフェールオーバークラスターを構成する必要があります。
これが私の設定です：
- WindowsServer2019を実行している2台の仮想マシン
- 2つのSQLServer2019Enterpriseインスタンス
- ノードのホスト名はtestnode1とtestnode2です。 SQLServerインスタンス名はnode1とnode2です。
フェイルオーバークラスタリングを追加します サーバーマネージャーを使用してロールするか、PowerShellを介してインストールします：
Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools
インストールは自動的に行われるため、まだ何も構成する必要はありません。 フェールオーバークラスターマネージャーを実行します スナップイン（FailoverClusters.SnapInHelper.msc ）そして新しいクラスターを作成します。
クラスターに参加するホストの名前を追加します。
次に、ウィザードはいくつかのテストを受けることを提案します。これを行うには、最初のアイテムを選択します。
クラスタ名を指定し、ネットワークとクラスタIPアドレスを選択します。クラスタ名はDNSに自動的に表示されます。 DNSレコードを手動で作成する必要はありません。私の場合、クラスター名は ClusterAGです。 。
オプションのチェックを外します対象となるすべてのストレージをクラスターに追加します 後でディスクを追加できるからです。
クラスタにはノードが2つしかないため、クラスタクォーラムを設定する必要があります 。クラスタークォーラムは決定票です。たとえば、クラスターノードの1つが使用できなくなった場合、クラスターは、実際にオンラインであり、相互に認識できるノードを検出する必要があります。クラスタクォーラムは、クラスタの整合性を提供します（[クラスタ]->[その他のアクション]->[クラスタクォーラム設定の構成]）。
クォーラム監視オプションを選択します。
次に、監視タイプを選択します：ファイル共有監視。
共有フォルダーへのUNCパスを指定します。自分でディレクトリを作成します。フェールオーバークラスターの外部のサーバーに存在する必要があります。
クラスタを構成すると、次のエラーが表示される場合があります。
There was an error configuring the file share witness. Unable to save property changes for File Share Witness. The system cannot find the file specified.
クラスタが実行されているユーザーアカウントには、共有フォルダにアクセスするためのNTFSアクセス許可がない可能性があります。デフォルトでは、クラスターはローカルユーザーアカウントで実行されています。フォルダーに対する特権をすべてのクラスターコンピューターに付与するか、クラスターサービスのアカウントを変更して、関連する特権を付与することができます。
基本的なWindowsフェールオーバークラスターの構成は終了しました。
MSSQLServerでのAlwaysOn可用性グループの構成
通常のSQLServerインスタンスのインストール後、AlwaysOn可用性グループを有効にして構成できます。 SQLServer構成マネージャーのインスタンスプロパティでそれらを有効にします 。スクリーンショットでわかるように、SQLServerはWSFCクラスターに属していることをすでに検出しています。 常にオンの可用性グループを有効にするをオンにします MSSQLインスタンスサービスを再起動します。 2番目のインスタンスについても同じようにします。
SQL Server Management Studioを実行し、ホストに接続して、[常に高可用性を利用する]をクリックします。 新しい可用性グループウィザードを実行します。
SQLServer2017およびSQLServer2019用のSQLServerManagement Studio 18.xでは、T-SQLでのみ使用可能なAlways On設定がいくつか表示されたため、最新のSSMSバージョンを使用することをお勧めします。
Always On可用性グループの名前を指定し、データベースレベルのヘルス検出を選択します 。このオプションを使用すると、AlwaysOnはデータベースが正常でないことを検出できます。
SQL Serverデータベースを選択して、AlwaysOn可用性グループに追加します。
レプリカの追加をクリックします 2番目のSQLサーバーに接続します。したがって、最大8台のサーバーを追加できます。
- 初期の役割 グループが作成されるまでのレプリカの役割です。プライマリまたはセカンダリのいずれかになります。
- 自動フェイルオーバー –データベースが使用できなくなった場合、AlwaysOnはプライマリロールを別のレプリカに移動します。このアイテムを確認してください;
- 可用性モード SynchronousCommitまたはAsynchronousCommitを選択できます。同期モードを選択した場合、プライマリレプリカに着信するトランザクションは、同期モードで他のすべてのセカンダリレプリカに送信されます。プライマリレプリカは、他のレプリカがディスクに書き込んだ後でのみトランザクションを終了します。したがって、プライマリレプリカに障害が発生した場合でも、データの損失はなくなります。非同期モードでは、プライマリレプリカは、他のレプリカの応答を待たずに、変更をすぐに書き込みます。
- 読み取り可能なセカンダリ セカンダリレプリカに対してSELECTクエリを実行できるようにするパラメータです。値がyesの場合、
ApplicationIntent=readonlyなしで接続している場合でも、クライアントは読み取り専用アクセスを取得できます。 。 - コミットするには同期されたセカンダリが必要です トランザクションを完了するために同期されたセカンダリレプリカの数です。レプリカの数に応じて設定します。1に設定します。
エンドポイントでは何も編集しないでください タブ。
バックアップ設定 タブで、バックアップの作成元を選択できます。ここではデフォルト設定のままにします：セカンダリを優先 。
可用性グループリスナーの名前、ポート、およびIPアドレスを指定します。
読み取り専用ルーティングをそのままにします 設定は変更されていません。
レプリカ同期タイプを選択します。最初のアイテムを残します（自動シード ）チェック済み。
次に、設定を検証する必要があります。エラーがない場合は、[完了]をクリックして変更を適用します。
私の場合、すべてのテストは成功しましたが、インストール後の結果ステップで、ウィザードに可用性グループリスナーの作成エラーが表示されました。エラーEVENTID1194がクラスターイベントログに表示されました：
Cluster network name resource failed to create its associated computer object in the domain.
これは、クラスターにリスナーを作成するための十分な権限がないことを意味します。ドキュメントには、クラスターのオブジェクトにコンピュータータイプのオブジェクトを作成する特権を付与するだけで十分であると記載されています。 ADで特権の委任を使用する方が簡単です（または簡単ですが、安全でないバリアントは、CLUSTERAG $オブジェクトをDomainAdminsグループに一時的に追加することです）。
可用性グループでAlways-Onおよび低SQLパフォーマンスの問題を診断するときは、標準のSQL Server診断ツールを使用することに加えて、Windowsクラスターログを徹底的に調査する必要があります。リスナーではなく可用性グループを作成したので、手動で追加しました。可用性グループのコンテキストメニューを開き、リスナーの追加をクリックします 。
リスナーのIPアドレス、ポート、およびDNS名を指定します。
リスナーが可用性グループリスナーに表示されていることを確認します AlwaysOnグループのセクション。
これで、AlwaysOn可用性グループの基本構成が完了しました。
SQL Server常時オン：操作性のチェックとフェイルオーバー
可用性グループダッシュボード（ダッシュボードの表示）を見てみましょう。
グループは作成され、機能しています。
node2を手動でプライマリインスタンスにしてみましょう。可用性グループを右クリックして、フェイルオーバーを選択します 。
フェイルオーバー準備の値に注意してください 。 データの損失なし データが失われないことを意味します。
node2に接続します。
[完了]をクリックします。
node2が可用性グループのプライマリレプリカ（プライマリインスタンス）になっていることを確認してください。
リスナーが正しく機能していることを確認してください。 SSMSでリスナーのDNS名とポートをコンマで区切って指定します：ag1-listener-1,1445
単純な挿入を実行し、SQLクエリを選択してデータベースに更新します。
次に、プライマリレプリカの自動フェイルオーバーを確認します。 TESTNODE2でsqlservr.exeプロセスを強制終了します。
残りのノードで可用性グループの状態を確認します：TESTNODE1\NODE1。
testnode2 \ node2が使用できなくなったため、クラスターはtestnode1\node1のステータスを自動的にプライマリに変更しました。
クライアントが接続に使用するため、リスナーの状態を確認します。
私の場合、リスナーに正常に接続しましたが、データベースにアクセスしようとすると、次のエラーが発生しました：
Unable to access database 'TestDatabase' because it lacks a quorum of nodes for high availability. Try the operation again later.
コミットするために同期されたセカンダリが必要が原因でエラーが発生しました オプション。構成時に値を1に設定したため、プライマリレプリカが1つしか残っていないため、AlwaysOnではデータベースへの接続が許可されません。
値を0に設定します クエリをもう一度実行してみてください。
Testnode1はプライマリインスタンスのステータスを維持し、testnode2はセカンダリインスタンスのステータスになりました。コンピューターの電源を入れた後、testnode2の電源を切ったときにtestnode1で変更したデータは、正常に同期されました。
そのため、すべてが正しく機能し、重大な障害が発生した場合にデータを読み取り/書き込みできるようにしています。
AlwaysOn可用性グループを簡単に構成できます。 SQL Serverベースのフェイルオーバーソリューションを構築する場合は、可用性グループがそれを適切に管理します。
-
高可用性-MSSQLServerの可用性
高可用性（HA）は、意図的か予期しないかにかかわらず、あらゆる条件でアプリケーション/データベースに24時間年中無休でアクセスできるようにするソリューション/プロセス/テクノロジーです。 基本的に、MSSQLServerでデータベースの可用性を設定するための5つのオプションがあります。 レプリケーション ログ配布 ミラーリング クラスタリング AlwaysON可用性グループ レプリケーション 元のデータは、オブジェクトレベルのテクノロジーを使用して、レプリケーションタスク（エージェント/ジョブ）を介して宛先にコピーされます。知っておくべき用語： パブリッシャー（パブリッシャー）がソースサー
-
謎解きされた高可用性アーキテクチャ
高可用性アーキテクチャとは何ですか？ 高可用性アーキテクチャとは、ピーク時の負荷に関係なく、連携して最適なパフォーマンスを維持するさまざまなコンポーネント、モジュール、またはサービスが存在する場合です。 最も純粋な意味で、このシステムは、企業が一定期間にわたって失敗することなく継続的に作業することを可能にします。多くの企業は、1分でもダウンタイムを許容できません。データが多くのビジネスの生命線であることを考えると、ほんの短い期間のダウンタイムでさえ、信じられないほどコストがかかる可能性があります。 特定の実際のシナリオでは、高可用性のために構築されたデータベースに依存する場合があり