From: | Derrick Rice <derrick(dot)rice(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Migrating to a WAL-shipped replication cluster |
Date: | 2011-05-13 16:56:25 |
Message-ID: | BANLkTi=XzJerA74CBE4VzEwyeBtw+Saxkg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | James B. Byrne | 2011-05-13 17:04:22 | Re: How to handle bogus nulls from ActiveRecord |
Previous Message | Fanbin Meng | 2011-05-13 16:33:22 | Link error when use functions of PGtypes |