- Documentation
RDS for PostgreSQL
Troubleshooting
How to troubleshoot and resolve inactive logical replication slots in an instance
Troubleshooting
How to troubleshoot and resolve inactive logical replication slots in an instance
How to troubleshoot and resolve inactive logical replication slots in an instance
Problem description
When there are too many inactive logical replication slots due to not being cleaned up in time, WAL logs will continue to accumulate, occupying a large amount of storage space, and may even fill up the disk, causing the instance to be locked and unable to write data, thus affecting the business. In business, promptly clean up replication slots that are no longer needed.
Troubleshooting approach
You can troubleshoot and handle inactive logical replication slots in the database according to the following approach:
- Check whether there are invalid logical replication slots.
- The business confirms whether the logical replication slot needs to continue to be used.
- Delete the invalid logical replication slot.
Solutions
- Confirm whether there are inactive logical replication slots in the instance. This can be determined in two ways:
- View the replication slot list in RDS for PostgreSQL console to confirm whether there are inactive logical replication slots. For detailed information about viewing the replication slot list, see Viewing replication slot list.
- Call Open API DescribeSlots to query the replication slots under the instance. If the SlotStatus field returns INACTIVE and the SlotType field returns logical, it indicates there are inactive logical replication slots under the instance. The SlotName field is the name of the replication slot.
- Contact the business party to check whether to continue to use the logical replication slot.
- If it is no longer used, execute step 3 to delete the replication slot.
- If continued use is needed and PostgreSQL's subscription feature is used, troubleshooting can proceed in the following direction:
- Replication of the logical replication slot was not enabled when creating the subscription on the subscriber side and was manually set to the Disabled state. Execute the following SQL on the subscription side to view the field return of the subenabled column.
select subname,subenabled from pg_subscription;
- If the field return of the subenabled column isf, it indicates that the subscription has Disabled logical replication. Execute the following SQL to enable logical replication for the subscription.
ALTER SUBSCRIPTION sub_name ENABLE;
- If the field return of the subenabled column ist, continue troubleshooting according to the following steps.
- The logical replication slot used when executing tasks using other tools is not automatically cleaned up due to task interruption or certain operations on the source or target database, such as backup, rebuilding indexes, and other unexpected situations.
- Query through the RDS for PostgreSQL console on the publishing side and check whether the returned "Slot name" field value starts with _volc_dts_logical_replica_. If so, it means the logical replication slot was generated by executing the DTS task. At this point, according to the task situation, decide whether to execute step 3 to clean the replication slot.
- Delete the invalid logical replication slot. There are two ways to delete the replication slot:
- Delete the replication slot in the replication slot list of RDS for PostgreSQL console. For detailed information about deleting replication slots, see Deleting replication slot.
- Call Open API DeleteSlot to delete the replication slot under the instance. Call the Open API [DeleteSlot](https://www.volcengine.com/docs/6438/1323548) to delete the replication slot under the instance. Specify the ID of the instance to which the replication slot belongs in the request parameter InstanceId, and specify the name of the replication slot to be deleted in the request parameter SlotName.
recommendations for reducing business impact
- In business, promptly clean up replication slots that are no longer needed.
- RDS for PostgreSQL provides two monitoring items for replication slots: Inactive transactions and Maximum WAL log accumulation in replication slots. Creating alarm policies for these two monitoring items can promptly detect inactive replication slots and storage space occupied by replication slots. For more information about creating alert policies, refer to Creating alarm strategy.
Last updated: 2025.11.17 16:15:13