From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | github kran <githubkran(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PostGreSQL Replication and question on maintenance |
Date: | 2019-11-16 17:13:00 |
Message-ID: | CAMkU=1w3t-PO8OoBnZRVF4Y9v+MBO-WWfgL-E9LVxNKedcRdow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-sql |
On Thu, Nov 14, 2019 at 12:23 PM github kran <githubkran(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2019-11-16 17:22:40 | Re: Weird ranking results with ts_rank |
Previous Message | Pavel Stehule | 2019-11-16 15:57:34 | Re: Function performance degrades after repeated execution |
From | Date | Subject | |
---|---|---|---|
Next Message | Soto Cuevas Manuel Alejandro | 2019-11-20 12:12:21 | Re: PostGreSQL Replication and question on maintenance |
Previous Message | github kran | 2019-11-16 13:36:01 | Re: PostGreSQL Replication and question on maintenance |