Livesync replication troubleshooting
Troubleshoot Livesync replication when migrating to Tiger Cloud
Common issues you may hit while running a Livesync replication migration to Tiger Cloud, and how to resolve them.
_ts_live_sync.subscription_rel empty
Section titled “_ts_live_sync.subscription_rel empty”It may take up to 30 minutes for large publications before _ts_live_sync.subscription_rel is populated. Check Docker logs:
docker logs -f livesyncReplay not keeping up
Section titled “Replay not keeping up”Add indexes on UPDATE/DELETE WHERE-clause columns on the target. Ensure REPLICA IDENTITY includes the partition column on hypertables.
Lag growing
Section titled “Lag growing”Scale up the target. Check for long-running transactions on the source that hold xmin and prevent WAL cleanup:
SELECT pid, age(backend_xmin) AS xmin_age, queryFROM pg_stat_activityWHERE backend_xmin IS NOT NULLORDER BY xmin_age DESC;Initial data copy is slow or target IOPS saturated
Section titled “Initial data copy is slow or target IOPS saturated”If the target’s IOPS or disk throughput is pinned during the initial data copy, the most common cause is index maintenance on the destination tables. Each non-PK index has to be updated for every COPY’d row, which multiplies the I/O cost.
Drop the non-PK indexes on the target before the copy and recreate them after all tables reach state r or s. Primary-key and unique-constraint indexes must stay; Livesync uses them for INSERT ... ON CONFLICT deduplication.
-- On the TARGET, before initial copy:DROP INDEX IF EXISTS <schema>.<index_1>;DROP INDEX IF EXISTS <schema>.<index_2>;-- ... repeat for each non-PK indexAfter the initial copy completes, recreate the indexes (preferably in parallel sessions for large tables):
SET maintenance_work_mem = '2GB';SET max_parallel_maintenance_workers = 4;
CREATE INDEX <index_1> ON <schema>.<table> (...);-- ... etc.Other knobs to consider: lower --table-sync-workers, scale up target IOPS or CPU, or stagger heavy tables.
Restart a single table
Section titled “Restart a single table”-
Remove the table from the publication on the source:
ALTER PUBLICATION <publication_name> DROP TABLE <schema>.<table>; -
Stop and restart Livesync to remove catalog objects for the dropped table.
-
Confirm removal (this should return empty):
psql "$TARGET" -c "SELECT * FROM _ts_live_sync.subscription_relWHERE tablename = '<table>';" -
Truncate the table on the target:
TRUNCATE <schema>.<table>; -
Add the table back to the publication:
ALTER PUBLICATION <publication_name> ADD TABLE <schema>.<table>; -
Stop and restart Livesync to begin syncing the re-added table.
Restart everything
Section titled “Restart everything”Stop Livesync, drop the subscription, truncate all target tables, then restart the container.
Failing to truncate target tables leads to duplicate-key violation errors or duplicate records on the target.