It's infuriating that the only mention of this seemingly crucial piece of configuration is in the release notes from a major version ago...
Added a write-ahead log (WAL) heartbeat (that is, running dummy queries) for replication from a PostgreSQL source. This feature was added so that idle logical replication slots don't hold onto old WAL logs, which can result in storage full situations on the source. This heartbeat keeps restart_lsn moving and prevents storage full scenarios.
I'm using DMS to CDC data from RDS (postgres) to Redshift. The heartbeat interval is currently set to the default of 5 minutes.
The RDS instance is experiencing a heavy (for us) write load. As a result, we are accumulating transaction logs at an increased rate.
I'm noticing a sawtooth pattern for transaction log disk usage on RDS. Peculiarly, the sawtooth seems to be on a 5 minute interval (matching the interval?).
I had an RDS instance run out of disk when testing because it was sitting "idle", building replication log.
The heartbeat setting seemed to have resolved this problem when testing. However, in production, due to the 5 min jaggedness, I'm wondering if Postgres is holding onto WAL longer than it actually needs to as a result of the heartbeat...