Configure SQL Server Always ON Availability Groups between Two Synchronous Replicas. Part 2

We already covered some theory about configuring Always ON Availability Groups for Linux-based SQL Servers. The current article will focus on practice.

We are going to present the step-by-step process of configuring the SQL Server Always ON Availability Groups between two synchronous replicas. Also, we’ll highlight the usage of the configuration-only replica to perform automatic failover.

Before we start, I would recommend you to refer to that previous article and refresh your knowledge.

CodingSight - Configure Two Node Synchronous Replicas and a Configuration-Only Replica on PACEMAKER Cluster between 3-Node Ubuntu Linux Systems. Part 2
Read More

Understanding Always ON Availability Group between Linux-Based SQL Server Instances. Part 1

SQL Server Always ON Availability Group is a solution meant to achieve high availability and disaster recovery for SQL Server databases. We can configure this functionality between the Windows-based SQL Server installations, Linux-based SQL Server installations, and even between Linux and Windows-based SQL Server installations together.

CodingSight - Understanding Always ON Availability Group between Linux-Based SQL Server Instances
Read More

Different Ways to Monitor SQL Server AlwaysOn Availability Groups

In my previous articles, I have explained the step-by-step process of deploying an AlwaysOn Availability group on SQL Server 2017. In this article, I am going to explain how to monitor AlwaysOn availability groups.

First, let’s review the configuration of the availability group we had deployed previously. To do that, open SQL Server Management Studio Expand database engine from the object explorer Expand “AlwaysOn High Availability Expand “Availability Groups.” You can see the availability group named SQLAAG. Under this availability group (SQLAAG), you can see the list of availability replicas, availability databases, and availability group listeners. Read More

SQL Server AlwaysOn Availability Groups: Installation and configuration, Part 1

In this article, I will explain the process of installing pre-requisites to deploy the SQL Server AlwaysOn availability group.

For the demonstration, I have prepared a demo set up at my work station. See the following components:

Virtual Machine Host Name Purpose
Domain Controller DC.Local The domain controller is installed on this machine
Primary Replica SQL01.DC.Local This machine acts as a Primary replica in the Availability group
Secondary Replica SQL02.DC.Local This machine acts as a Secondary replica in the Availability group. This replica is in a Synchronous commit mode
Secondary Replica with SQL03.DC.Local This machine acts as a secondary replica in the Availability group. This replica is in an Asynchronous commit mode

I will explain the following actions:

  1. Installing a failover clustering role
  2. Create a failover cluster
  3. Enable AlwaysOn availability group features in SQL Server

Read More

SQL Always On Availability Groups: Computer Objects

SQL Server Always On Availability Groups is Microsoft’s latest technology for addressing the High Availability and Disaster Recovery needs of organizations that use SQL Server. One big advantage of AlwaysOn is the ability to address both HA and DR in one implementation. We experienced the following key benefits of AlwaysOn:

  1. We can group related databases as part of a single Availability Group and have them failover together in case this is needed. This is especially useful for applications that depend on more than one database, such as Microsoft Office SharePoint, Microsoft Lync, and Sage.

  2. When compared to SQL Server Failover Cluster Instances, we find that storage as a single point of failure has been eliminated since each instance which constitutes a replica is assigned its own storage.

  3. With AlwaysOn, it is possible to configure HA and DR at once. This is achieved by creating a Multi-site Windows Failover Clusters as the foundations of your AlwaysOn configuration. Performing a Role Switch when using AlwaysOn is significantly simpler than doing it when using Transaction Log Shipping.

Read More