|
Description
|
The World's Most Advanced Open Source Relational Database
|
|
Type
|
Write-ahead log (WAL) Replication
|
|
Supported Replication
|
Initial Sync
Continuous Sync
|
|
Authentication Type
|
Password Authentication
|
Setting up PostgreSQL CDC for ELT & CDC
ELT & CDC uses WAL based logical replication - pgoutputdecoding for PostgreSQL database source and requires a user with LOGIN and REPLICATION role.
Supported providers
Requirements
- PostgreSQL versions 10.x or above.
- Database user with CREATE permission on the schema and database to be synced.
- Tables with PRIMARY KEY .
- Sync user should be the OWNER of the tables.
- The ownership requirement is for adding the tables to the PUBLICATION that we create in order for receiving replication events from the database. For more info, click here.
- Master instances of Postgres (log based replication only works for master instances).
Features
|
|
Supported |
Notes |
| Full (Historical) sync |
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
| UPSERT |
Yes |
|
|
|
Yes |
Can be specified at a table level
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
|
|
|
Yes |
Supported on AWS |
Heartbeat
PostgreSQL uses the confirmed_flush_lsn to determine which WAL segments can be safely removed, so if it's not updated because the tables in your publication aren't changing, the WAL storage can indeed grow significantly.
To ensure that the confirmed_flush_lsn advances even when there are no transactions for the selected tables, we created a heartbeat table, insert a single record and update it every 10 minutes while the pipeline is running.
create table if not exists <pipeline schema>.integrateio_heartbeat ( last_heartbeat timestamptz primary key);
This table will not be replicated to your destination and the updates will not count towards your usage.
Frequently Asked Questions (FAQs)
Q: How do you handle Postgres replication slots?
A: We create a replication slot when the initial sync starts. After the initial sync completes, we start listening for changes from it. Once a pipeline is deleted or archived by you, we try to remove the replication slot from your Postgres DB provided that we can still access it.
Q: How do you handle large JSONB objects?
A: Large JSONB objects are mapped as TEXT/VARCHAR/STRING columns and might be truncated (depending on destination). Note about the TOAST table - if there are tables which use the toast tables (usually tables with huge JSONB or TEXT columns) then their REPLICA IDENTITY (https://www.postgresql.org/docs/10/sql-altertable.html#SQL-CREATETABLE-REPLICA-IDENTITY) needs to be set to FULL for us to properly sync the data in case of continuous sync.