Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

SQL Server 2017 AlwaysOn on Linux configuration and maintenance (14)

2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)06/01 Report--

2.5 Action 2.5.1 availability group upgrade

Before upgrading, you can refer to the model and practice for upgrading replica instances of AG.

The order in which instances are upgraded depends on whether the roles are secondary copies and whether they are synchronous or asynchronous copies. First upgrade the instance that hosts the asynchronous copy, and then upgrade the instance that hosts the synchronous copy.

Note: if an AG has only an asynchronous copy, to avoid data loss, change a copy to synchronous, wait until it is synchronized, and then upgrade the copy.

The following is for AG to perform a rolling upgrade of the SQL Server instance on Linux.

Back up each database

Stop the resources on the target secondary replica node that is about to be upgraded

Pcs constraint location ag_cluster-master avoids nodeName1

Upgrade SQL Server on the secondary copy

Sudo yum update mssql-serversudo yum update mssql-server-ha

Remove position constraint

Pcs constraint remove location-ag_cluster-master-rhel1--INFINITY

Verify that the resource is started and the secondary copy is connected and synchronized after the upgrade

Pcs status

After all secondary replicas are upgraded, manually fail over to a synchronous replica.

For AG of type EXTERNAL, use cluster management tools to fail over

For AG of type NONE, use Transact-SQL for failover.

Sudo pcs resource move ag_cluster-master-master

Important: the following steps apply only if AG does not have Cluster Administrator.

If AG is of type NONE, fail over manually. It is done in the following order.

1. Set the primary copy as secondary

ALTER AVAILABILITY GROUP [ag1] SET (ROLE = SECONDARY)

two。 Set the synchronization secondary copy as the primary

ALTER AVAILABILITY GROUP [ag1] FAILOVER

After a failover, upgrade SQL Server on the old master copy.

# add constraint for the resource to stop on the upgraded node# replace 'nodename2' with the name of the cluster node targeted for upgradepcs constraint location ag_cluster-master avoids nodeName2# upgrade mssql-server and mssql-server-ha packagessudo yum update mssql-serversudo yum update mssql-server-ha# remove the constraint; make sure the resource is started and replica is connected and synchronizedpcs constraint remove location-ag_cluster-master-rhel1--INFINITY

For AG type EXTERNAL, clean up positional constraints caused by manual failover

Sudo pcs constraint remove cli-prefer-ag_cluster-master

Restore data movement for the newly upgraded secondary copy (that is, the old primary copy)

ALTER DATABASE database_name SET HADR RESUME

After upgrading all the servers, you can switch back the master copy as needed.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report