Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2

>
> ...
>
> You can actually reduce the time more by pre-syncing to the new location.
> something like:
>
> rsync -va /var/lib/pgsql/ /var/lib/pgsql2/
> service postgres stop
> rsync -va /var/lib/pgsql/ /var/lib/pgsql2/
>
> The second rsync will only copy the deltas from the first, it still has to
> go in and determine what needs to be copied/what changed but the bulk of it
> can be prepared/migrated before the actual downtime window.
>
>
>
The benefit of an initial and final rsync will depend on how many files
change. Rsync's default when copying between local paths is to use the
--whole-file option so at least it won't busy itself reading and comparing
the source and destination files which is worse than simply copying the
entire thing but you will only save the time associated with those files
that have unchanged modification time and size between the first and second
rsync. If the initial rsync takes, say, a half hour it is potentially
beneficial to run a second or even additional preliminary rsync runs as
each additional run should be faster due to less time for files to change
during the rsync. You will have to test for your specific case.

If you *really* want to do a fast switch and your configuration disk
configuration supports it you could possibly play games with using
single-machine DBRD or LVM RAID to live-sync the old and new directories.
Of course it's equally possible that the setup involved to do this will
involve more initial downtime than just copying the files.

Another possibility is to set up an additional slave instance of PostgreSQL
on your master machine then cut over to that instance. I haven't though
through the issue of bringing up your actual slave servers after the
cutover. I suspect in the worse case you would have your current master
instance, your replica instance running on the master server and using the
new SSD then migrate the slave servers to cascade off the master server's
replica instance. When all is synched up, promote the master server replica
instance to a master and kill off the original master instance.

As always in these instance, testing and practice is mandatory.

Cheers,
Steve