Re: PITR clarification to certain points

Guys,

Something I forgotten to point out.
When you do a base backup, you have also the configuration file from the Primary, which means you will have it configured to archive as well on the WARM server, once you restored it.
So, my guess is I must turn off the archiving process on the WARM? This is what I have done!
I have not seen any mention of this in any documentation so far.

Is that correct?

Thank you

Renato

Renato Oliveira
Systems Administrator
e-mail: renato(dot)oliveira(at)grant(dot)co(dot)uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

-----Original Message-----

From: pgsql-admin-owner(at)postgresql(dot)org [mailto:pgsql-admin-owner(at)postgresql(dot)org] On Behalf Of Renato Oliveira
Sent: 02 February 2010 10:12
To: pgsql-admin(at)postgresql(dot)org
Subject: [ADMIN] PITR clarification to certain points
Importance: High

Dear all,

I apologise for this post in advance, I am sure some of you have already answered many question and maybe find it boring by now.

I have been playing with PITR for some time now and read quite a bit about it, it is nice feature. I am really enjoying playing with it.

I have managed to get it working on my test environment, but I have few things I would like mention here in the list and if someone could clarify them to me, please it would be very much appreciated.

The Archiving process is very simple and straight and forward
Main Server
1 - You setup postgreSQL
2 - you initialise the cluster: initdb -D /var/lib/pgsql/data
3 - Edit /var/lib/pgsql/data/postgresql.conf and add:
archive_mode = on
archive_command = 'cp %p /data/pitr/%f'
archive_timeout = 600
4 - mkdir /data/pitr; chown postgres: /data/pitr
5 - service postgresql start
6 - select pg_start_backup('/data/pitr');
7 - tar -zcvf data.pitr.tar.gz /var/lib/pgsql/data
8 - select pg_stop_backup();

Everything as far as can think is done for the Primary server, I can see it starts working, as soon as I add some data the logs start being archived.

The restore process is not so straight and forward and some it lacks some necessary info I think

On the StandBy
1 - Install PostgreSQL
2 - initd -D /var/lib/pgsql/data
3 - mv data data.old
4 - tar -zxvf data.pitr.tar.gz
5 - Create a file recovery.conf ad add the following lines:
restore_command = 'cp /data/pitr/%f %p'
NOTE if I turn the server on the file recovery.conf is automatically renamed to recovery.done and no data other than the original base backup is restored. It does not read the longs copied to /data/pitr and restores them, why do you guys think is that?

Then I tried a single server test.

On the Primary Postgre I did.
1 - Killed postgres
2 - moved data to data.afterPITR
3 - restored the base backup
4 - deleted /var/lib/pgsql/data/pg_xlog/* files
5 - deleted /var/lib/pgsql/data/pg_log/*, deleleted PID file
6 - copied /var/lib/pgsql/ data.afterPITR/pg_xlog to /var/lib/pgsql/data/pg_log/
7 - created the recovery.conf added:
restore_command = 'cp /data/pitr/%f %p'
8 - service start postgresql

Then it worked it did restore to the point I was expecting.

So, this brings me to the following questions:
1 - Do I need to leave the server in recovery mode off, I mean postgresql not running?
2 - Everytime a disaster strikes, do I need to go back to the base backup and restore it to the StandBY server?
3 - If point 2 is true, then I would need to do a base backup the other way round, for example:
* when primary goes down and I bring the secondary as master fromn the recovery process, I need to do a base backup on the secondary which is now the primary?
* then when I am restoring the old Primary I need to do the inverse process to make it a WARM server?
4 - Which logs really do I need to clean only pg_xlog?
5 - Do I need to copy the old logs from the crashed server from /data/pg_xlog to the new master? What about if it has crashed and I can't get anything out of it? IS it a 'must' those logs or it is only in case you want to recover to the last minute before it crashed?
6 - Why does it renames the recovery.conf? I thought it would be a continuous process?
I mean I thought the WARM server would be there reading the logs until I tell it otherwise.

Guys I thank all of you in advance for this.

If someone could clarify a bit to me it would be very much appreciated.

Thank you very much

Best regards

Renato

Renato Oliveira
Systems Administrator
e-mail: renato(dot)oliveira(at)grant(dot)co(dot)uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
http://www.grant.co.uk/

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).

OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our http://www.grant.co.uk/Support/openxml.html

--
Sent via pgsql-admin mailing list (pgsql-admin(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

-----Original Message-----

P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).

OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our http://www.grant.co.uk/Support/openxml.html