Closed salieflewis closed 1 month ago
Thanks for reaching out and glad you are finding this useful. As long as you haven't called switchover
or stop_sync
the subscription stays in tact and Postgres will continue to logically replicate the data on the tables as it comes.
Is that what you meant by persistent connection or something else?
I'd also recommend following the stats from time to time to ensure the subscription is healthy and there are no dead replication slots. Happy to look into health
or similar cli status if that would make it useful.
Thanks for reaching out and glad you are finding this useful. As long as you haven't called
switchover
orstop_sync
the subscription stays in tact and Postgres will continue to logically replicate the data on the tables as it comes.Is that what you meant by persistent connection or something else?
I'd also recommend following the stats from time to time to ensure the subscription is healthy and there are no dead replication slots. Happy to look into
health
or similar cli status if that would make it useful.
Ok amazing! And thank you for the tip. I think the log reads that the container died, is it triggered to restart by incoming data? I'm relatively new to the behavior of containers so please bare with me.
The only other annoying process with this was that I was unable to use the copy schema functionality due to incompatible versions with pg_dump.
I think the log reads that the container died, is it triggered to restart by incoming data? I'
That is expected since the container commands are meant to be one-off, the actual replication is carried about Postgres and not pg_easy_replicate it self. pg_easy_replicate does all the setup and orchestration, so you won't have to run all the manual sql commands etc
The only other annoying process with this was that I was unable to use the copy schema functionality due to incompatible versions with pg_dump.
interesting, what were the versions?
Ok, I think I understand. I am running into the issue right now where the replication seems to have stopped. It works in the sense that I can see the data from the publisher present in the subscriber, but upon adding new data it doesn't look like the subscriber is picking it up. Would I see the SQL commands being executed in the logs of the container?
"message_lsn_receipts": [
{
"received_lsn": "0/1A2DC28",
"last_msg_send_time": "2024-06-28 19:04:07 UTC",
"last_msg_receipt_time": "2024-06-28 19:04:07 UTC",
"latest_end_lsn": "0/1A2DC28",
"latest_end_time": "2024-06-28 19:04:07 UTC"
}
]
Re: pg_dump
I believe by default Railway uses Postgres v16 and pg_dump
is configured for v15.
EDIT: Think the error I'm running into is because max_wal_senders
and max_replication_slots
have been inappropriately configured on the subscriber.
ah! i see, is there any info on the replication slots and other info in the status, wonder if they are healthy or not.
Yeah, re: max_replication_slots
and max_wal_senders
, they should be at least the same, unless there are physical replication so max_wal_senders
should be higher. same for max_logical_replication_workers
I wonder if we could extend the config
check to also print some recommendation, in addition to docs.
Closing, but happy to help assist if anything comes up. Thanks!
I've successfully synced my databases using this tool on Railway. Just wanted to make sure that I can indeed use this tool to establish a persistent connection. For instance, new data gets created in the publisher and synced to the subscriber automatically. Is this tool designed to handle this?