Thanks Jeff for your reply. We are not using replication concept here but doing the data copy using few custom sql scripts. We had our PostgreSQL engine supported by AWS and the instance was restarted automatically based on the AWS design of PostgreSQL engine. Replica is restarted automatically when the data sync is behind the master.
My intension is to bring to this forum and see if this is expected based on the use case what I mentioned. I love this community and advices the community has for various problems. i still need to find out how can I do this using replication. Please provide me few resources if there is a better solution for this problem.
When the migration activity runs(weekly) from past 2 times , we saw the cluster read replica instance has restarted as it fallen behind the master(writer instance).
I can't figure out what your setup is here. You must be using logical replication (not physical) or you wouldn't be able to write to the replica at all. But if you are using logical replication, why do you also need these weekly jobs? Why isn't logical replication taking care of it?
Everything
after that worked seamlessly but we want to avoid the replica getting restarted. To avoid from restart we started doing smaller binary files and copy those files to the cluster-2
Who restarted it? I am not aware of any case where the replica responds to falling behind by restarting itself. With physical replication, it can start cancelling queries, but you don't seem to be using physical replication.
