私のSQLサーバーファームは、OSレベルとSQLサーバーレベルのパッチで無視されています(これらは重要なシステムであるため、停止することは困難です)。
オプションは、AOAGクラスターのセカンダリノードに最新のパッチを適用する1か月後にパッチを適用し、翌月には、業務が時間外にフェールオーバーをスケジュールすることに同意します。その後、新しいセカンダリ(古いプライマリ)にパッチを適用できます。これは、ノードが1か月間同じパッチレベルにならないことを意味します。これは「いいえ」ですか?
これはサポートされていない構成です ドキュメント
同じAG内でのSQL Serverインスタンスのバージョンの混在は、ローリングアップグレードの外部ではサポートされておらず、アップグレードが迅速に行われるため、その状態で長期間存在しないようにする必要があります。 SQL Server 2016以降をアップグレードするためのもう1つのオプションは、分散型可用性グループを使用することです。
これは実際にはどういう意味ですか?それは完全に良いかもしれません-互換性の問題はゼロであるかもしれず、それは水泳に行くかもしれません。それもないかもしれません。 インスタンス間でバージョンを混在させることを選択した場合、Microsoftは実行中の構成をテストしていません。個人的には、その時点では、リスクは利点をはるかに上回っています。
また、私が投稿したリンクで定義されているローリングアップグレードプロセスを使用すると、ダウンタイムが最小限に抑えられることにも注意してください。それでも十分でない場合は、パッチを適用するのではなく、2つの新しいサーバーと新しいAGを構築し、それらに移行してみませんか?作業量は多くなりますが、ダウンタイムをさらに最小限に抑えることができるはずです。
ダウンタイムの日にセカンダリサーバーにパッチを適用しますが、ダウンタイムの前に完了します。
スケジュールどおりにフェイルオーバーします。
フェイルオーバーが完了して安定したら、プライマリサーバーにパッチを適用します。
両方のサーバーは同じように構築する必要があるため、どちらがプライマリかは問題ではありません。ただし、問題がなければ、別のダウンタイムウィンドウでフェイルバックしてください。
あるいは、AGにリスナーを追加し、アプリケーションがリスナーを指すようにする(すべてのアプリケーションがこれを実行できるわけではありません)。サーバーに毎月次々にパッチを適用でき、唯一のダウンタイムはアプリケーションの初回です。リスナーを再度ポイントします。
オプションは、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