Re: pg_upgrade and rsync
От | Jim Nasby |
---|---|
Тема | Re: pg_upgrade and rsync |
Дата | |
Msg-id | 54C6BB7C.1000408@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: pg_upgrade and rsync (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: pg_upgrade and rsync
Re: pg_upgrade and rsync |
Список | pgsql-hackers |
On 1/23/15 12:40 PM, Stephen Frost wrote: >> >That said, the whole timestamp race condition in rsync gives me the heebie-jeebies. For normal workloads maybe it's notthat big a deal, but when dealing with fixed-size data (ie: Postgres blocks)? Eww. > The race condition is a problem for pg_start/stop_backup and friends. > In this instance, everything will be shut down when the rsync is > running, so there isn't a timestamp race condition to worry about. Yeah, I'm more concerned about people that use rsync to take base backups. Do we need to explicitly advise against that?Is there a way to work around this with a sleep after pg_start_backup to make sure all timestamps must be different?(Admittedly I haven't fully wrapped my head around this yet.) >> >How horribly difficult would it be to allow pg_upgrade to operate on multiple servers? Could we have it create a shellscript instead of directly modifying things itself? Or perhaps some custom "command file" that could then be replayedby pg_upgrade on another server? Of course, that's assuming that replicas are compatible enough with masters forthat to work... > Yeah, I had suggested that to Bruce also, but it's not clear why that > would be any different from an rsync --size-only in the end, presuming > everything went according to plan. Yeah, if everything is shut down maybe we're OK. -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: