I'm designing my Azure Website for High Availability. In the interesting of doing so, I read the following: https://azure.microsoft.com/en-us/documentation/articles/sql-database-designing-cloud-solutions-for-disaster-recovery/#design-pattern-1-active-passive-deployment-for-cloud-disaster-recovery-with-a-co-located-database
In particular, I'm attempting to use Pattern #1. In short, you:
Establish your primary site and a backup site.
Your backup site remains active, but never used directly while your primary site is functional.
All database transactions are replicated from the primary to the secondary as they occur
When a failover occurs, your traffic only hits your backup site.
My question is: after you failover, how would you return to your primary site? If database transactions were written to your secondary database, they'd need to be written back to the primary. Would you use "Geo Restore" (https://azure.microsoft.com/en-us/blog/azure-sql-database-geo-restore/) and restore your backup over your primary, then update the Azure Traffic Manager to begin using your primary location again?
As I understand correctly, the 'syncing back' is done automatically.
See here
When the failed primary recovers and is available again, the system will automatically mark it as a secondary and bring it up-to-date with the new primary.
And then, yes, I would update the Traffic Manager to route to the original primary again.
Related
I want to implement solution such that the secondary server database is queryable.
Amongst the following options:
Log shipping
Transactional replication
Database mirroring
Always on failover clustering
Always on availability groups
Which of the above methods allows the secondary server database to be online and queryable?
Are there any more options other than the above 5 ?
Log shipping
Secondary Database is "normally" in a recovering state so that additional backups can be applied
Secondary database can be made readable between restores by restoring with STANDBY
Users on secondary must be disconnected so that the next restore can take place
Transactional replication
Primary and Secondary databases are independent and can have transactions on bot sides
Secondary database is not restricted to READ-ONLY. Users can make updates if they have permissions
Be wary of updates on the Secondary that could cause issues with future replication updates from the Primary
Secondary is always online
Database mirroring
Deprecated technology
Requires a Database Snapshot to be taken to allow a queryable copy
Snapshot Database will have a different name from the Primary and Secondary
No updates applied to Snapshot
Snapshot will increase in size as changes made to Secondary because of copy-on-write process
Need to drop the snapshot (disconnecting users) and recreate it to get newer data
Always on failover clustering
There is only 1 copy of the database in Failover Clustering - it is the ownership of the storage that changes on a failover. This has no Secondary to make available for querying
Always on availability groups
Allows a Secondary to be set to read-only
Continuously updated from Primary
Be wary also of license restrictions if you make secondary copies queryable.
I have two bases in a group on SQL Server.
The first one is primary and the second is the replica.
I want to connect to the replica (from a simple C # application) if the primary one falls.
How can I do that? Thank you!
If your databases are in an Availability Group (AG), you should point your application to the Listener for the AG. This is a network name that will always point to the primary server for the AG.
SQL Server 2008 Enterprise and later versions support backup compression. When creating a log shipping configuration, you can control the backup compression behavior of log backups and if you already have a Replica then you can configure it When an availability failover occurs, existing persistent connections to the availability are terminated and the client must establish a new connection in order to continue working with the same primary database or read-only secondary database. For more information.
Configure Log Shipping
Secondary Database Settings
Application Failover
I have my WSFC setup with three nodes in my Availability Group. One for DR and one primary and the other active secondary.
the secondary will be used to failover should my primary server fail. My question is can I also use the secondary to do backups and reporting on it as well?
If so, if there is an on going backup happening on my secondary node, and suddenly the primary crashes. What happens in this case?
Does the backup stop and the failover begins to the secondary node, or does it wait till the backup finishes?
I'm using SQL Server 2016
Reporting off the secondary, read only copy shouldn't be a problem. Just make sure you include ApplicationIntent=ReadOnly in the connection string of of your shared data source.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I just read thisActive Geo-Replication for Azure SQL Database article on active geo-replication and have some questions. I posted these questions on the page with the article but haven't gotten a reply yet.
Could really use help!
“Every forced termination results in the irreversible loss of the replication relationship between the primary database and the associated online secondary database.” What does irreversible mean here? Does it mean that in order to re-establish a replication relationship between the primary database and an associated online secondary database after a forced termination, we’d need to start over with seeding another online secondary database?
“Local data redundancy and operational recovery are standard features for Azure SQL Database. Each database possesses one primary and two local replica databases that reside in the same datacenter, providing high availability within that datacenter. This means that the Active Geo-Replication databases also have redundant replicas. Both the primary and online secondary databases have two secondary replicas.” So, if we imagine we have active geo-replication up and running and the primary database is lost for some reason. Will Azure SQL automatically put one of the remaining two local replicas that exist within the same datacenter as part of the standard local data redundancy and operational recovery Azure SQL feature in place of the primary database that was just lost with no impact to existing connections? If so, I would take that to mean that the only case in which a forced termination of the replication relationship between the primary database and the online secondary (via geo-replication) would only be necessary would be if all 3 copies of the database existing in the local datacenter were lost. Is that right?
Using an active geo-replication configuration, can online secondary databases be in the same region as the primary? Say we wanted active geo replication within the same region for a time. Is that doable? I realize that, from a regional disaster perspective, having online secondaries in the same region would defeat the purpose. Still would be good to know if it’s doable.
Forced terminate requires you to restart the process of creating active geo replication.
You will be able to force terminate if the primary database is unavailable. SQL DB maintains local HA and if one replica down then it switches to a local secondary and built the replacement replica
For premium databases you can set up active replication with in the region. This also helps you read scale out.
If you force terminate the continuous copy link then a new link must be established to enable Geo-Replication on the new primary database. This would create a new database and start over with the seeding of another online secondary database.
Azure SQL Database has built-in high availability. Geo-Replication (and forced failover) only needs to be used in the event of a disaster causing the entire data center with the primary database (and its replicas) to be unavailable.
Active Geo-Replication can be used to scale out read workloads. Active Geo-Replication can be configured in the same region, but the replica must be on a different server than the primary. See "design pattern 2".
I am a newbie to database administration. I am trying to get things sorted out but as I study more and more about oracle database backup I get more messed up, so I've decided to ask here. Please accept my apologize if I say something ridiculous :p.
Here is my "simple" situation 1:
Assuming I have 2 server rack, one is my Primary Server, another is my Backup Server (Both server sitting in the same site).(Using Oracle 11g), When the Primary Database broke down, the primary database service will point to backup database. Therefore, the backup database must always be updated from primary database, like a mirror. So my questions are:
What backup method suits this situation? Oracle Dataguard? Oracle Stream? Oracle Goldengate?
Can Oracle Active Dataguard achieve this approach?
If Oracle Active Dataguard can achieve this, the redo-log will only be applied when there is a switchover? So if the primary database broke down and the redo-log only starts to apply into the backup database, I'll have some downtime before my production can resume? This production requires 0 downtime.
Please feel free to comment on the database architecture base on the following requirements and feel free to change it if it is not correct.
Requirements:
No downtime. The site is running 24/7.
Auto switchover to backup database without human interaction.
Able to notify administrator after switchover (If the switchover is completely transparent, no one will realize something went wrong with the primary database right?)
Thank you so much.
P/s: Sorry for my horrible english.
As per your requirements, Oracle data guard is the best solution. Oracle goldengate uses replication concept. Oracle data guard is purely for high availability. There are various protection modes exist in data guard. You can set protection mode for minimum data loss. During Active data guard, standby database (here on backup server as per your detail) is also available for querying and executing read only operations like generating reports. This feature is used for decreasing load on production (here primary server). During this stage, your standby database (backup server) is open in read only mode and also accepting changes (redo) from primary database. It means, it is still updating in background and syncing. There is very minimum chance of data loss and minimum downtime during this stage. Using dataguard, you can set automated switchover task too.
In older versions of Oracle (prior to 11g), if we open standby database in read only mode then it does not accept changes from primary database. If primary database will crash in this situation then we need to apply all changes to standby database manually and wait for data synchronization after that we can switch.
You need to study your technical requirements, consider your IT budget for using these features because Oracle dataguard is license product.