Skip to main content

MS SQL Server Mirroring v/s MS SQL Always on

MS SQL Server Mirroring v/s MS SQL Always on

MS SQL Server Mirroring and Always On Availability Groups are both high-availability and disaster recovery solutions provided by Microsoft SQL Server, but they have some key differences:

SQL Server Mirroring:

  • MS SQL Server Mirroring is an older technology and has been deprecated in newer versions of SQL Server.
  • Mirroring works on a per-database basis, meaning that each database needs to be individually configured for mirroring.
  • It uses a principal and mirror server configuration, where the principal server handles client connections and the mirror server maintains a synchronized copy of the database.
  • Automatic failover is possible in high-safety mode with the help of a witness server, which monitors the availability of the principal server.
  • Mirroring supports synchronous and asynchronous replication modes.
  • Mirroring is limited to two servers and does not provide read scalability.
  • Mirroring is available in the Standard and Enterprise editions of SQL Server.
  • Mirroring operates at the database level and provides database-level failover.
  • It allows for automatic failover, but only in the case of synchronous mode with a witness server.
  • Mirroring requires a separate server instance to act as the mirror server, which operates in a standby mode and maintains an identical copy of the principal database.


Always On Availability Groups:

  • Always On Availability Groups is available in the Enterprise edition of SQL Server.
  • Always On Availability Groups is the recommended high-availability and disaster recovery solution for SQL Server.
  • Availability Groups operate at the database level and can include multiple databases within a single group.
  • It allows for more advanced configurations, such as multi-site fail-over clusters and read scalability with readable secondary replicas.
  • Automatic fail-over is supported in both synchronous and asynchronous replication modes, and no witness server is required.
  • Availability Groups provide enhanced monitoring, backup capabilities, and integration with Windows Server Failover Clustering.
  • Availability Groups support multiple secondary replicas, enabling read-only access to secondary replicas for offloading reporting or backups.
  • It provides more granular control over fail-over, allowing for automatic or manual fail-over at the availability group level.

    AWS recommended architecture for SQL Server with Amazon RDS:



Ref.:

https://docs.aws.amazon.com/images/dms/latest/sbs/images/sbs-aws-dms-listener-ip-connection.png

https://docs.aws.amazon.com/dms/latest/sbs/chap-manageddatabases.sqlserveralwayson.ag.html


In summary, while SQL Server Mirroring is a simpler solution limited to two servers and deprecated in newer versions of SQL Server. Always On Availability Groups provide more advanced features, scalability, and flexibility for high availability and disaster recovery scenarios. It is recommended to use Always On Availability Groups for new SQL Server deployments.

In summary, SQL Server Mirroring is a simpler and more basic form of high availability and disaster recovery. However, it's important to note that SQL Server Mirroring has been deprecated by Microsoft, and Always On Availability Groups is the recommended solution for achieving high availability and disaster recovery in modern versions of SQL Server.

Labels:

Comments

Post a Comment

Popular posts from this blog

MySQL InnoDB cluster troubleshooting | commands

Cluster Validation: select * from performance_schema.replication_group_members; All members should be online. select instance_name, mysql_server_uuid, addresses from  mysql_innodb_cluster_metadata.instances; All instances should return same value for mysql_server_uuid SELECT @@GTID_EXECUTED; All nodes should return same value Frequently use commands: mysql> SET SQL_LOG_BIN = 0;  mysql> stop group_replication; mysql> set global super_read_only=0; mysql> drop database mysql_innodb_cluster_metadata; mysql> RESET MASTER; mysql> RESET SLAVE ALL; JS > var cluster = dba.getCluster() JS > var cluster = dba.getCluster("<Cluster_name>") JS > var cluster = dba.createCluster('name') JS > cluster.removeInstance('root@<IP_Address>:<Port_No>',{force: true}) JS > cluster.addInstance('root@<IP add>,:<port>') JS > cluster.addInstance('root@ <IP add>,:<port> ') JS > dba.getC...
Post a Comment
Read more

MySQL slave Error_code: 1032 | MySQL slave drift | HA_ERR_KEY_NOT_FOUND

MySQL slave Error_code: 1032 | MySQL slave drift: With several MySQL, instance with master slave replication, I have one analytics MySQL, environment which is larger in terabytes, compared to other MySQL instances in the environment. Other MySQL instances with terabytes of data are running fine master, slave replication. But this analytics environment get started generating slave Error_code :1032. mysql> show slave status; Near relay log: Error_code: 1032; Can't find record in '<table_name>', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log <name>-bin.000047, end_log_pos 5255306 Near master section: Could not execute Update_rows event on table <db_name>.<table_name>; Can't find record in '<table_name>', Error_code: 1032; Can't find record in '<table_name>', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log <name>-bin.000047, end_l...
2 comments
Read more

InnoDB cluster Remove Instance Force | Add InnoDB instance

InnoDB cluster environment UUID is different on node: To fix it stop group replication, remove instance (use force if require), add instance back Identify the node which is not in sync: Execute following SQL statement on each node and identify the node has different UUID on all nodes. mysql> select * from mysql_innodb_cluster_metadata.instances; Stop group replication: Stop group replication on the node which does not have same UUID on all nodes. mysql > stop GROUP_REPLICATION; Remove instances from cluster: Remove all secondary node from the cluster and add them back if require. $mysqlsh JS >\c root@<IP_Address>:<Port_No> JS > dba.getCluster().status() JS > dba.getCluster () <Cluster:cluster_name> JS > var cluster = dba.getCluster("cluster_name"); JS >  cluster.removeInstance('root@<IP_Address>:<Port_No>'); If you get "Cluster.removeInstance: Timeout reached waiting......" JS > cluster.removeInstance(...
2 comments
Read more