[pgpool-general: 3481] Re: failover on write failure (no disk space left)?

Aistis Zen aistis+pgpool at gmail.com
Sat Feb 21 01:41:19 JST 2015


Interesting. I let it fail for several minutes and then stopped the test.
Will leave it for a bit longer, just in case it makes up its mind.

On a second thought, perhaps it would be possible to instruct PostgreSQL to
shoot itself if it can't write to a filesystem. This would surely trigger a
failover. I haven't looked at this option yet.

Aistis


On Fri, Feb 20, 2015 at 6:33 PM, Michel Kirstein <kirstein at tuhh.de> wrote:

> I'm testing pgpool with 3 nodes in replication mode (not streaming
> replication) and had a degeneration because i let one node run full with
> log files on purpose. I don't think i still have the log files of that
> event but i could check my documentation on monday.
> If i remember correctly the error message was the same.
>
> It just might be that "replication_stop_on_mismatch" was the option that
> triggered the failover in my setup.
>
> Am 20.02.2015 um 17:16 schrieb Aistis Zen:
>
>  Dear Michael
>>
>> well, I have this on, but if we read the comment there, it doesn't look
>> like it's designed for this case:
>>
>> # Initiates failover when reading/writing to the
>> # backend communication socket fails
>> # If set to off, pgpool will report an
>> # error and disconnect the session.
>>
>> In case of the disk space issue, we still got our socket alive and
>> communication does happen with a backend.
>>
>> On Fri, Feb 20, 2015 at 5:47 PM, Michel Kirstein <kirstein at tuhh.de>
>> wrote:
>>
>>  Hi Aistis,
>>> as i see, it the option "fail_over_on_backend_error" does enable what
>>> you're looking for.
>>> By default it's set to false and pgpool does just "report an error and
>>> disconnect the session".
>>> I think health_check does only check if the node is still alive and
>>> replies to a simple select.
>>>
>>> Am 20.02.2015 um 16:15 schrieb Aistis Zen:
>>>
>>>  Hello
>>>>
>>>> I managed to go past failover scenarios with introduction of failback
>>>> scripts. All the "normal" tests like failover and failback are working,
>>>> so
>>>> I went further and tested out-of-order scenario with the master suddenly
>>>> not having enough disk space. What happened is.. nothing. My script
>>>> keeps
>>>> on trying to write and pgpool reporting:
>>>>
>>>> Feb 20 17:02:47 slave pgpool[16626]: DB node id: 1 backend pid: 17243
>>>> statement: BEGIN
>>>> Feb 20 17:02:47 slave pgpool[16626]: DB node id: 0 backend pid: 3689
>>>> statement: INSERT into demo.test(uid) values(37501);
>>>> Feb 20 17:02:47 slave pgpool[16626]: pool_send_and_wait: Error or notice
>>>> message from backend: : DB node id: 0 backend pid: 3689 statement:
>>>> INSERT
>>>> into demo.test(uid) values(37501); message: could not extend file
>>>> "base/24675/24681": No space left on device
>>>>
>>>> Shouldn't it assume that the backend has an issue and initiate a
>>>> failover
>>>> in this case? Is there anything to be configured in pgpool, which could
>>>> catch such exception? I know it does SELECT's to check availability, but
>>>> it
>>>> doesn't seem to care if the master database is no longer writable.
>>>>
>>>>
>>>> Thank you!
>>>> Aistis
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> pgpool-general mailing list
>>>> pgpool-general at pgpool.net
>>>> http://www.pgpool.net/mailman/listinfo/pgpool-general
>>>>
>>>>   _______________________________________________
>>>>
>>> pgpool-general mailing list
>>> pgpool-general at pgpool.net
>>> http://www.pgpool.net/mailman/listinfo/pgpool-general
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20150220/4d95af70/attachment-0001.html>


More information about the pgpool-general mailing list