Logical replication 'possible' problem
Hi,
I'm in the process of doing the initial syncing of a subscriber with a
publisher.
There is only one table that is still in a 'dumping' state. It is quite a
large table and in previous executions it took several hours.
I'm not sure if it encountered a problem and stopped or if it is still
going.
Looking at the replication slots on the publisher I see this:
b2bcreditonline=> select slot_name, active, active_pid from
pg_replication_slots;
slot_name | active | active_pid
--------------------------------------------+--------+------------
b2bcreditonline_prod_b_master | t | 21511
b2bcreditonline_prod_b_shard | t | 21703
pg_67491625_sync_60067_7093664237039303581 | f |
(3 rows)
I assume the pg_xxxx slot is the one created for the initial copy but I'm
not sure if having a false active state is normal/ok.
If it is, great. If not, how do I determine the problem and go about fixing
it?
Thanks,
Steve
Sorry, I should have added the publisher is on 13.1 and the subscriber
14.2. Both are AWS RDS instances. I checked the log files for the publisher
and subscriber and couldn't see any logical replication errors. The
publisher is a busy DB though so if there are any errors there, I may have
missed them.
Thanks.
On Wed, May 4, 2022 at 1:50 PM Steve Baldwin <steve.baldwin@gmail.com>
wrote:
Show quoted text
Hi,
I'm in the process of doing the initial syncing of a subscriber with a
publisher.There is only one table that is still in a 'dumping' state. It is quite a
large table and in previous executions it took several hours.I'm not sure if it encountered a problem and stopped or if it is still
going.Looking at the replication slots on the publisher I see this:
b2bcreditonline=> select slot_name, active, active_pid from
pg_replication_slots;
slot_name | active | active_pid
--------------------------------------------+--------+------------
b2bcreditonline_prod_b_master | t | 21511
b2bcreditonline_prod_b_shard | t | 21703
pg_67491625_sync_60067_7093664237039303581 | f |
(3 rows)I assume the pg_xxxx slot is the one created for the initial copy but I'm
not sure if having a false active state is normal/ok.If it is, great. If not, how do I determine the problem and go about
fixing it?Thanks,
Steve
The logical replication dump of the table I thought was 'stuck' eventually
completed after 6+ hours. I guess the replication slot showing active as
false is to be expected. I never noticed it before.
So there never was an issue - apart from my ignorance. Sorry for the noise.
Cheers,
Steve
On Wed, May 4, 2022 at 1:54 PM Steve Baldwin <steve.baldwin@gmail.com>
wrote:
Show quoted text
Sorry, I should have added the publisher is on 13.1 and the subscriber
14.2. Both are AWS RDS instances. I checked the log files for the publisher
and subscriber and couldn't see any logical replication errors. The
publisher is a busy DB though so if there are any errors there, I may have
missed them.Thanks.
On Wed, May 4, 2022 at 1:50 PM Steve Baldwin <steve.baldwin@gmail.com>
wrote:Hi,
I'm in the process of doing the initial syncing of a subscriber with a
publisher.There is only one table that is still in a 'dumping' state. It is quite a
large table and in previous executions it took several hours.I'm not sure if it encountered a problem and stopped or if it is still
going.Looking at the replication slots on the publisher I see this:
b2bcreditonline=> select slot_name, active, active_pid from
pg_replication_slots;
slot_name | active | active_pid
--------------------------------------------+--------+------------
b2bcreditonline_prod_b_master | t | 21511
b2bcreditonline_prod_b_shard | t | 21703
pg_67491625_sync_60067_7093664237039303581 | f |
(3 rows)I assume the pg_xxxx slot is the one created for the initial copy but I'm
not sure if having a false active state is normal/ok.If it is, great. If not, how do I determine the problem and go about
fixing it?Thanks,
Steve