On Thu, 2008-05-29 at 12:05 -0700, Robert Hodges wrote:
> Hi everyone,
>
> First of all, I’m absolutely delighted that the PG community is
> thinking seriously about replication.
>
> Second, having a solid, easy-to-use database availability solution
> that works more or less out of the box would be an enormous benefit to
> customers. Availability is the single biggest problem for customers
> in my experience and as other people have commented the alternatives
> are not nice. It’s an excellent idea to build off an existing feature
> —PITR is already pretty useful and the proposed features are solid
> next steps. The fact that it does not solve all problems is not a
> drawback but means it’s likely to get done in a reasonable timeframe.
>
> Third, you can’t stop with just this feature. (This is the BUT part
> of the post.) The use cases not covered by this feature area actually
> pretty large. Here are a few that concern me:
>
> 1.) Partial replication.
> 2.) WAN replication.
1.) & 2.) are better done asunc, the domain of Slony-I/Londiste
> 3.) Bi-directional replication. (Yes, this is evil but there are
> problems where it is indispensable.)
Sure, it is also a lot harder and always has several dimensions
(performanse/availability7locking) which play against each other
> 4.) Upgrade sup****t. Aside from database upgrade (how would this ever
> really work between versions?), it would not sup****t zero-downtime app
> upgrades, which depend on bi-directional replication tricks.
Or you could use zero-downtime app upgrades, which don't depend on
this :P
> 5.) Heterogeneous replication.
> 6.) Finally, performance scaling using scale-out over large numbers of
> replicas. I think it’s possible to get tunnel vision on this—it’s
not
> a big requirement in the PG community because people don’t use PG in
> the first place when they want to do this. They use MySQL, which has
> very good replication for performance scaling, though it’s rather weak
> for availability.
Again, doing scale-out over large number of replicas should either be
async or for sync use some broadcast channel to all slaves (and still be
a performance problem on master, as it has to wait for slowest slave).
> As a consequence, I don’t see how you can get around doing some sort
> of row-based replication like all the other databases.
Is'nt WAL-base replication "some sort of row-based replication" ?
> Now that people are starting to get religion on this issue I would
> strongly advocate a parallel effort to put in a change-set extraction
> API that would allow construction of comprehensive master/slave
> replication.
Triggers. see pgQ's logtrigga()/logutrigga(). See slides for Marko
Kreen's presentation at pgCon08.
> (Another approach would be to make it possible for third party apps
> to read the logs and regenerate SQL.)
which logs ? WAL or SQL command logs ?
> There are existing models for how to do change set extraction; we have
> done it several times at my company already. There are also research
> projects like GORDA that have looked fairly comprehensively at this
> problem.
pgQ with its triggers does a pretty good job of change-set extraction.
------------------
Hannu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
|
