Standalone synchronous master
От | Alexander Björnhagen |
---|---|
Тема | Standalone synchronous master |
Дата | |
Msg-id | CAO-C5=ka8Sd6ZRqCeJReEBGHe=Oe7=7jFabiH1p6Di17eMYqMw@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: Standalone synchronous master
|
Список | pgsql-hackers |
Hi all, I’m new here so maybe someone else already has this in the works ? Anyway, proposed change/patch : Add a new parameter : synchronous_standalone_master = on | off To control whether a master configured with synchronous_commit = on is allowed to stop waiting for standby WAL sync when all synchronous standby WAL senders are disconnected. Current behavior is that the master waits indefinitely until a synchronous standby becomes available or until synchronous_commit is disabled manually. This would still be the default, so synchronous_standalone_master defaults to off. Previously discussed here : http://archives.postgresql.org/pgsql-hackers/2010-10/msg01009.php I’m attaching a working patch against master/HEAD and I hope the spirit of christmas will make you see kindly on my attempt :) or something ... It works fine and I added some extra logging so that it would be possible to follow more easily from an admins point of view. It looks like this when starting the primary server with synchronous_standalone_master = on : $ ./postgres LOG: database system was shut down at 2011-12-25 20:27:13 CET <-- No standby is connected at startup LOG: not waiting for standby synchronization LOG: autovacuum launcher started LOG: database system is ready to accept connections <-- First sync standby connects here so switch to sync mode LOG: standby "tx0113" is now the synchronous standby with priority 1 LOG: waiting for standby synchronization <-- standby wal receiver on the standby is killed (SIGKILL) LOG: unexpected EOF on standby connection LOG: not waiting for standby synchronization <-- restart standby so that it connects again LOG: standby "tx0113" is now the synchronous standby with priority 1 LOG: waiting for standby synchronization <-- standby wal receiver is first stopped (SIGSTOP) to make sure we have outstanding waits in the primary, then killed (SIGKILL) LOG: could not receive data from client: Connection reset by peer LOG: unexpected EOF on standby connection LOG: not waiting for standby synchronization <-- client now finally receives commit ACK that was hanging due to the SIGSTOP:ed wal receiver on the standby node And so on ... any comments are welcome :) Thanks and cheers, /A
Вложения
В списке pgsql-hackers по дате отправления: