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

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