The question is related to configuring failover cluster on Azure VMs with SQL Server Enterprise version.
Is it possible to configure failover cluster with two machines like that:
one high-spec PRIMARY server (VM + SQL Server)
the second one on low-spec as the SECONDARY server (VM + SQL Server)
The main traffic will go to the PRIMARY as always but the SECONDARY will live there on low-spec just in case of downtime. That approach will save some money as it is more cost effective.
Can that be considered as bad/good/neutral practice? What are the other disadvantages apart from latency with syncing the data?
Note that this is failover cluster configuration only and it is set up to avoid the downtime when one of the servers goes down.
These articles are also very helpful, but there is no information related to my question:
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-portal-sql-create-failover-cluster
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-high-availability-dr
Related
I'm migrating a SQLServer DB which uses AlwaysOn feature for high availability in cluster on-premises. How to enable this in CloudSQL-SQLServer?, if not possible, is there any workaround ?
I'm a little confuse with HA and replica approaches and not sure if the combination of both could help on this.
The primary reason for using replication is to scale the use of data in a database without degrading performance. Other reasons include migrating data between regions.
Additionally, if an original instance is corrupted, a replica could
be promoted to a standalone instance (in which case, existing
replicas would not consider that instance as primary).
When referring to a Cloud SQL instance, the instance that is
replicated is called the primary instance and the copies are called
read replicas. The primary instance and read replicas all reside in
Cloud SQL.
Replication in Cloud SQL : SQL Server is currently in Pre-General Availability stage. SQL Server replication is implemented using SQL Server Read Scale Availability Groups.This feature only applies to the SQL Server 2017 Enterprise version of Cloud SQL for SQL Server. The preview is limited to the instances created or cloned on or after June 21, 2021.
The document reference for the same is here.
However, the purpose of an HA configuration is to reduce downtime when a zone or instance becomes unavailable. This might happen during a zonal outage, or when an instance becomes corrupted. With HA, your data continues to be available to client applications. The HA configuration, sometimes called a cluster, provides data redundancy.
The document reference for configuring HA for new/existing SQL Server
instances is here.
Note : Once you start the high availability configuration on an instance, you cannot stop it.
I would like to know what are best practices for using SQL Server replication on a SQL Server instance that may have other application databases that may also use replication. That is, our product needs to play well with other users of the instance.
The product currently uses SQL Server replication to create a copy database used for reporting. It is always the sole user of the SQL Server instance. But we now need to document and test (regulatory requirements) how the product can share the instance.
I'm making the assumption here that we still need replication as we do not see another way to isolate reporting load from the application's database.
Has anybody done this successfully?
If we are using instance level replication:
Is there a way we can stop/start/modify replication for our application without affecting others?
Do setting differ greatly? That is, is it realistic to share instance level replication settings across applications?
Non-instance replication just looks hard, do I have the wrong view here?
Our customers use SQL Server 2008 R2 or SQL Server 2012.
At an instance level, replication configures only one distributor. That is, regardless of how many databases you have configured for replication on an instance, they'll all share one distributor. You do have the option to make that distributor local (i.e. on the same instance) or remote. So, if you find that distribution is taking up considerable resources (or anticipate that that's going to be the case), configure remote distribution.
Whatever drive holds your databases' log files will need to have sufficient headroom in their throughput to handle the logreader agent. If you're concerned that your database's activity will be impacting to other databases, isolate.
As for other concerns, replication is a lot like your line of business application. That is, it needs to read data (from the publisher and distributor depending on which phase of replication you're talking about) and write data (from the distributor and subscriber again depending on which phase of replication you're talking about). Provision resources accordingly and you should be just fine.
We're migrating our environment over to AWS from a colo facility. As part of that we are upgrading our 2 SQL Server 2005s to 2014s. The two are currently mirrored and we'd like to keep it that way or find other ways to make the servers redundant. # of transactions/server-use is light for our app - but it's in production, requires high availability, and, as a result, requires some kind of fail over.
We have already setup one EC2 instance and put SQL server 2014 on it (as opposed to using RDBMS for licensing reasons and are now exploring what to do next to achieve this.
What suggestions do people have to achieve the redundancy we need?
I've seen two options thus far from here and googling around. I list them below - we're very open to other options!
First, use RDBMS mirroring service, but I can't tell if that only applies if the principal server is also RDBMS - it also doesn't help with licensing.
Second, use multiple availability zones. What are the pros/cons of this versus using different regions altogether (e.g., bandwidth issues) etc? And does multi-AZ actually give redundancy (if AWS goes down in Oregon, for example, then doesn't everything go down)?
Thanks for the help!
The Multi-AZ capability of Amazon RDS (Relational Database Service) is designed to offer high-availability for a database.
From Amazon RDS Multi-AZ Deployments:
When you provision a Multi-AZ DB Instance, Amazon RDS automatically creates a primary DB Instance and synchronously replicates the data to a standby instance in a different Availability Zone (AZ). Each AZ runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. In case of an infrastructure failure (for example, instance hardware failure, storage failure, or network disruption), Amazon RDS performs an automatic failover to the standby, so that you can resume database operations as soon as the failover is complete. Since the endpoint for your DB Instance remains the same after a failover, your application can resume database operation without the need for manual administrative intervention.
Multiple Availability Zones are recommended to improve availability of systems. Each AZ is a separate physical facility such that any disaster that should befall one AZ should not impact another AZ. This is normally considered sufficient redundancy rather than having to run across multiple Regions. It also has the benefit that data can be synchronously replicated between AZs due to low-latency connections, while this might not be possible between Regions since they are located further apart.
One final benefit... The Multi-AZ capability of Amazon RDS can be activated by simply selecting "Yes" when the database is launched. Running your own database and using mirroring services requires you to do considerably more work on an on-going basis.
I would like to know the differences between Failover Clustering and AlwaysOn Availability Groups in SQL Server 2012
AlwaysOn FailOver Clustering (FCI) is associated with Windows Services FailOver Clustering (WSFC). This is a High Availability (HA) scenario where two (or more) servers share a SAN, or WAN, or NAS. The first server is the Active Node (Node1). The second server is the Passive Node (Node2). A 3rd server called the Witness or Quorum server, does a heartbeat check on both servers on a set interval, usually between 1 to 3 seconds. If either of the servers doesn't answer the heartbeat ping, the other server is declared the primary node. If that is Node1, then no changes occur. If that is Node2, then the Witness server automatically fails-over the control of the databases to that node. Failover usually is withing 15 seconds. Any uncommitted transactions are automatically rolled-back.
AlwaysOn Availability Groups is an improvement on Database Mirroring. Database mirroring is for single databases, and also has two or more nodes. In this scenario, each of the nodes has it's own storage. The mirroring mechanism will either synchronously or Asynchronously ship transactions to the mirrored node. Synchronous mode would wait for the validation signal from the mirror before committing the transaction in the primary. Asynchronous mode would ship off the transactions and go straight to a local commit. AlwaysOn Availability Groups improves upon that concept by grouping databases together in Availability Groups. When one database fails-over, they all do. You must have AlwaysOn FCI configured to utilize AlwaysOn Availability Groups, as the have some common libraries.
references:
Adding Always-on Availability Groups to Existing Failover Clusters
Creating an SQL Server w/ Always-on Availability Group
Always-on Availability Groups vs Always-on Failover Clusters
I have a database on an SQL Server instance hosted on Azure Windows VM. There are two things I need to achieve.
Create a real-time duplicate of the database on another server. i.e. I need my database to make a copy of itself and then copy all of it's data to the duplicate at regular intervals. Let's say, 2 hours.
If my original database fails due to some reason, I need it to redirect all read/write requests to the duplicate database.
Any elaborate answer or links to any articles you deem helpful are welcome. Thank you!
You can have a high availability solution for your SQL Server databases in Azure using AlwaysOn Availability Groups or database mirroring.
Basically, you need 3 nodes for true HA. The third one can be a simple file server that will work as the witness to complete the quorum for your failover cluster. Primary and Secondary will be synchronized and in case of a failure, secondary will take over. You can also configure read requests to be split among instances.
If HA is not really that important for your use case, disaster recovery will be a cheaper solution. Check the article below for more info.
High Availability and Disaster Recovery for SQL Server in Azure Virtual Machines
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-high-availability-and-disaster-recovery-solutions/