I have two source databases and one target database.
I have setup pglogical replication between the two source dbs to the target db
source db1 -> replicates few tables to -> target db1
source db2 -> replicates few tables to -> target db1
After the initial setup, the subscription status is shown replicating and entire data is replicated. The replication is working fine from both databases.
However, when I perform a TRUNCATE CASCADE in one of the parent table in source db1 , the subscription status is changed from "replicating" to "down".
Then, if I drop the subscriber node and recreates it, the subscription will again start replicating.
Please let me know if pglogical has any know issue when TRANCATE CASCADE is performed at provider node.
Related
I am testing replication from Citus(Cloud Hosted) to my RDS Aurora Postgres with ref https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.Logical.html#AuroraPostgreSQL.Replication.Logical.Configure
Everything ran successful but on subscribers, no data is coming so what may be wrong? how do I troubleshoot
SELECT count(*) FROM LogicalReplicationTest;
Note: on Citus DB I can See Publication:
But in my RDS can't see Subscriptions in the list in spite of CREATE SUBSCRIPTION testsub CONNECTION was successful:
I observed that when I run SELECT count(*) FROM LogicalReplicationTest; there is no data but only column name showing Lock symbol as shown in this screenshot! any idea what this lock symbol means apart from the Read-only Column? why it's not listing data inside that table which is in publisher DB Is there any permission I have to delegate to the table when creating a publication?
I have two DB instances with postgresql 10.
First instance working with wal_level = logical, have ALL TABLE publisher. Second - have subscription to the publisher, described above.
All data from the Master DB tables are successfully sending to the replica.
There is only one issue for me - when my App add a new table on Master - I need to add the same table to the replica (and run REFRESH PUBLICATION).
My question - is there a way for replica DB to create new tables automatically?
Schema changes aren't replicated. You can see that in the documentation, at Postgresql 10 Logical Replication: Subscription
The way I handle this is to make all schema changes through a script, and to write the script so that it executes the change commands twice: once on the primary database, and once on the replica.
We are looking to use Postgres Logical Replication to move changes from an upstream server ("source" server) to a downstream server ("sink" server).
We run into issues when we simulate a disaster recovery scenario. In order to simulate this, we delete the source database while the replication is still active. We then bring up a new source database and try to: a) move data from the sink into the source, and b) set up replication. At this stage we get one of two errors, depending on when we set up the replication (before or after moving the data).
The errors we get after testing the above are one of the below:
Replication slot already in use, difficulty in re-enabling slot without deletion
LOG: logical replication apply worker for subscription "test_sub" has started
ERROR: could not start WAL streaming: ERROR: replication slot "test_sub" does not exist
LOG: worker process: logical replication worker for subscription 16467 (PID 205) exited with exit code 1
Tried amending using:
ALTER SUBSCRIPTION "test_sub" disable;
ALTER SUBSCRIPTION "test_sub" SET (slot_name = NONE);
DROP SUBSCRIPTION "test_sub";
Cannot create subscription due to PK conflicts
ERROR: duplicate key value violates unique constraint "test_pkey"
DETAIL: Key (id)=(701) already exists.
CONTEXT: COPY test, line 1
Some possible resolutions:
Have the Logical Replication set up after a given WAL record number. This might avoid the PK issues we are facing
Find a way to recreate the replication slot on the source database
Backup the Postgres server, including the replication slot, and re-import
Is this a well-catered for use case for Postgres Logical Replication? This is a typical disaster recovery scenario, so would like to know how best to implement. Thanks!
I have configured SQL Replication between two our two IBM DB2 databases ( database A and database B). The replication is working fine and all the data changes in one database are being replicated to the other database.
The issue I am facing is that if I add a new table in database A, then I have to manually add this table in Capture Control Server and Apply Control Server.
Even If I add a new column in a table for whom SQL Replication is already configured, I have to register that column in Capture Control Server and Apply Control Server.
Is there any way of replicating the schema changes automatically from one database to the other so that we don't have to manually add the new tables and columns in Capture Control Server and Apply Control Server for SQL Replication?
Regards,
Babar Hussain
I am using slony-I to replicate tables from one server to another. I have to databases on the master slave that have same exact tables , and i want to replicate them to a single table in the slave. I can create the same tables in different schemas in the slave table , however i cant determine the schema in the replication set in the slave host.
I want to be able to determine the schema i am replicating to on the slave host.
How can i do this in slony?
Thank you
Unfortunately you can't choose the schema on the slave host in slony.The schema name and table name should be identical on both the master and slave. A Work around for this thing is to create another schema on both databases on slave and master and use them in your slony replication