From: | Armand du Plessis <adp(at)bank(dot)io> |
---|---|
To: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Least intrusive way to move primary data |
Date: | 2013-05-30 08:58:10 |
Message-ID: | CANf99sW9zp3e10S1NdaYOywF_J36e4hQ_710-ka2X99Dk80ohQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
We're looking into options for the least intrusive way of moving our
pg_data onto faster storage. The basic setup is as follows :
6 disk RAID-0 array of EBS volumes used for primary data storage
2 disk RAID-0 array of EBS volumes used for transaction logs
RAID arrays are xfs
It's the primary data volumes we'd like to switch onto a faster RAID array.
The options I'm looking at are the following:
- Setup new slave on similar hardware, do a normal master -> slave
failover when it's ready. Upside, minimal downtime. Downside, quite a lot
of work for something that's essentially just a copy of data
- rsync the data storage to new RAID-0 array. stop Postgres. rsync again
to apply changes. Change mount points and restart Postgres. Longer downtime
but seems to be the most straight forward.
- Go the full route of stopping Postgres, make consistent snapshots of
all the volumes and recreate a new RAID-0 array from them and restarting.
https://github.com/alestic/ec2-consistent-snapshot
The rsync route sounds like the most straight-forward option, however I'm a
little worried about it's consistency on a busy filesystem despite it being
stopped when the second sync happens.
Scripting the snapshotting, and reassembling of the RAID array sounds like
the most reliable way of doing it and possibly the quickest as well.
Any pitfalls, gotchas or suggestions for making the switch?
Kind regards,
Armand
From | Date | Subject | |
---|---|---|---|
Next Message | prakhar jauhari | 2013-05-30 09:17:34 | Standby doesn't chose a new timeline when promoted to master |
Previous Message | aarti sawant | 2013-05-30 08:49:23 | Migration and snapshot of database |