Re: Archiving and recovering pg_stat_tmp - Mailing list pgsql-general
From | Amit Langote |
---|---|
Subject | Re: Archiving and recovering pg_stat_tmp |
Date | |
Msg-id | CA+HiwqGLMH4uJ1hroC+TcEe1sZvNv8NzgZ6D234dR=hV2cF5Uw@mail.gmail.com Whole thread Raw |
In response to | Re: Archiving and recovering pg_stat_tmp (Sameer Thakur <samthakur74@gmail.com>) |
Responses |
Re: Archiving and recovering pg_stat_tmp
|
List | pgsql-general |
On Fri, Jun 21, 2013 at 2:44 PM, Sameer Thakur <samthakur74@gmail.com> wrote: > >> >"You need to have statistics recovered to the same state as they were >> >when you took the FS level backup of your database after shutting down >> >the server." > > Correct >> >> >> >"Shutting down" is important since that is when you would have >> >statistics files ($PGDATA/pg_stat/*.stat) available to backup. They >> >capture the statistics as of when the server was shut down. >> Agreed > > > >What I did: >> >> >> >1) Collect a few statistics in a result file from a currently running >> >server. For example, the result of the query "select * from >> >pg_stat_user_tables", into say stats1.txt >> >> >2) Clean shut down the server. Take a snapshot of the data directory, >> >"cp -r $pgdata $pgbkp" >> >> >3) Start the server and run a few pgbench tests so that statistics >> >change. Again collect stats, same as in (1) into say stats2.txt >> >> >4) Write $pgbkp/recovery.conf with appropriate restore_command and >> >maybe recovery target (PITR), which I did not, though. Note that we >> >have archiving enabled. >> >> >5) Start the server using -D $pgbkp (may be with port changed for the >> >sake of testing). >> >> >6) After server started in (5) is done recovering and comes online, >> >collect stats again into say stats3.txt >> >> >7) Compare stats3.txt with stats1.txt and stats2.txt. >> >> >8) I observed that stats3.txt == stats1.txt. That is stats after >> >recovery are same as they were when the snapshot was taken. >> >> Thank you for all the effort! A question > > When server was restarted in (5) which stats file was loaded stats1.txt or > stats.2.txt?. I think it must have been stats1.txt as stats3.txt = > stats1.txt. What happens if stats2.txt is loaded on (5) instead on > stats1.txt? I am trying to figure out if the Server will reject stats file > from a different timeline than the one its been rolled back to. I started the server in step (5) using the back up directory. And remember backup directory would contain stats as they are in stats1.txt. So, there wasn't a possibility of stats as they are in stats2.txt to be loaded. But, if you do PITR using the same directory (which I haven't), I think you would need to somehow replace the stats with the ones you want, may be from your backup of the same (that is, of pg_stat/*.stat), though I am not sure if that would be correct. I doubt if WAL replay (as in a consistent recovery mechanism :-) ) accounts for the stats. I guess stats are not WAL logged (like changes to table data) since they are managed using temporary files in pg_stat_temp and hence may not be recoverable using WAL replay to a particular state using PITR. but I may be wrong. Thoughts? -- Amit Langote
pgsql-general by date: