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.oliveira@xxxxxxxxxxx
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@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
