When upgrading a SQL Server mirrored instance to a new SQL Server version, to a new SQL Server Service Pack or Cumulative Update, or to a new Windows service pack or cumulative update, you can reduce downtime for each mirrored database to only a single manual failover by performing a rolling upgrade (or two manual failovers if failing back to the original primary).
A rolling upgrade is a multi-stage process that in its simplest form involves upgrading the SQL Server instance that is currently acting as the mirror server in a mirroring session, then manually failing over the mirrored database, upgrading the former principal SQL Server instance, and resuming mirroring.
In practice, the exact process will depend on the operating mode and the number and layout of mirroring session running on the SQL Server instances that you are upgrading.
Please refer this MSDN Article for Prerequisites & Best Practices to perform a rolling upgrade.
The steps to upgrade SQL server 2012 to 2014 under ScaleArc are as follows:
1. Make sure on RW server on scalearc all primary dbs are present. If not do manual failover and bring all primary dbs on primary server.
2. Check databases using ‘DBCC CHECKDB (“<db_name>”)‘ query. It should not report any error.
3. To be on the safer side take backup of database by right clicking on db -> selecting task -> BackUp. Take Full backup.
4. Convert replication type of all dbs to “High safety without automatic failover”. i.e. Sync
5. Do upgrade of witness db server first by following steps below.
a. Mount SQL Server 2014 iso.
b. Execute iso and select Installation -> Upgrade from 2012
c. Follow the installation steps. Find attached snapshots of every window during upgrade.
d. After upgrade restart SSCM services.
6. Do upgrade of standby/mirror by following steps 5.a to 5.d.
7. Do scalearc based switchover.
8. All dbs should become primary on promoted server. i.e. server which we have upgraded at step 6.
9. DBs will be in suspended mode on new primary. Traffic will not be affected.
10. Do upgrade of current standby by following steps 5.a to 5.d.
11. After upgrade is done restart SSCM service again on current primary and on witness server. (Note : Here as service is restarted failover might get triggered and role of servers might get changed. Also there will be error on connections which are in process during service restart).
12. Manually resume replication for each db.
13. Manually restore replication type as per step 4 modifications.
14. Validate replication is working correctly and recovery rate value is coming an integer in output of stored procedure execution “EXEC sp_dbmmonitorresults "SID_Sync", 0, 1;” on msdb database on stanby server.
IMP NOTE: Please Note that after Initiating a SWITCHOVER the NEW Incoming Connections recieved by ScaleArc will be held in SURGE QUEUE during the SWITCHOVER and will be directed to the NEW R+W Database once the roles are changed but the In-Flight Connection (Connections which are already being processed by OLD R+W Server) will be Disconnected.