Thread: Postgres and geographically diverse replication
Hi, I've been given a task to build a couple of geographically separate servers, which are capable of replicating data between each other. I've surfed through various google results, and most of what I've found seems to be a bit dated, so I thought I'd pose my question here, perhaps for more detailed and more up-to-date info. Is this normally done in a push/pull scenario within the postgres installations themselves, or is additional software required? What are the various replication capabilities? I apologize for the general nature of my questions, I'm new to postgres and to geographically separate replication. Any tips, books, whitepapers or other resources you might be able to point me to is most appreciated. Thanks, Drew Myers
To answer your question meaningfully, you need to provide more details. What are you trying to get out of "replication"? High availability? Load sharing? On Wed, 18 Apr 2007, Drew Myers wrote: > > Hi, > > I've been given a task to build a couple of geographically separate > servers, which are capable of replicating data between each other. > > I've surfed through various google results, and most of what I've found > seems to be a bit dated, so I thought I'd pose my question here, perhaps > for more detailed and more up-to-date info. > > Is this normally done in a push/pull scenario within the postgres > installations themselves, or is additional software required? What are > the various replication capabilities? > > I apologize for the general nature of my questions, I'm new to postgres > and to geographically separate replication. Any tips, books, whitepapers > or other resources you might be able to point me to is most appreciated. > > Thanks, > > Drew Myers > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster >
In response to "Drew Myers" <drew.myers@innerwireless.com>: > > I've been given a task to build a couple of geographically separate > servers, which are capable of replicating data between each other. > > I've surfed through various google results, and most of what I've found > seems to be a bit dated, so I thought I'd pose my question here, perhaps > for more detailed and more up-to-date info. > > Is this normally done in a push/pull scenario within the postgres > installations themselves, or is additional software required? What are > the various replication capabilities? > > I apologize for the general nature of my questions, I'm new to postgres > and to geographically separate replication. Any tips, books, whitepapers > or other resources you might be able to point me to is most appreciated. Generally speaking, when you're talking geographically separate, Slony is your best bet. We're using it to maintain data on opposites sides of the US with good success. http://slony.info -- Bill Moran http://www.potentialtech.com
On Wed, 2007-04-18 at 16:43 -0400, Bill Moran wrote: > In response to "Drew Myers" <drew.myers@innerwireless.com>: > > > > I've been given a task to build a couple of geographically separate > > servers, which are capable of replicating data between each other. > > > > I've surfed through various google results, and most of what I've found > > seems to be a bit dated, so I thought I'd pose my question here, perhaps > > for more detailed and more up-to-date info. > > > > Is this normally done in a push/pull scenario within the postgres > > installations themselves, or is additional software required? What are > > the various replication capabilities? > > > > I apologize for the general nature of my questions, I'm new to postgres > > and to geographically separate replication. Any tips, books, whitepapers > > or other resources you might be able to point me to is most appreciated. > > Generally speaking, when you're talking geographically separate, Slony > is your best bet. We're using it to maintain data on opposites sides of > the US with good success. Successfully using slony over a wide area is going to depend on how much data you are replicating, how fast the connection between the two sites is, and how stable the connection between the two sites is. -- Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp.
In response to Brad Nicholson <bnichols@ca.afilias.info>: > On Wed, 2007-04-18 at 16:43 -0400, Bill Moran wrote: > > In response to "Drew Myers" <drew.myers@innerwireless.com>: > > > > > > I've been given a task to build a couple of geographically separate > > > servers, which are capable of replicating data between each other. > > > > > > I've surfed through various google results, and most of what I've found > > > seems to be a bit dated, so I thought I'd pose my question here, perhaps > > > for more detailed and more up-to-date info. > > > > > > Is this normally done in a push/pull scenario within the postgres > > > installations themselves, or is additional software required? What are > > > the various replication capabilities? > > > > > > I apologize for the general nature of my questions, I'm new to postgres > > > and to geographically separate replication. Any tips, books, whitepapers > > > or other resources you might be able to point me to is most appreciated. > > > > Generally speaking, when you're talking geographically separate, Slony > > is your best bet. We're using it to maintain data on opposites sides of > > the US with good success. > > Successfully using slony over a wide area is going to depend on how much > data you are replicating, how fast the connection between the two sites > is, and how stable the connection between the two sites is. That's all true. It's also true of _any_ geographically diverse replication. Except, of course, Microsoft's. According to Microsoft's marketing materials, their replication system is able to exceed the speed of light. So far, we've found Slony to do an excellent job of gracefully handing intermittent network problems and occasional transaction spikes that temporarily exceeded our available bandwidth. Obviously, excessive instances of either of these situations are going to make Slony fail, but they'll do that to _any_ replication system, except those that can exceed the speed of light ... -- Bill Moran http://www.potentialtech.com