When a metabase is hosted on a SQL Server instance with Always On enabled, Connect CDC detects the availability group and enrolls the metabase on the primary replica. Connect CDC sets the metabase recovery model to FULL, takes the full backup that starts the backup chain, and adds the metabase database to the availability group.
Some high-availability requirements remain outside the metabase database. Standard availability groups do not replicate objects in master and msdb, and removing a database from an availability group does not drop secondary copies from disk. Complete the tasks in this topic for every SQL Server on Linux availability group or distributed availability group that hosts Connect CDC metabases.
Prepare each replica
Configure each SQL Server on Linux replica with the login, job, service, and filesystem requirements needed after failover.
Perform this task during cluster build and whenever you add a replica. Completing it before failover prevents orphaned users, missing CDC jobs, and backup failures after another replica becomes primary.
Schedule transaction log backups
Add each SQL Server metabase to your transaction log backup schedule.
Connect CDC sets the metabase recovery model to FULL during availability group enrollment. A database in FULL recovery truncates its transaction log only after a log backup.
Remove deleted metabase copies
Drop leftover secondary metabase copies after deleting a metabase from the Connect CDC portal.
When you delete a metabase, Connect CDC removes the database from the availability group and drops it on the primary replica. SQL Server leaves the secondary copies on disk in RESTORING state.
Check planned failover readiness
Confirm the target replica and metabases are ready before a planned availability group failover.
Run these checks immediately before planned maintenance or failover.
Verify replication after failover
Check Connect CDC metabases and CDC jobs after any planned or unplanned failover.
Run these checks after every failover. For contained availability groups, the login, msdb, and CDC job checks confirm that contained system database replication is healthy.
Rotate the rpuser password
Change the rpuser password consistently across SQL Server on Linux replicas.
Use this task during credential rotation or after a password reset. Complete the replica changes in one maintenance window.
rpuser password, so authentication does not depend on which replica the listener routes to after failover.Check distributed availability group routing
Confirm that metabase operations are directed to the global primary in a distributed availability group.
This task applies only to distributed availability groups. In a distributed group, a listener can resolve to the primary of its local availability group even when that instance is a forwarder and not the global primary.
Troubleshoot SQL Server on Linux high availability issues
Use common symptoms to identify missing replica preparation, routing, backup, or cleanup work.
Use this table when SQL Server on Linux high-availability behavior affects Connect CDC metabases or CDC-enabled source databases.
| Symptom | Cause | Resolution |
|---|---|---|
A database with the same name remains in RESTORING state on secondary replicas after deleting a metabase. |
Expected SQL Server behavior. Removing a database from an availability group does not drop secondary copies. | Run the deleted-metabase cleanup task. |
| SQL Server error 3752 appears during metabase deletion. | The metabase is still part of an availability group, or the operation reached a forwarder instead of the primary. | Confirm the primary and listener routing. If required, remove the metabase from the availability group manually with ALTER AVAILABILITY GROUP [<ag>] REMOVE DATABASE [<metabase>];, then retry deletion. |
SQL Server error 15434 appears when dropping rpuser. |
An active rpuser session exists, usually from a running pipeline or pooled connection. |
Stop the pipelines that own those sessions. Stop a session only after you confirm that it is idle. |
| Pipelines fail to authenticate after failover, or login failures occur only on some replicas. | The rpuser login is missing, its security identifier differs, or its password differs between replicas. |
Prepare the replica again and synchronize the rpuser password across replicas. |
| CDC stops capturing after failover with no portal error. | CDC capture and cleanup jobs exist only on the former primary. | Create the missing CDC jobs on the new primary and add CDC job creation to replica preparation. |
| The transaction log grows continuously until disk fills. | The metabase is in FULL recovery and has no log backup job. |
Add the metabase to the transaction log backup schedule. |
| Metabase creation succeeds, but the metabase is absent from secondary replicas. | Availability group enrollment did not run, the operation reached a forwarder, or the backup path was not writable. | Confirm the backup directory and distributed availability group routing. Then enroll the metabase manually only as a recovery procedure. |
| CDC jobs exist but never run. | SQL Server Agent is disabled on the Linux host. | Enable SQL Server Agent and restart SQL Server. |