Re: Hot Backup with rsync fails at pg_clog if under load
От | Robert Haas |
---|---|
Тема | Re: Hot Backup with rsync fails at pg_clog if under load |
Дата | |
Msg-id | CA+TgmoYBP-hxL+b3dzFq=9NRLkMMAKAxCn5NXjggask+_Ka5bw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hot Backup with rsync fails at pg_clog if under load (Euler Taveira de Oliveira <euler@timbira.com>) |
Ответы |
Re: Hot Backup with rsync fails at pg_clog if under load
|
Список | pgsql-hackers |
On Wed, Sep 21, 2011 at 12:22 PM, Euler Taveira de Oliveira <euler@timbira.com> wrote: > [This question doesn't belong to -hackers. Please post it in -general or > -admin] -hackers or -bugs seems appropriate to me; I think this is a bug. >> 2.2. pg_start_backup(Obackup_under_loadš) on the master (this will take a >> while as master is loaded up); > > No. if you use pg_start_backup('foo', true) it will be fast. Check the > manual. If the server is sufficiently heavily loaded that a checkpoint takes a nontrivial amount of time, the OP is correct that this will be not fast, regardless of whether you choose to force an immediate checkpoint. >> 2.3. rsync data/global/pg_control to the standby; > > Why are you doing this? If ... > >> 2.4. rsync all other data/ (without pg_xlog) to the standby; > > you will copy it again or no? Don't understand your point. His point is that exercising the bug depends on doing the copying in a certain order. Any order of copying the data theoretically ought to be OK, as long as it's all between starting the backup and stopping the backup, but apparently it isn't. > The problem could be that the minimum recovery point (step 2.3) is different > from the end of rsync if you are under load. It seems pretty clear that some relevant chunk of WAL isn't getting replayed, but it's not at all clear to me why not. It seems like it would be useful to compare the LSN returned by pg_start_backup() with the location at which replay begins when you fire up the clone. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: