Re: Streaming-only Remastering
| От | Josh Berkus |
|---|---|
| Тема | Re: Streaming-only Remastering |
| Дата | |
| Msg-id | 4FDE364D.2030403@agliodbs.com обсуждение исходный текст |
| Ответ на | Re: Streaming-only Remastering (Simon Riggs <simon@2ndQuadrant.com>) |
| Список | pgsql-hackers |
Simon, > The "major limitation" was solved by repmgr close to 2 years ago now. > So while you're correct that the patch to fix that assumed that > archiving worked as well, it has been possible to operate happily > without it. repmgr is not able to remaster using only streaming replication. It also requires an SSH connection, as well as a bunch of other administative setup (and compiling from source on most platforms, a not at all insignificant obstacle). So you haven't solved the problem, you've just provided a somewhat less awkward packaged workaround. It's certainly possible to devise all kinds of workarounds for the problem; I have a few myself in Bash and Python. What I want is to stop using workarounds. Without the requirement for archiving, PostgreSQL binary replication is almost ideally simple to set up and administer. Turn settings on in server A and Server B, run pg_basebackup and you're replicating. It's like 4 steps, all but one of which can be scripted through puppet. However, the moment you add log-shipping to the mix things get an order of magnitude more complicated, repmgr or not. There's really only too things standing in the way of binary replication being completely developer-friendly. Remastering is the big one, and the separate recovery.conf is the small one. We can fix both. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-hackers по дате отправления: