Are any of these changes ready for CVS for 7.4?


Ed L. wrote:
> I've been modifying dbmirror and wanted to offer my changes to anyone that 
> cared to experiment, FWIW.  My effort is ongoing, the docs aren't perfect, 
> I make no claims of production readiness, and testing of this latest 
> version has been minimal, so I strongly advise you to conduct your own 
> thorough testing before considering a production deployment.  That said, 
> it's a significantly improved solution for our async master-slave needs, 
> with a few caveats below, and shouldn't be too hard to setup.
> There are enough changes that I would hardly consider this a patch,  closer 
> to an overhaul, since I've removed files, renamed others, and added new 
> files.  Among the changes I've made so far:
>       * Added script for easier setup of many tables/dbs/slaves;
>       * Added initial support for multiple master replicating distinct data to a 
> single slave;
>       * Added batching to minimize load on master and net traffic.  You can grab 
> a configurable number of updates to replicate before hitting the master 
> again.
>       * Added port specification;
>       * Wrapped all replication in transactions;
>         * Bulletproofed against downed master or slave;
>         * Started modularization of DB access layer, added some error 
> handling;
>         * Added a number of config vars for sync delays, etc;
>         * Eliminated bug in transaction ordering for replay.  Updates cannot 
> be replicated in the order of the transactions (see archives for discussion 
> of why).
>         * Eliminated need for by making 
> self-clearing;
>         * Collasped schema into 1 queue table for performance;
>         * Changed sequence ID column types to BIGINT for 64-bit sequence;
>         * Added reconnection handling for robustness;
>         * Added local tracking of last seq_id to help with recovery 
> robustness;
>         * Added master/slave compatibility checking;
>         * Enabled slave setup during production service so master does not 
> have to stop serving.
>         * Renamed tables to minimize namespace conflicts;
>         * Added lots of logging/debug messages;
>       * Maybe a few other things I've forgotten...
> AFAICS, there are still at least a few major drawbacks to this approach:
>       *  DML statements are not replicated (same for eRServer, AFAIK).
>       *  SEQUENCE objects are not handled;  nextval() will not be replicated, so 
> sequence objects (and serial columns) between master and slave can easily 
> get out of sync.  I wonder if eRServer has this same issue?
>       *  Mass updates/deletes/inserts of 5000 rows with a single SQL command on 
> the master will result in 5000 individual trigger-firings, and 5000 
> individual replication inserts on the slave.  Rumor has it eRServer's 
> snapshot gets around this problem.
> The code is here:
> Ed
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [EMAIL PROTECTED] so that your
> message can get through to the mailing list cleanly

  Bruce Momjian                        |
  [EMAIL PROTECTED]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to