Обсуждение: Migrating to a WAL-shipped replication cluster
Happy Friday,
I'm migrating a set of data, about 16G of SQL-dump (-F plain), to a postgresql instance with WAL shipping backups. My plan is to do this in subsets of data, as there some work that has to be done with the dump before it is moved over. Let's assume 8 chunks ranging from 1G to 4G in size, where I'm able to do about 1 chunk an hour.
Should I set up WAL shipping replication at the beginning and count on it to replicate the data inserted by the restore? Or should I stop WAL shipping before each chunk and then rebase the backups? Part of me thinks that the WAL shipping will choke on this volume. On the other hand, rebasing will have to move a larger volume of data across the wire. What I really care about is the time between restoring the data and the backups being caught up.
Obviously I'll do some dry-runs to figure out exactly what the process will feel like, but I'm trying to get a head start on understanding areas of low-redundancy during this migration so that I can minimize them.
Thanks,
Derrick
I'm migrating a set of data, about 16G of SQL-dump (-F plain), to a postgresql instance with WAL shipping backups. My plan is to do this in subsets of data, as there some work that has to be done with the dump before it is moved over. Let's assume 8 chunks ranging from 1G to 4G in size, where I'm able to do about 1 chunk an hour.
Should I set up WAL shipping replication at the beginning and count on it to replicate the data inserted by the restore? Or should I stop WAL shipping before each chunk and then rebase the backups? Part of me thinks that the WAL shipping will choke on this volume. On the other hand, rebasing will have to move a larger volume of data across the wire. What I really care about is the time between restoring the data and the backups being caught up.
Obviously I'll do some dry-runs to figure out exactly what the process will feel like, but I'm trying to get a head start on understanding areas of low-redundancy during this migration so that I can minimize them.
Thanks,
Derrick