[EMAIL PROTECTED] (Brad Nicholson) writes:
> On Wed, 2006-10-11 at 16:12 -0500, Jim C. Nasby wrote:
>> On Wed, Oct 11, 2006 at 10:28:44AM -0400, Andrew Sullivan wrote:
>> > On Thu, Oct 05, 2006 at 08:43:21PM -0500, Jim Nasby wrote:
>> > > Isn't it entirely possible that if the master gets trashed i
On Wed, 2006-10-11 at 16:12 -0500, Jim C. Nasby wrote:
> On Wed, Oct 11, 2006 at 10:28:44AM -0400, Andrew Sullivan wrote:
> > On Thu, Oct 05, 2006 at 08:43:21PM -0500, Jim Nasby wrote:
> > > Isn't it entirely possible that if the master gets trashed it would
> > > start sending garbage to the Slo
On Wed, Oct 11, 2006 at 10:28:44AM -0400, Andrew Sullivan wrote:
> On Thu, Oct 05, 2006 at 08:43:21PM -0500, Jim Nasby wrote:
> > Isn't it entirely possible that if the master gets trashed it would
> > start sending garbage to the Slony slave as well?
>
> Well, maybe, but unlikely. What happens
Hi,
>
> I think this highlights exactly what I'm trying to emphasise: in
> actual, shared-nothing systems like this, there's no possible
> guarantee of "never". There are possible guarantees of "very
> rarely". The problem is, you're already trying to address a teeny
> portion of the likely eve
On Tue, Oct 10, 2006 at 10:11:08AM -0500, Jim C. Nasby wrote:
> couldn't setup HA on OpenBSD. The key is just to make sure that you
> never bring up two servers on the same data directory.
I think this highlights exactly what I'm trying to emphasise: in
actual, shared-nothing systems like this, th
On Thu, Oct 05, 2006 at 08:43:21PM -0500, Jim Nasby wrote:
> Isn't it entirely possible that if the master gets trashed it would
> start sending garbage to the Slony slave as well?
Well, maybe, but unlikely. What happens in a shared-disc failover is
that the second machine re-mounts the same pa
On Fri, Oct 06, 2006 at 06:34:25AM -, Sebastian Reitenbach wrote:
> > I think PITR would be a much better option to protect against this,
> > since you could probably recover up to the exact point of failover.
> >
> > When it comes to the actual failover, take a look at the HA-linux
> > pr
Hi all,
>
> I think PITR would be a much better option to protect against this,
> since you could probably recover up to the exact point of failover.
>
> When it comes to the actual failover, take a look at the HA-linux
> project. They've got some stuff you could probably use (such as the
On Oct 5, 2006, at 1:41 PM, Andrew Sullivan wrote:
On Thu, Oct 05, 2006 at 04:24:17AM -, Sebastian Reitenbach wrote:
I just have one data center, no remote far away replication is
needed.
If it is at all feasible with your budget, I'd think _very strongly_
about replicating using Slony
On Thu, 2006-10-05 at 04:24 +, Sebastian Reitenbach wrote:
> Hi,
>
> Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> > On Wed, Oct 04, 2006 at 11:23:45 -,
> > Sebastian Reitenbach <[EMAIL PROTECTED]> wrote:
> > >
> > > something I thought that might work:
> > > is there sth. that will rep
On Thu, Oct 05, 2006 at 04:24:17AM -, Sebastian Reitenbach wrote:
>
> I just have one data center, no remote far away replication is needed.
If it is at all feasible with your budget, I'd think _very strongly_
about replicating using Slony inside your data centre _too_. The
shared storage an
Hi,
Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 04, 2006 at 11:23:45 -,
> Sebastian Reitenbach <[EMAIL PROTECTED]> wrote:
> >
> > something I thought that might work:
> > is there sth. that will repair an inconsisten postgresql datastore? e.g.
the
> > master database died, t
On Wed, 2006-10-04 at 10:43 -0500, Bruno Wolff III wrote:
> On Wed, Oct 04, 2006 at 11:23:45 -,
> Sebastian Reitenbach <[EMAIL PROTECTED]> wrote:
> If you have multiple data centers to protect against disaster, then you might
> look at SLONY which you can use to replicate to a slave system.
On Wed, Oct 04, 2006 at 11:23:45 -,
Sebastian Reitenbach <[EMAIL PROTECTED]> wrote:
>
> something I thought that might work:
> is there sth. that will repair an inconsisten postgresql datastore? e.g. the
> master database died, the slave will mount the storage, then repair it in a
> reason
14 matches
Mail list logo