From: | Dustin Sallings <dustin(at)spy(dot)net> |
---|---|
To: | Matt Davies <matt(at)mattdavies(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Postgress and MYSQL |
Date: | 2004-01-14 19:11:15 |
Message-ID: | 6CCDCD73-46C5-11D8-B15D-000393CFE6B8@spy.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-general |
On Jan 14, 2004, at 10:18, Matt Davies wrote:
> 1. Replication: Like it or not most people regard their data and
> access to their
> data as 'invaluable'. If not, why are they storing it. Having a
> secondary
I'm not the only person who has used this same argument against mySQL
installs. There is a huge understanding problem here. Sure, so you're
replicating your data...that doesn't mean you're storing what you think
you're storing, or transactionally safe, or consistent, etc...
> server (read slaves) on which you can perform backups, load balance RO
> traffic,
> and eventually use as a failover has been one of the great selling
> points of
> MySQL for my specific applications. I wish there were a Master-Master
> replication scheme out there, but that is not the case.
You don't need a replicate to perform a backup in general. mySQL
imposed this requirement, but a replicate shouldn't be used that way.
Load balancing, perhaps...failover, maybe.
In my experience with really good replication systems (sybase's rep
server), we didn't really use replication this way. We had a replicate
going to a DSS system which was indexed and used differently, and we
had a replicate going to a ``warm'' standby which we would use for some
read-only queries. Its original purpose was to use as a failover
system, but it was rarely used this way, even when there were
catastrophic database problems. The reason is simple. If something
broke the DB, it would be plain irresponsible to swap out the DB server
for another one that is (as far as we know) just as likely to break for
the same reason leaving us stranded. Breaking replication required
rematerialization of the master after brining it back online, which was
an expensive process that left us without a spare for several hours.
So it was the DBAs' job to spend some time during any database failure
to determine the cause and solution. Occasionally that meant swapping
to the other DB, but that process was never automated (well, no more
than being a script a DBA would run whenever he determined it
necessary).
--
Dustin Sallings
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Davies | 2004-01-14 19:12:48 | Re: Postgress and MYSQL |
Previous Message | Josh Berkus | 2004-01-14 19:02:59 | Re: Website and "open development" |
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Davies | 2004-01-14 19:12:48 | Re: Postgress and MYSQL |
Previous Message | Ben | 2004-01-14 19:02:51 | Re: Postgress and MYSQL |