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. Thanks githubkran On Sat, Nov 16, 2019 at 11:13 AM Jeff Janes <jeff.ja...@gmail.com> wrote: > On Thu, Nov 14, 2019 at 12:23 PM github kran <githubk...@gmail.com> wrote: > >> >>> >>> *Problem what we have right now. * >>> >>> 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. > > Cheers, > > Jeff > >>
