Configure SQL Server on Linux high availability for metabases - Precisely Data Integrity Suite

Data Integrity Suite

Product
Spatial_Analytics
dis_mcp
Data_Integration
Data_Enrichment
Data_Governance
Precisely_Data_Integrity_Suite
geo_addressing_1
platform_spatial_analytics
Data_Observability
Data_Quality
dis_core_foundation
Services
Spatial Analytics
Precisely MCP
Data Integration
Data Enrichment
Data Governance
Geo Addressing
Data Observability
Data Quality
Core Foundation
ft:title
Data Integrity Suite
ft:locale
en-US
PublicationType
pt_product_guide
copyrightfirst
2000
copyrightlast
2026
Prepare SQL Server on Linux availability group replicas so Connect CDC metabases continue to work after failover.
You must be a database administrator for the SQL Server on Linux instances that host the Connect CDC metabase and the source databases enabled for CDC.

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 before it can become the primary replica.
    For standard availability groups, create the matching rpuser login, grant msdb access, enable SQL Server Agent, prepare the backup directory, and create CDC capture and cleanup jobs on each replica. For contained availability groups, the contained master and msdb databases replicate the login, permissions, and jobs, but SQL Server Agent and the backup directory remain host-level requirements.
  • Schedule transaction log backups for each metabase.
    The metabase runs in FULL recovery because SQL Server requires that recovery model for availability group membership. Without log backups, the transaction log continues to grow until the filesystem is exhausted.
  • Remove leftover secondary copies after deleting a metabase.
    Connect CDC removes the metabase from the availability group and drops it on the primary replica. SQL Server leaves each secondary copy in RESTORING state, so you must identify and drop those copies on the secondary replicas.
  • Check availability group readiness before and after each failover.
    Before a planned failover, confirm the target replica is prepared and synchronized. After any failover, confirm the listener resolves to the new primary, metabases remain online and in the group, and CDC jobs and log backups are still present.
  • Keep the rpuser password synchronized across replicas.
    Connect CDC stores one password for the data connection. If replicas hold different rpuser passwords, authentication can succeed on one replica and fail after failover to another.
  • For distributed availability groups, confirm metabase operations reach the global primary.
    A listener can resolve to a local primary that is a forwarder rather than the global primary. Create and delete metabase operations must run against the global primary.
The SQL Server on Linux replicas are prepared for Connect CDC metabase availability group operations, planned maintenance, and failover recovery.

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.

  1. Check whether the availability group is contained.
    SELECT name, is_contained FROM sys.availability_groups;

    If the is_contained column does not exist, the group is not contained.

  2. For a standard availability group, retrieve the rpuser security identifier from the replica where the metabase was created.
    SELECT name, sid FROM sys.server_principals WHERE name = 'rpuser';
  3. For a standard availability group, create the rpuser login with the same security identifier and password on every other replica.
    USE master;
    CREATE LOGIN rpuser
        WITH PASSWORD = '<same password as the original replica>',
             SID = 0x<sid from the query above>,
             DEFAULT_DATABASE = master;
    
    EXEC sp_addsrvrolemember 'rpuser', 'bulkadmin';
  4. For a standard availability group, grant rpuser access to msdb.
    USE msdb;
    IF NOT EXISTS (SELECT 1 FROM sys.database_principals WHERE name = 'rpuser')
        CREATE USER rpuser FOR LOGIN rpuser;
    EXEC sp_addrolemember 'SQLAgentReaderRole', 'rpuser';
  5. Enable SQL Server Agent on every replica.
    systemctl status mssql-server-agent

    If SQL Server Agent is not enabled, enable it and restart SQL Server.

    sudo /opt/mssql/bin/mssql-conf set sqlagent.enabled true
    sudo systemctl restart mssql-server
  6. Create the backup directory on every replica.
    sudo mkdir -p /var/opt/mssql/backup
    sudo chown mssql:mssql /var/opt/mssql/backup

    The directory must be writable by the mssql service account. Connect CDC writes the metabase enrollment backup to this path, and your log backup job can also use it.

  7. For a standard availability group, create CDC capture and cleanup jobs for each CDC-enabled source database on every replica where CDC was not originally enabled.
    USE [<source database>];
    
    IF NOT EXISTS (SELECT 1 FROM msdb.dbo.sysjobs WHERE name = 'cdc.<source database>_capture')
        EXEC sys.sp_cdc_add_job @job_type = N'capture';
    
    IF NOT EXISTS (SELECT 1 FROM msdb.dbo.sysjobs WHERE name = 'cdc.<source database>_cleanup')
        EXEC sys.sp_cdc_add_job @job_type = N'cleanup';

    This applies to source databases enabled for CDC, not to the metabase. Repeat this step whenever a new source database is added to a pipeline.

  8. Verify the replica configuration.
    SELECT name, sid FROM sys.server_principals WHERE name = 'rpuser';
    
    SELECT dp.name FROM msdb.sys.database_principals dp WHERE dp.name = 'rpuser';
    
    SELECT name, enabled FROM msdb.dbo.sysjobs WHERE name LIKE 'cdc.%';

    For a contained availability group, the rpuser, msdb, and CDC job checks confirm that the contained system databases replicated as expected. In contained groups, Connect CDC must connect through the contained availability group listener so it resolves to the contained master and msdb.

Each replica has the host-level services, filesystem path, login, permissions, and CDC jobs required to run Connect CDC after failover.

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.

  1. Add each metabase to the same log backup routine used for other availability group databases.
    If your maintenance jobs already enumerate all availability group databases in FULL recovery, each new metabase is covered automatically.
  2. Keep each metabase in FULL recovery.
    Do not change the metabase to SIMPLE recovery. A database in SIMPLE recovery cannot remain in an availability group.
The metabase transaction log is truncated by scheduled backups and does not grow until disk space is exhausted.

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.

  1. On each secondary replica, find databases in RESTORING state that are no longer availability group members.
    SELECT d.name, d.state_desc, d.create_date
    FROM sys.databases d
    LEFT JOIN sys.availability_databases_cluster adc
           ON adc.database_name = d.name
    WHERE d.state_desc = 'RESTORING'
      AND adc.database_name IS NULL
      AND d.database_id > 4
    ORDER BY d.create_date;
  2. Confirm that each candidate database is a deleted Connect CDC metabase.
    A database in RESTORING state that is no longer in an availability group can also be a log shipping secondary or a restore that is deliberately in progress. If you use a metabase naming convention, add it to the query before dropping anything.
  3. Verify that the metabase is not online and is not still in the availability group.
    SELECT name, state_desc FROM sys.databases WHERE name = '<metabase>';
    
    SELECT COUNT(*) AS still_in_ag
    FROM sys.availability_databases_cluster
    WHERE database_name = '<metabase>';
  4. Drop the secondary copy.
    DROP DATABASE [<metabase>];
    Warning: Never drop a database that is ONLINE or still an availability group member. In a distributed availability group, check the partner group replicas as well.
The deleted metabase no longer consumes disk space on secondary replicas and no longer blocks a future metabase with the same name.

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.

  1. Allow any in-flight metabase creation or deletion to finish.
  2. Confirm the target replica has been prepared.
    The target replica should have the required rpuser setup, msdb access, SQL Server Agent service, backup directory, and CDC jobs for its availability group type.
  3. Confirm the metabase log backup job exists on the target replica.
  4. Run the deleted-metabase sweep on secondary replicas.
  5. Take a transaction log backup.
  6. Confirm all synchronous-commit replicas report SYNCHRONIZED.
    SELECT ar.replica_server_name, ars.synchronization_health_desc
    FROM sys.dm_hadr_availability_replica_states ars
    JOIN sys.availability_replicas ar ON ars.replica_id = ar.replica_id;
  7. Record the current primary for comparison after failover.
The planned failover can proceed with the target replica prepared for Connect CDC metabase and CDC operations.

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.

  1. Identify the new primary replica.
    SELECT @@SERVERNAME AS instance, role_desc
    FROM sys.dm_hadr_availability_replica_states
    WHERE is_local = 1;
  2. Connect through the listener and confirm it resolves to the new primary.
    SELECT @@SERVERNAME;
  3. Confirm metabases are online and still availability group members.
    SELECT d.name, d.state_desc,
           CASE WHEN adc.database_name IS NULL THEN 'NOT IN AG' ELSE 'in AG' END AS ag_status
    FROM sys.databases d
    LEFT JOIN sys.availability_databases_cluster adc ON adc.database_name = d.name
    WHERE d.database_id > 4;
  4. Check each metabase for orphaned users.
    USE [<metabase>];
    SELECT dp.name AS orphaned_user, dp.sid
    FROM sys.database_principals dp
    LEFT JOIN sys.server_principals sp ON dp.sid = sp.sid
    WHERE sp.sid IS NULL
      AND dp.type IN ('S', 'U')
      AND dp.name NOT IN ('guest', 'dbo', 'sys', 'INFORMATION_SCHEMA');

    No rows is the expected result. If rpuser appears and the login exists with a different security identifier, repair the mapping with ALTER USER rpuser WITH LOGIN = rpuser;.

  5. Confirm CDC capture and cleanup jobs exist.
    SELECT name, enabled FROM msdb.dbo.sysjobs WHERE name LIKE 'cdc.%';

    Each CDC-enabled source database should have a _capture job and a _cleanup job. If either job is missing, create the missing jobs on the new primary.

  6. Confirm the log backup job is present and enabled.
    SELECT name, enabled FROM msdb.dbo.sysjobs WHERE name LIKE '%log%backup%';
  7. Sweep the former primary for leftover deleted metabase copies.
  8. Verify in the Connect CDC portal that pipelines have reconnected through the listener and are capturing changes.
Connect CDC metabases and CDC-enabled source databases are verified on the new primary. Resume metabase creation and deletion only after the primary, listener, metabase, orphaned-user, CDC job, and log backup checks pass.

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.

  1. On each replica, change the rpuser password to the same value.
    ALTER LOGIN rpuser WITH PASSWORD = '<new password>';
  2. Update the data connection in the Connect CDC portal.
  3. Confirm pipelines reconnect successfully.
All replicas accept the same 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.

  1. Confirm that the deployment uses a distributed availability group.
    SELECT name, is_distributed FROM sys.availability_groups;
  2. Before creating or deleting a metabase, check whether the listener has resolved to a writable metabase instance.
    SELECT DATABASEPROPERTYEX(N'<an existing metabase>', 'Updateability') AS updateability;

    The value must be READ_WRITE. A value of READ_ONLY indicates a forwarder.

  3. Check this instance's role in each availability group.
    SELECT ag.name, ag.is_distributed, ars.role_desc
    FROM sys.dm_hadr_availability_replica_states ars
    JOIN sys.availability_groups ag ON ag.group_id = ars.group_id
    WHERE ars.is_local = 1;
  4. If the listener resolved to a forwarder, fail the distributed group back or direct the operation to the availability group that currently holds the global primary role.
Metabase create and delete operations run against the global primary. Running against a forwarder can create a metabase that does not replicate or can produce SQL Server error 3752 during deletion.

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.

Table 1. SQL Server on Linux high availability troubleshooting
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.
  1. For active rpuser sessions, identify the owning sessions.
    SELECT s.session_id, s.login_name, s.host_name, s.program_name,
           s.status, s.last_request_end_time, DB_NAME(s.database_id) AS database_name
    FROM sys.dm_exec_sessions s
    WHERE s.login_name = 'rpuser';
  2. Stop the pipelines that own the sessions.
  3. If sessions persist after the pipelines stop and you confirm the sessions are idle, stop the sessions.
    KILL <session_id>;
  4. Enroll a metabase manually only when automatic enrollment did not take effect.
    USE master;
    ALTER DATABASE [<metabase>] SET RECOVERY FULL;
    BACKUP DATABASE [<metabase>] TO DISK = N'/var/opt/mssql/backup/<metabase>.bak' WITH INIT, FORMAT;
    ALTER AVAILABILITY GROUP [<ag name>] ADD DATABASE [<metabase>];

    Run manual enrollment on the global primary. Then join the database on each secondary by using your standard onboarding process or automatic seeding.

The likely cause is identified and the recovery action is tied to the affected replica, metabase, CDC job, or availability group route.