I have a cluster of databases, one primary and two secondary. I need to enable CDC on a database, but I want to enable it on one of the secondary databases to eliminate any resource consumption on the primary database (similar to SQL Server secondary database backup). Is this possible to do it and how? If not: can you tell me the best practices for enabling CDC on cluster?
I want to enable it on one of the secondary databases to eliminate any resource consumption on the primary database
This is not possible. CDC writes the changes back to system tables in the target database, so must run against the primary replica. See Replication, change tracking, & change data capture - Always On availability groups
Related
Currently working on customer releases for our product. First step is to compare the customer database with our current dev db. Apparently we need to shut off cdc to do this, which drops all of the system cdc tables. Is there any way to backup and restore these tables for after we've finished comparing the two db's?
Apparently we need to shut off cdc to do this.
Completely agree with #DavidBrown that it isn't necessary to disable CDC for comparing the databases.
CDC enabled database simply means that your database captures the data change automatically. It manages that changed data in a separate table therefore you can still compare your database with different database without disabling CDC.
In case if required, you can restore the CDC enabled database by referring this third-party tutorial.
Restoring a SQL Server database that uses Change Data Capture
I have a distributed SQL Server (Always On) High Availability Group, using SQL Server 2016, with the purpose of disaster recovery. The servers exist in different datacenters, and the primary is doing async commits to the Distributed AG. I want to test a failover to the DAG without disrupting the traffic flow to the primary.
My question is - If I execute the ALTER AVAILABILITY GROUP [DAG_NAME_HERE] FORCE_FAILOVER_ALLOW_DATA_LOSS; command on the DAG, will both servers now be able to handle read/writes, or will the original primary become unavailable, and only the DAG (which is now the primary) can handle read/writes.
Only the secondary (which is not the primary) can do read/writes. The others are suspended.
From MS (https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/perform-a-forced-manual-failover-of-an-availability-group-sql-server?view=sql-server-ver15):
The secondary databases in the remaining secondary replicas are
suspended and must be manually resumed.
Confirmed that running the ALTER AVAILABILITY GROUP [DAG_NAME_HERE] FORCE_FAILOVER_ALLOW_DATA_LOSS; SQL Command against the secondary in a Distributed Availability Group configuration, both SQL Servers essentially become a primary that can handle read/writes, but synchronization between the 2 AG's is halted.
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 tried many things and analyzed lots of documents but I haven't found a solution yet.
I have three virtual machines in VmWare called (DC,SQLServer01,SQLServer02). All of SQL Servers are member of a domain.(DC) I installed failover cluster for SQLServer01 and SQLServer02. I did necessary configurations in SQLServer01. Then I installed SQL Server 2014 for both servers. Now, I created an alwaysOn group. SQLServer01 is a primary and other is secondary. When I cut the connection of SQLServer01, everything is fine (Secondary becomes primary). It is acceptable for other condition.
However, when all servers are online, I can not do any operation (insert,update,delete,alter ,etc) except read operations in my secondary replica. I see always "database is read only" error. In properties of Alwayson group, both primary and secondary replica have all connections and secondary readable is "YES".
I want to make CRUD operations even if all servers are online. (I mean, do everything also for secondary replica. )
So, do you have any suggestion or idea?
Thank your time and consideration.
The error occurs because writing to secondary replicas in sql server is not possible. Only primary replica can host read-write databases, and an availability group can only have one single primary replica. Secondary replicas can host read-only databases only. When both replicas are available, only one of the two can be the primary and therefore support read-write. When only a single replica is available, that replica becomes primary replica because there are no other replicas, and read-write operations against that replica is possible.
What you need to configure instead is replication.
In SQL Server, merge replication allows you to write at multiple nodes, with periodic synchronization that resolves conflicts and pushes changes to all replicas.
Peer to Peer replication is another solution. Application layer must not allow conflicts (update of same row at more than one node), but is much faster.
In the business I work for we are discussion methods to reduce the read load on our primary database.
One option that has been suggested is to have live one-way replication from our primary database to a slave database. Applications would then read from the slave database and write directly to the primary database. So...
Application Reads From Slave
Application Writes to Primary
Primary Updates Slave Automatically
What are the major pros and cons for this method?
A few cons:
2 points of failure
Application logic will have to take into account the delay between writing something and then reading it, since it won't be available immediately from the secondary database
A strategy I have used is to send key reporting data to a secondary database nightly, de-normalizing it on the way, so that beefy queries can run on that database instead of locking up tables and stealing resources from the OLTP server. I'm not using any formal data warehousing or replication tools, rather I identify problem queries that are Ok without up-to-the-minute data and create data structures on the secondary server specifically for those queries.
There are definitely pros to the "replicate everything" approach:
You can run any ad-hoc query on the secondary, since it has all of your data
If your primary server dies, you can re-purpose the secondary quickly to take over
We are using one-way replications, but not from the same application. Our applications are reading-writing to the master database, the data gets synchronized to the replca database, and the reporting tools are using this replica.
We don't want our application to read from a different database, so in this scenario I would suggest using file groups and partitioning on the master database. Using file groups (especially on different drives) and partitioning of files and indexes can help on performance a lot.