Thread: How to switch file systems with least downtime?
How do I migrate my 9.1 directory to a new file system with the least downtime possible?
I don't know if this makes any difference, but my pg_xlog directory is on its own volume as well, so I would have to unmount it and remount it as well, but I would not have to copy over my xlogs.
I figure the first part of this is to do a pg_start_backup() and rsync the files over., bu I'm not sure what to do after that.
Thanks for your help.
Moshe Jacobson
Nead Werx, Inc. | Manager of Systems Engineering
Nead Werx, Inc. | Manager of Systems Engineering
2323 Cumberland Parkway, Suite 201 | Atlanta, GA 30339
moshe@neadwerx.com | www.neadwerx.com
moshe@neadwerx.com | www.neadwerx.com
"Quality is not an act, it is a habit." -- Aristotle
Have you considered setting up a synchronously replicated slave database on the new file system (using a port other than 5432), getting it in sync, then shutting both databases down (master first), switching the slave over to become the master and restarting just that database on port 5432?
--
--
Mike Nolan
On Sat, Sep 14, 2013 at 8:32 AM, Moshe Jacobson <moshe@neadwerx.com> wrote:
How do I migrate my 9.1 directory to a new file system with the least downtime possible?I don't know if this makes any difference, but my pg_xlog directory is on its own volume as well, so I would have to unmount it and remount it as well, but I would not have to copy over my xlogs.I figure the first part of this is to do a pg_start_backup() and rsync the files over., bu I'm not sure what to do after that.Thanks for your help.Moshe Jacobson
Nead Werx, Inc. | Manager of Systems Engineering2323 Cumberland Parkway, Suite 201 | Atlanta, GA 30339
moshe@neadwerx.com | www.neadwerx.com"Quality is not an act, it is a habit." -- Aristotle
On Sat, Sep 14, 2013 at 9:40 AM, Michael Nolan <htfoot@gmail.com> wrote:
Not a bad idea, but in this case, a small amount of downtime is preferable over going to that level of effort.
Have you considered setting up a synchronously replicated slave database on the new file system (using a port other than 5432), getting it in sync, then shutting both databases down (master first), switching the slave over to become the master and restarting just that database on port 5432?
Not a bad idea, but in this case, a small amount of downtime is preferable over going to that level of effort.
Moshe Jacobson
Nead Werx, Inc. | Manager of Systems Engineering
Nead Werx, Inc. | Manager of Systems Engineering
2323 Cumberland Parkway, Suite 201 | Atlanta, GA 30339
moshe@neadwerx.com | www.neadwerx.com
moshe@neadwerx.com | www.neadwerx.com
"Quality is not an act, it is a habit." -- Aristotle
We've done this across servers, maybe it would work for you:
1) rsync the entire db to the second file system
2) do another rsync each day until you are ready to swap (of course only changed files will be moved)
3) before the swap do another rsync to bring the db as close to sync'ed as possible
4) shut down the primary db
5) do a final rsync (should have little to nothing to sync)
6) start the secondary db
7) Validate the new db
On 9/14/13 7:46 AM, Moshe Jacobson wrote:
1) rsync the entire db to the second file system
2) do another rsync each day until you are ready to swap (of course only changed files will be moved)
3) before the swap do another rsync to bring the db as close to sync'ed as possible
4) shut down the primary db
5) do a final rsync (should have little to nothing to sync)
6) start the secondary db
7) Validate the new db
On 9/14/13 7:46 AM, Moshe Jacobson wrote:
On Sat, Sep 14, 2013 at 9:40 AM, Michael Nolan <htfoot@gmail.com> wrote:Have you considered setting up a synchronously replicated slave database on the new file system (using a port other than 5432), getting it in sync, then shutting both databases down (master first), switching the slave over to become the master and restarting just that database on port 5432?
Not a bad idea, but in this case, a small amount of downtime is preferable over going to that level of effort.Moshe Jacobson
Nead Werx, Inc. | Manager of Systems Engineering2323 Cumberland Parkway, Suite 201 | Atlanta, GA 30339
moshe@neadwerx.com | www.neadwerx.com"Quality is not an act, it is a habit." -- Aristotle
On Sat, Sep 14, 2013 at 11:26 AM, CS DBA <cs_dba@consistentstate.com> wrote:
Thanks. That's how I normally do it, but I was hoping to eliminate much of the downtime between 4 and 6.
3) before the swap do another rsync to bring the db as close to sync'ed as possible
4) shut down the primary db
5) do a final rsync (should have little to nothing to sync)
6) start the secondary db
Thanks. That's how I normally do it, but I was hoping to eliminate much of the downtime between 4 and 6.
Moshe Jacobson
Nead Werx, Inc. | Manager of Systems Engineering
Nead Werx, Inc. | Manager of Systems Engineering
2323 Cumberland Parkway, Suite 201 | Atlanta, GA 30339
moshe@neadwerx.com | www.neadwerx.com
moshe@neadwerx.com | www.neadwerx.com
"Quality is not an act, it is a habit." -- Aristotle
On Sat, Sep 14, 2013 at 6:32 AM, Moshe Jacobson <moshe@neadwerx.com> wrote: > How do I migrate my 9.1 directory to a new file system with the least > downtime possible? > > I don't know if this makes any difference, but my pg_xlog directory is on > its own volume as well, so I would have to unmount it and remount it as > well, but I would not have to copy over my xlogs. Just FYI you still need to copy over pg_xlog
On Sat, Sep 14, 2013 at 2:32 PM, Moshe Jacobson <moshe@neadwerx.com> wrote: > How do I migrate my 9.1 directory to a new file system with the least > downtime possible? > Create a new tablespace on a the new filesystem and move everything over.