Test Decoding Replication Setup

Test decoding is the longest running change tracking solution for PostgreSQL, and it can capture deletes which enables the soft delete function in DataLakeHouse.io.

Check to see if any logical replication slots already exist by running the command: select * from pg_catalog.pg_replication_slots;

There is almost always one default one called pghoard_local with a physical slot_type. If this is the only one that exist then you have NO logical replication slots yet.

Ensure that:

Replace the placeholders, schema name, etc. below with your actual values and record them for later references as you'll need them to setup the user that will have access to the database you will connect with in the DataLakeHouse.io connection info, for example we usually recommend the '' as 'datalakehouse_sync_svc':

as an example, to create a user with access to all tables:



Creating the logical replication slots require some basic configurations on the PostgreSQL server.

Adjust a few configurations: -- Set timeout to 30 mins SET statement_timeout = '1800';

Now create the actual logical replication slot, using specifically the name 'datalakehouseio_replication_slot': SELECT pg_create_logical_replication_slot('datalakehouseio_replication_slot', 'test_decoding');

Create a ROLE and Grant permissions to the user created previously,

Creating a logical replication slot has the ability to add options such as "include-xids" and "skip-empty-xacts". As of 12/1/2021, DataLakeHouse requires the Xids (the default), but does not concern over skip-empty-xacts, but we suggest that leaving the default settings as-is unless otherwise communicated by our support team. There are other not well-known options for test_decoding and wal2json which unless communicated by our support team should not be used.

Peeking at the logical changes are the easiest way to check if the logical replication is working and if to see if there are any tracked changes flowing through without actually changing the pointerlike when you use get_changes command:

Also, retrieve the change inacted as well, as this is the same logic that DataLakeHouse.io uses, SELECT * FROM pg_logical_slot_get_changes('datalakehouseio_replication_slot', null, null); which will move the pointer of the tracking forward and clear out the change records from the WAL thus removing the disk space previously consumed so the disk does not grow out of control.

In order to confirm that your logical replication is working, you can artificially create, or wait for, a DML activity of INSERT, UPDATE, DELETE.

Then run the above peek_changes command,

This will show the last received and last replayed WAL positions. If there is a delta (in Bytes) beteween pg_last_wal_receive_lsn and pg_last_wal_replay_lsn, then there is a lag then data is available typically.

To quickly shown any flush confirmations from using the get_changes:

Which will look similar to the following output

This table provides the basic information about the logic replication you have created. When DataLakeHouse.io is retrieving from the slot, the active colum will typically be set to "t" instead of "f" for true and false repsectively.

There are several parameters for working with the pg_logical_slot_peek_changes function as further described here, https://pgpedia.info/p/pg_logical_slot_peek_changes.html, for testing the flow of WAL changes as identifying the LSNs.

Is not leveraged by DataLakeHouse.io as this relates to a streaming replication standby replication instance, where DataLakeHouse.io is on-demand frequency sync scheduled query-based.

Aiven.io has a good article on standard operation increase in disk space due to WAL, https://developer.aiven.io/docs/products/postgresql/concepts/pg-disk-usage.html

Run any of the main postgreSQL commands to check disk space on the instance:

In a standard process where the DDL of your postgreSQL tables do not change much there is very little cause for failure other than not have a sync frequency that is not aligned with the volume of data your database tables produce commensurate with the disk space of the database/server. Since Logical Replication does not track DDL changes an error could occur if a DDL change is made but downstream impacts are not considered. In the case of DataLakeHouse.io a manual change may be required on your target system in order to reflect a DDL change on your source system.

When errors, if any occur, please report them immediately by opening up a support ticket. Methods used on your source database side to clear issues may include things such as using: