Tino, I did try mirroring the disk using 'dd' command and it took me a long time. At the end postgres did not start up.
I am sure I could probably get postgres working, but the db integrity not sure about that. Thank you very much for the input and offer Renato Renato Oliveira Systems Administrator e-mail: renato.olive...@grant.co.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: Dai, Tino [mailto:t...@loc.gov] Sent: 31 March 2010 03:08 To: Greg Smith; Renato Oliveira Cc: pgsql-admin@postgresql.org; Tino Schwarze Subject: RE: [ADMIN] Migrate postgres to newer hardware Hi Everybody, I'm not a dba. I'm a sysadmin by training. Is there some way to mirror the disks at the OS level? And then move it to the new machine. Just a though, I don't know the exact steps. But if you are interested, I can see what I can find. -Tino ________________________________________ From: pgsql-admin-ow...@postgresql.org [pgsql-admin-ow...@postgresql.org] On Behalf Of Greg Smith [g...@2ndquadrant.com] Sent: Tuesday, March 30, 2010 1:05 PM To: Dai, Tino; Renato Oliveira Cc: pgsql-admin@postgresql.org; Tino Schwarze Subject: Re: [ADMIN] Migrate postgres to newer hardware Renato Oliveira wrote: > Are there any commercial solutions out there for migrating large DBs? > I'm not aware of any. The main way to address this problem by throwing money at it is to hire someone extremely familiar with PostgreSQL replication technology and figure out how to customize one of the available approaches (Slony, Londiste, PITR, dump/restore) to match your application. For example, in some cases it's possible to record database changes on the application side, replicate the database via one of the fast online approaches like PITR, and then synchronize just the changes made in the master while that was happening for a fast switch-over to a new version. It's not unheard for that to require small application changes to support, to provide an easier way to log the difference between the two. If you can't take the additional load of Slony and have minimal tolerance for downtime, you really need to come up with a long-term approach to coping with that from an application architecture perspective. Unfortunately you're not going to find any quick fix for that combination of requirements. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.us -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.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 -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin