web-dev-qa-db-ja.com

SQL Server Always-On可用性グループのパッチ

私のSQLサーバーファームは、OSレベルとSQLサーバーレベルのパッチで無視されています（これらは重要なシステムであるため、停止することは困難です）。

オプションは、AOAGクラスターのセカンダリノードに最新のパッチを適用する1か月後にパッチを適用し、翌月には、業務が時間外にフェールオーバーをスケジュールすることに同意します。その後、新しいセカンダリ（古いプライマリ）にパッチを適用できます。これは、ノードが1か月間同じパッチレベルにならないことを意味します。これは「いいえ」ですか？

sql-serveravailability-groupspatching
3
Daniel Nash

これはサポートされていない構成です ドキュメント

同じAG内でのSQL Serverインスタンスのバージョンの混在は、ローリングアップグレードの外部ではサポートされておらず、アップグレードが迅速に行われるため、その状態で長期間存在しないようにする必要があります。 SQL Server 2016以降をアップグレードするためのもう1つのオプションは、分散型可用性グループを使用することです。

これは実際にはどういう意味ですか？それは完全に良いかもしれません-互換性の問題はゼロであるかもしれず、それは水泳に行くかもしれません。それもないかもしれません。 インスタンス間でバージョンを混在させることを選択した場合、Microsoftは実行中の構成をテストしていません。個人的には、その時点では、リスクは利点をはるかに上回っています。

また、私が投稿したリンクで定義されているローリングアップグレードプロセスを使用すると、ダウンタイムが最小限に抑えられることにも注意してください。それでも十分でない場合は、パッチを適用するのではなく、2つの新しいサーバーと新しいAGを構築し、それらに移行してみませんか？作業量は多くなりますが、ダウンタイムをさらに最小限に抑えることができるはずです。

6
George.Palacios

ダウンタイムの日にセカンダリサーバーにパッチを適用しますが、ダウンタイムの前に完了します。

スケジュールどおりにフェイルオーバーします。

フェイルオーバーが完了して安定したら、プライマリサーバーにパッチを適用します。

両方のサーバーは同じように構築する必要があるため、どちらがプライマリかは問題ではありません。ただし、問題がなければ、別のダウンタイムウィンドウでフェイルバックしてください。

あるいは、AGにリスナーを追加し、アプリケーションがリスナーを指すようにする（すべてのアプリケーションがこれを実行できるわけではありません）。サーバーに毎月次々にパッチを適用でき、唯一のダウンタイムはアプリケーションの初回です。リスナーを再度ポイントします。

1
James Jenkins

オプションは、AOAGクラスターのセカンダリノードに最新のパッチを適用するパッチを適用することです。その後、翌月にビジネスが時間外にフェールオーバーをスケジュールすることに同意します。その後、新しいセカンダリ（古いプライマリ）にパッチを適用できます。

パッチの更新を計画するときは、AG内のすべてのレプリカが実際にソリューションを維持するように計画する必要があります常にオン、これはサーバーの可用性グループの主要な利点の1つですメンテナンスはダウンタイムなしで行うことができます。

たとえば、常にオンのビジネス継続性という用語を破るアプローチでは、セカンダリレプリカを更新するときに、プライマリレプリカを更新せずに残します。なんらかの理由でセカンダリにフェイルオーバーしたかったので、その瞬間以降、元のプライマリに再びフェイルオーバーしない可能性があります。これは、データベースが常に新しいバージョンにアップグレードされてもダウングレードされない理由の1つです。 DBバージョンをダウングレードするには、いくつかの回避策（スクリプトアウト）が必要です。この場合、プライマリレプリカにフェールバックできない場合常にオンではありません、したがって、すべてのレプリカのパッチ更新を 推奨される順序.. とともにスケジュールすることをお勧めします。

ダウンタイムはありませんが、サーバーの過負荷が少ないときに、更新されたパッチを実行するのに適しています。続行する前に、検討することをお勧めします（まだ構成されていない場合） ノードおよびフェールシェアマジョリティクォーラム WSFCに偶数のノードがある場合に推奨されるため、ファイル共有監視特にパッチの更新中にセカンダリノードがオフラインである場合に、健全なクォーラムとクラスターリソースを健全に保つための投票を維持します（リスナー）。

次のクエリは、同期の正常性を確認するのに役立ちます（パッチの更新を行う前後に不可欠です）。一部の情報は可用性グループダッシュボードで利用できませんが、DMVを介して取得できます（次のように）：

select  db.name, 
        db.database_id, 
        ag.name as GroupName, 
        state_desc, 
        recovery_model_desc, 
        log_reuse_wait_desc,
        AGDB.truncation_lsn,
        Rep.replica_server_name,
        rep.endpoint_url,
        DBRepStats.is_primary_replica,
        DBRepStats.synchronization_health_desc,
        DBRepStats.database_state_desc,
        (redo_queue_size / 1024.0) as redo_queue_size_MB,
        last_redone_time,
        last_redone_lsn,
        DBRepStats.end_of_log_lsn,
        DBRepStats.last_sent_lsn,
        DBRepStats.last_sent_time,
        DBRepStats.last_received_lsn,
        DBRepStats.last_received_time,
        DBRepStats.last_hardened_lsn,
        DBRepStats.last_hardened_time
from sys.databases as db
    left outer join sys.availability_databases_cluster as AGDB on db.group_database_id = AGDB.group_database_id
    left outer join sys.dm_hadr_database_replica_states as DBRepStats on db.group_database_id = DBRepStats.group_database_id
    left outer join sys.availability_replicas as Rep on DBRepStats.group_id = Rep.group_id and DBRepStats.replica_id = Rep.replica_id 
    left outer join sys.availability_groups as AG on DBRepStats.group_id = AG.group_id
where db.database_id > 4
0
Shekar Kola