Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [propel-dev] r/w splitting in master-slave db replication environment

propel
Discussion topic

Back to topic list

Re: [propel-dev] r/w splitting in master-slave db replication environment

Reply

Author =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com>
Full name =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com>
Date 2008-01-07 08:02:14 PST
Message Hmmm... sure? AFAIK, that's just what SQLRelay, MySQLProxy et al do...
But yeah, you might have a point.


David



Am 07.01.2008 um 16:56 schrieb Hans Lellelid:

> Ok, I think I understand how this would work. One change, though,
> is that I'd like to not have any SQL-parsing done by Propel to
> determine which connection to use. I think the connection type
> (master/write or slave/read) needs to be explicitly requested by the
> generated peer classes. There's no good way to determine whether a
> SQL statement represents a read or a write operation.
>
> Hans
>
> David Zülke wrote:
>> No, Propel uses an instance of the router to determine which
>> connection to write to. That is done by calling a method on the
>> router, along with the SQL query. The router could then decide
>> which actual connection to return. In Propels default
>> implementation this would, unconditionally, be a random slave for
>> any SELECT; for everything else, it would be the master connection.
>>
>>
>> David
>>
>>
>>
>> Am 07.01.2008 um 15:47 schrieb Hans Lellelid:
>>
>>> I'm not sure I understand how they fit in to the big picture,
>>> though. Does PropelPDO implement PropelReplicationRouter? Or are
>>> these separate objects -- and if so, it seems like this would be a
>>> breaking API change?
>>>
>>> Hans
>>>
>>> David Zülke wrote:
>>>> An idea...
>>>> interface PropelReplicationRouter { /* with some stuff */ }
>>>>
>>>> Such an implementation is used to determine where to write to. We
>>>> have a default one that shoots SELECTs to a random slave, rest to
>>>> a master. It's not a static class, so instead of setting a class
>>>> name in the configuration, a user could also provide an existing
>>>> instance (because, for instance, he needed to initialize it with
>>>> whatever information first).
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>> David
>>>>
>>>>
>>>>
>>>> Am 04.01.2008 um 14:57 schrieb Hans Lellelid:
>>>>
>>>>> Hi All -
>>>>>
>>>>> I wanted to re-open this discussion. I'm currently working with
>>>>> the
>>>>> various PDO subclasses in Propel to address the need for
>>>>> logging, etc.
>>>>> As part of this, I'm also going to be refactoring the master/
>>>>> slave stuff
>>>>> a bit. I wanted to provide some information about what I'm
>>>>> currently
>>>>> thinking of and get someone (Moritz?) to provide a unified set of
>>>>> requirements for good replication support -- with the
>>>>> requirement that
>>>>> it not cause excessive complexity or performance penalties to
>>>>> those who
>>>>> don't need the replication support. Ideally, I'd also not like
>>>>> to have
>>>>> the replication support affect the OM build.
>>>>>
>>>>> So, currently in the works is a system like this (this is mostly
>>>>> code by
>>>>> Christian):
>>>>>
>>>>> - Propel configuration parsing will look for the presence of
>>>>> <slave>
>>>>> connection configurations in the runtime configuration file. If
>>>>> they
>>>>> are present, the ReplicationPDO class will be used (instead of the
>>>>> default, PropelPDO). ReplicationPDO delegates read queries
>>>>> (SELECT
>>>>> statements) to a *random* slave. The slave connection is only
>>>>> actually
>>>>> initialized when requested. The SlavePDO class is used for the
>>>>> slave
>>>>> connections (when they're initialized); this class overrides
>>>>> methods to
>>>>> ensure that it is only performing read queries.
>>>>> - It is also possible to override the PDO subclass by specifying a
>>>>> <classname> within the <connection> for the master connection or
>>>>> the
>>>>> slave connections. It is worth noting that the generated code
>>>>> requires
>>>>> a PropelPDO object (for nested transaction support), so the
>>>>> custom class
>>>>> will have to subclass PropelPDO.
>>>>>
>>>>> Some questions / comments I have:
>>>>> - Is there a reason to use random connections for every SELECT
>>>>> query?
>>>>> Or should we iterate over slaves (if more than one)? -- Maybe
>>>>> compromise would be to start with a random slave and then loop
>>>>> over
>>>>> them. I don't know that calling rand() for every SELECT
>>>>> statement is a
>>>>> big performance penalty, but it doesn't seem entirely necessary.
>>>>> - Is it strictly necessary to enforce READ-only in the
>>>>> SlavePDO? i.e.
>>>>> if a slave object is explicitly asked to perform an update,
>>>>> should this
>>>>> be allowed? I guess my concern is that by checking the SQL for
>>>>> 'SELECT'
>>>>> (but not 'SELECT INTO'), we are not comprehensively eliminating
>>>>> update
>>>>> statements --- e.g. "select sp_insert_into_my_table('foo',
>>>>> 'bar')". I
>>>>> don't think there's any good way for the ReplicationPDO to be
>>>>> able to
>>>>> guess, based on the SQL, which connection should be used. For
>>>>> that
>>>>> reason, I like Mortiz's suggestion of having this be explicitly
>>>>> requested as part of the getConnection() call -- i.e. the
>>>>> doSelect()
>>>>> methods know they can use a slave, other methods will use a
>>>>> master.
>>>>> When fetching your own connection, the default could be master,
>>>>> but you
>>>>> could also fetch a slave connection if you know that you're
>>>>> performing a
>>>>> SQL query. Putting this into the hands of the programmer, is
>>>>> probably
>>>>> wise, no?
>>>>> - From Mortiz's description below, is it safe to assume that for
>>>>> systems
>>>>> that don't care about replication Propel::getConnection() would
>>>>> always
>>>>> be returning a master connection -- regardless of whether a
>>>>> slave was
>>>>> requested?
>>>>>
>>>>> I've created an empty wiki page to hold the finalized version of
>>>>> this:
>>>>> http://propel.phpdb.​org/trac/wiki/Develo​pment/ReplicationSup​port
>>>>> I'm looking for volunteer(s) to help distill this discussion
>>>>> into a set
>>>>> of basic requirements and help me plan (and test) this
>>>>> implementation.
>>>>> I definitely like what I see below (and think I understand it);
>>>>> I just
>>>>> want to make sure everyone is in agreement. Also, I have not
>>>>> used db
>>>>> replication at all, so I look for wiser input on what application
>>>>> support for this should look like. The important thing from my
>>>>> perspective, as mentioned earlier, is that it not introduce
>>>>> complexity
>>>>> or penalty for those not using replication -- and also that it
>>>>> not break
>>>>> the current API. I don't see anything below that would do
>>>>> either, but
>>>>> just wanted to make that clear.
>>>>>
>>>>> Thanks!
>>>>> Hans
>>>>>
>>>>> Moritz Mertinkat wrote:
>>>>>> Yeah, you're absolutely right. CONNECTION_SELECT or
>>>>>> CONNECTION_READ or
>>>>>> something like that (think i'd prefer _READ and _WRITE for
>>>>>> being a bit
>>>>>> more unspecific ;-).
>>>>>>
>>>>>> Things to think about:
>>>>>>
>>>>>> 1) If a MASTER/WRITE connection is established first (and no
>>>>>> master
>>>>>> connection is forced), should all subsequent SLAVE/SELECT/READ
>>>>>> "connections" use that established connection? Or would it be
>>>>>> better
>>>>>> to establish an additional SLAVE/SELECT/READ connection?
>>>>>> Maybe Propel::forceSingleC​onnection(true/false​)?
>>>>>>
>>>>>> 2) Propel::forceMasterC​onnection(true/false​) should be
>>>>>> implemented imho.
>>>>>>
>>>>>> 3) Propel::forceConsist​entConnection(true/f​alse) would be quite
>>>>>> nice.
>>>>>>
>>>>>> Regards,
>>>>>> Moritz
>>>>>>
>>>>>> Shane Langley schrieb:
>>>>>>> I think CONNECTION_SLAVE is a bit confusing - since
>>>>>>> CONNECTION_SLAVE
>>>>>>> could be a connection to the master.
>>>>>>>
>>>>>>> Maybe CONNECTION_SELECT?
>>>>>>>
>>>>>>> Shane.
>>>>>>>
>>>>>>> Moritz Mertinkat wrote:
>>>>>​>>> Hi,
>>>>>​>>>
>>>>>​>>> what about Propel::getConnection(..., <TYPE>) where TYPE is
>>>>>​>>> something like this: CONNECTION_MASTER, CONNECTION_SLAVE?
>>>>>​>>>
>>>>>​>>> Within a doDelete method this would be called with
>>>>>​>>> CONNECTION_MASTER
>>>>>​>>> whereas in a doSelect method CONNECTION_SLAVE is used.
>>>>>​>>>
>>>>>​>>> That way there's a maximum of two open connection (first
>>>>>​>>> SLAVE and
>>>>>​>>> then MASTER). If a MASTER is opened first one may use that
>>>>>​>>> connection also for reading (even if CONNECTION_SLAVE is used).
>>>>>​>>> PRO: the connection is _only_ established when required.
>>>>>​>>>
>>>>>​>>> What it does NOT fix is the problem Shane described (forced
>>>>>​>>> reading
>>>>>​>>> from
>>>>>​>>> a MASTER). Therefore a Propel::forceMasterC​onnection(true)
>>>>>​>>> method may
>>>>>​>>> be implemented.
>>>>>​>>>
>>>>>​>>> [A nice add-on feature might be
>>>>>​>>> Propel::forceConsist​entConnection(true).​ When a slave
>>>>>​>>> connection is
>>>>>​>>> required the slave's status is checked first and the
>>>>>​>>> connection will
>>>>>​>>> only be used if the slave is up-to-date. However I do only
>>>>>​>>> know how
>>>>>​>>> to do this with MySQL.]
>>>>>​>>>
>>>>>​>>> Regards,
>>>>>​>>> Moritz
>>>>>​>>>
>>>>>​>>>
>>>>>​>>> Shane Langley schrieb:
>>>>>​>>>> "Another problem with random-slave-per-query might occur when
>>>>>​>>>> you're slaves are
>>>>>​>>>> not 100 % synchronized (i.e. some are a few seconds behind
>>>>>​>>>> master).
>>>>>​>>>> I think a single page view should (in general) be handled by
>>>>>​>>>> just
>>>>>​>>>> one slave."
>>>>>​>>>>
>>>>>​>>>> I agree with this. The first time a connection to a slave is
>>>>>​>>>> required a connection should be established to one slave, and
>>>>>​>>>> stored as the "select" connection.
>>>>>​>>>>
>>>>>​>>>> Subsequent selects should re-use that slave .
>>>>>​>>>>
>>>>>​>>>> "[Onother idea would be to tell Propel if you need read/
>>>>>​>>>> write- or just
>>>>>​>>>> read-access to your database. In case you only need read-
>>>>>​>>>> access it's
>>>>>​>>>> enough to connect _one_ a random slave (no master db is
>>>>>​>>>> required).
>>>>>​>>>> Maybe both ideas together would make the perfect
>>>>>​>>>> master-slave-propel :-]"
>>>>>​>>>>
>>>>>​>>>> The reverse works as well.
>>>>>​>>>>
>>>>>​>>>> For an application I worked on I created a
>>>>>​>>>> ConnectionMananger class
>>>>>​>>>> that
>>>>>​>>>> handled the split between master/slave.
>>>>>​>>>>
>>>>>​>>>> I added a method "forceMaster()" that would ensure every query
>>>>>​>>>> would hit the master.
>>>>>​>>>>
>>>>>​>>>> Some pages you want to have the most update-to-date data (when
>>>>>​>>>> editing for example) loaded into
>>>>>​>>>> your form. Without this method, the data would come from a
>>>>>​>>>> slave
>>>>>​>>>> (since the select query is not in a transaction) which could
>>>>>​>>>> be
>>>>>​>>>> out-of-date by a few seconds.
>>>>>​>>>>
>>>>>​>>>> In this case, you don't need a slave connection at all.
>>>>>​>>>>
>>>>>​>>>> Regards,
>>>>>​>>>>
>>>>>​>>>> Shane.
>>>>>​>>>>
>>>>>​>>>> Moritz Mertinkat wrote:
>>>>>​>>>>>​ Hi everybody,
>>>>>​>>>>>​
>>>>>​>>>>>​ I've just looked at the code and I think it's a great thing
>>>>>​>>>>>​ to add
>>>>>​>>>>>​ to propel.
>>>>>​>>>>>​
>>>>>​>>>>>​ What I think should be improved is that all slave
>>>>>​>>>>>​ connections get
>>>>>​>>>>>​ connected at
>>>>>​>>>>>​ the moment Propel ist loaded. That is, if you have eight
>>>>>​>>>>>​ MySQL
>>>>>​>>>>>​ slave servers
>>>>>​>>>>>​ you establish a MySQL connection to all of them, even
>>>>>​>>>>>​ though you
>>>>>​>>>>>​ just need one
>>>>>​>>>>>​ (for example). Kinda slow :)
>>>>>​>>>>>​
>>>>>​>>>>>​ Wouldn't it be better to load just _one_ random slave upon
>>>>>​>>>>>​ starting?
>>>>>​>>>>>​
>>>>>​>>>>>​ Another problem with random-slave-per-query might occur when
>>>>>​>>>>>​ you're slaves are
>>>>>​>>>>>​ not 100 % synchronized (i.e. some are a few seconds behind
>>>>>​>>>>>​ master).
>>>>>​>>>>>​ I think a single page view should (in general) be handled
>>>>>​>>>>>​ by just
>>>>>​>>>>>​ one slave.
>>>>>​>>>>>​
>>>>>​>>>>>​ For those who (really) want to have a different slave each
>>>>>​>>>>>​ query
>>>>>​>>>>>​ one might add
>>>>>​>>>>>​ a flag to Propel::init or to the configuration.
>>>>>​>>>>>​
>>>>>​>>>>>​ [Onother idea would be to tell Propel if you need read/
>>>>>​>>>>>​ write- or just
>>>>>​>>>>>​ read-access to your database. In case you only need read-
>>>>>​>>>>>​ access it's
>>>>>​>>>>>​ enough to connect _one_ a random slave (no master db is
>>>>>​>>>>>​ required).
>>>>>​>>>>>​ Maybe both ideas together would make the perfect
>>>>>​>>>>>​ master-slave-propel :-]
>>>>>​>>>>>​
>>>>>​>>>>>​ Regards,
>>>>>​>>>>>​ Moritz
>>>>>​>>>>>​
>>>>>​>>>>>​
>>>>>​>>>>>​ Christian Abegg schrieb:
>>>>>​>>>>>​
>>>>>​>>>>>​> Hi Hans
>>>>>​>>>>>​>
>>>>>​>>>>>​> - This will work fine without master/slave replication and
>>>>>​>>>>>​> it
>>>>>​>>>>>​> should not
>>>>>​>>>>>​> have any impact on a existing single db setup. Although
>>>>>​>>>>>​> I'd be
>>>>>​>>>>>​> glad for
>>>>>​>>>>>​> further testings or code reviews.
>>>>>​>>>>>​>
>>>>>​>>>>>​> - The changes in the Propel class primarly touch the
>>>>>​>>>>>​> "getConnection" method.
>>>>>​>>>>>​> I copied some code from it to that new "initConnection"
>>>>>​>>>>>​> method
>>>>>​>>>>>​> which can now
>>>>>​>>>>>​> be called multiple times from the "getConnection" method
>>>>>​>>>>>​> (i.e.
>>>>>​>>>>>​> for the
>>>>>​>>>>>​> master and its slaves).
>>>>>​>>>>>​>
>>>>>​>>>>>​> - Of course I'll document it.
>>>>>​>>>>>​>
>>>>>​>>>>>​> Please note that I've just tried it on a mysql replication
>>>>>​>>>>>​> setup.
>>>>>​>>>>>​> I'd be
>>>>>​>>>>>​> happy to run some tests. Do you have a test suite?
>>>>>​>>>>>​>
>>>>>​>>>>>​> Regards,
>>>>>​>>>>>​> Christian
>>>>>​>>>>>​>
>>>>>​>>>>>​>
>>>>>​>>>>>​>
>>>>>​>>>>>​>
>>>>>​>>>>>​>
>>>>>​>>>>>​>
>>>>>​>>>>>​>
>>>>>​>>>>>​> Hans Lellelid wrote:
>>>>>​>>>>>​>
>>>>>​>>>>>​>> Hi Christian,
>>>>>​>>>>>​>>
>>>>>​>>>>>​>> Yes :)
>>>>>​>>>>>​>>
>>>>>​>>>>>​>> Am I right in assuming that this will work fine without a
>>>>>​>>>>>​>> master/slave
>>>>>​>>>>>​>> setup? (i.e. in traditional, single-db model?)
>>>>>​>>>>>​>>
>>>>>​>>>>>​>> I didn't drop these in to do a diff, but the PropelPDO
>>>>>​>>>>>​>> looked
>>>>>​>>>>>​>> fairly
>>>>>​>>>>>​>> similar; Propel class too?
>>>>>​>>>>>​>>
>>>>>​>>>>>​>> I'd like to get this added in, though. I think it would
>>>>>​>>>>>​>> be a great
>>>>>​>>>>>​>> benefit.
>>>>>​>>>>>​>>
>>>>>​>>>>>​>> Would you be willing to contribute some documentation on
>>>>>​>>>>>​>> getting
>>>>>​>>>>>​>> this
>>>>>​>>>>>​>> setup? -- e.g. in 1.3 user guide?
>>>>>​>>>>>​>>
>>>>>​>>>>>​>> Thanks,
>>>>>​>>>>>​>> Hans
>>>>>​>>>>>​>>
>>>>>​>>>>>​>>
>>>>>​>>>>>​>> Christian Abegg wrote:
>>>>>​>>>>>​>>
>>>>>​>>>>>​>>> hi there
>>>>>​>>>>>​>>>
>>>>>​>>>>>​>>> here's a refinend implementation of r/w splitting:
>>>>>​>>>>>​>>> http://www.nabble.co​m/file/p14116000/rwS​plitting.zip
>>>>>​>>>>>​>>> rwSplitting.zip
>>>>>​>>>>>​>>>
>>>>>​>>>>>​>>> anyone interested?
>>>>>​>>>>>​>>>
>>>>>​>>>>>​>>> regards
>>>>>​>>>>>​>>> christian
>>>>>​>>>>>​>>>
>>>>>​>>>>>​>>>
>>>>>​>>>>>​>>>
>>>>>​>>>>>​>>> Christian Abegg wrote:
>>>>>​>>>>>​>>>
>>>>>​>>>>>​>>>> hi cameron, dear devs
>>>>>​>>>>>​>>>>
>>>>>​>>>>>​>>>> thank you for your reply. i made a first try to
>>>>>​>>>>>​>>>> implement it
>>>>>​>>>>>​>>>> the way you
>>>>>​>>>>>​>>>> proposed:
>>>>>​>>>>>​>>>> - the propel class initializes a PropelPDO object which
>>>>>​>>>>>​>>>> acts
>>>>>​>>>>>​>>>> as db
>>>>>​>>>>>​>>>> connection to the master server
>>>>>​>>>>>​>>>> - the PropelPDO object also holds an array of other PDO
>>>>>​>>>>>​>>>> connections used
>>>>>​>>>>>​>>>> for read only queries
>>>>>​>>>>>​>>>>
>>>>>​>>>>>​>>>> pro: realtively simple to implement, building up on the
>>>>>​>>>>>​>>>> existing code
>>>>>​>>>>>​>>>> contra: PropelPDO extending PDO is no more used as a
>>>>>​>>>>>​>>>> singe db
>>>>>​>>>>>​>>>> connection
>>>>>​>>>>>​>>>>
>>>>>​>>>>>​>>>> have a look at the two patches attached. they are a
>>>>>​>>>>>​>>>> very first
>>>>>​>>>>>​>>>> draft
>>>>>​>>>>>​>>>> showing the way I would choose.
>>>>>​>>>>>​>>>> http://www.nabble.co​m/file/p13820966/Pro​pel.diff
>>>>>​>>>>>​>>>> Propel.diff
>>>>>​>>>>>​>>>> http://www.nabble.co​m/file/p13820966/Pro​pelPDO.diff
>>>>>​>>>>>​>>>> PropelPDO.diff
>>>>>​>>>>>​>>>>
>>>>>​>>>>>​>>>> please let me know if you'd appreciate any further work
>>>>>​>>>>>​>>>> on
>>>>>​>>>>>​>>>> that matter
>>>>>​>>>>>​>>>> and
>>>>>​>>>>>​>>>> if there are architectural changes/constraints to be
>>>>>​>>>>>​>>>> considered.
>>>>>​>>>>>​>>>>
>>>>>​>>>>>​>>>> cheers
>>>>>​>>>>>​>>>> christian
>>>>>​>>>>>​>>>>
>>>>>​>>>>>​>>>>
>>>>>​>>>>>​>>>> Cameron Brunner wrote:
>>>>>​>>>>>​>>>>
>>>>>​>>>>>​>>>>>​ There is no reason this cant be done purely by
>>>>>​>>>>>​>>>>>​ slotting in a new
>>>>>​>>>>>​>>>>>​ PropelPDO layer with intelligence on what to send the
>>>>>​>>>>>​>>>>>​ query
>>>>>​>>>>>​>>>>>​ to IMO. I
>>>>>​>>>>>​>>>>>​ have thought this out before and it shouldn't be too
>>>>>​>>>>>​>>>>>​ painful
>>>>>​>>>>>​>>>>>​ depending
>>>>>​>>>>>​>>>>>​ upon just how smart you want it.
>>>>>​>>>>>​>>>>>​
>>>>>​>>>>>​>>>>>​ On 11/3/07, Christian Abegg <abegg dot ch at gmail dot com> wrote:
>>>>>​>>>>>​>>>>>​
>>>>>​>>>>>​>>>>>​> hi
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​> i'd like to use my propel app in an environment where
>>>>>​>>>>>​>>>>>​> the
>>>>>​>>>>>​>>>>>​> db-master is
>>>>>​>>>>>​>>>>>​> replicated to one or more slave databases. the master
>>>>>​>>>>>​>>>>>​> gets
>>>>>​>>>>>​>>>>>​> the writing
>>>>>​>>>>>​>>>>>​> statements, the slave gets the reading statements.
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​> in my opinion, the propel layer would be appropriate
>>>>>​>>>>>​>>>>>​> implement that
>>>>>​>>>>>​>>>>>​> function.
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​> as far as i see, there is no such feature in propel.
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​> after a short look into the generated base-classes,
>>>>>​>>>>>​>>>>>​> it seems
>>>>>​>>>>>​>>>>>​> like a
>>>>>​>>>>>​>>>>>​> quite an easy task to implement a read-write splitting.
>>>>>​>>>>>​>>>>>​> assuming that
>>>>>​>>>>>​>>>>>​> all reading queries call the "doSelectStmt" function,
>>>>>​>>>>>​>>>>>​> i'd
>>>>>​>>>>>​>>>>>​> introduce
>>>>>​>>>>>​>>>>>​> the
>>>>>​>>>>>​>>>>>​> DATABASE_NAME_READ-constant which points to the
>>>>>​>>>>>​>>>>>​> configuration of the
>>>>>​>>>>>​>>>>>​> slave-db.
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​> for load balancing between multiple slave-db's i'd
>>>>>​>>>>>​>>>>>​> use the
>>>>>​>>>>>​>>>>>​> mysql-proxy.
>>>>>​>>>>>​>>>>>​> but a simple round robin mechanism could be
>>>>>​>>>>>​>>>>>​> implemented in
>>>>>​>>>>>​>>>>>​> propel as
>>>>>​>>>>>​>>>>>​> well.
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​> i'm not sure wheter this approach could solve my
>>>>>​>>>>>​>>>>>​> problem. a big
>>>>>​>>>>>​>>>>>​> question
>>>>>​>>>>>​>>>>>​> is: are the connection objects cached by propel? or
>>>>>​>>>>>​>>>>>​> is the
>>>>>​>>>>>​>>>>>​> $con-variable
>>>>>​>>>>>​>>>>>​> always null if the user doesn't give a connection on
>>>>>​>>>>>​>>>>>​> the
>>>>>​>>>>>​>>>>>​> application
>>>>>​>>>>>​>>>>>​> layer?
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​> if that enhancement is considered usefull and could be
>>>>>​>>>>>​>>>>>​> implemented
>>>>>​>>>>>​>>>>>​> within reasonable time, i'd be glad to help.
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​> christian abegg
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​> ps: my attempts to add an enhancement ticket failed
>>>>>​>>>>>​>>>>>​> beacaus
>>>>>​>>>>>​>>>>>​> they were
>>>>>​>>>>>​>>>>>​> rejected as spam by trac.
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​> --------------------​--------------------​--------------------​---------
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>>>>>​>>>>>​>>>>>​> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​>
>>>>>​>>>>>​>>>>>​ --
>>>>>​>>>>>​>>>>>​ Cameron Brunner
>>>>>​>>>>>​>>>>>​
>>>>>​>>>>>​>>>>>​ Want a better web browser?
>>>>>​>>>>>​>>>>>​ http://www.spreadfir​efox.com/?q=affiliat​es&id=182780​&t=1
>>>>>​>>>>>​>>>>>​
>>>>>​>>>>>​>>>>>​ --------------------​--------------------​--------------------​---------
>>>>>​>>>>>​>>>>>​
>>>>>​>>>>>​>>>>>​ To unsubscribe, e-mail: dev-
>>>>>​>>>>>​>>>>>​ unsubscribe at propel dot tigris dot org
>>>>>​>>>>>​>>>>>​ For additional commands, e-mail: dev-help at propel dot tigris dot org
>>>>>​>>>>>​>>>>>​
>>>>>​>>>>>​>>>>>​
>>>>>​>>>>>​>>>>>​
>>>>>​>>>>>​>>>>>​
>>>>>​>>>>>​>> --------------------​--------------------​--------------------​---------
>>>>>​>>>>>​>>
>>>>>​>>>>>​>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>>>>>​>>>>>​>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>>>>​>>>>>​>>
>>>>>​>>>>>​>>
>>>>>​>>>>>​>>
>>>>>​>>>>>​>>
>>>>>​>>>>>​> --
>>>>>​>>>>>​> View this message in context:
>>>>>​>>>>>​> http://www.nabble.co​m/r-w-splitting-in-m​aster-slave-db-repli​cation-environment-t​f4740128.html#a14124​959
>>>>>​>>>>>​>
>>>>>​>>>>>​> Sent from the propel - dev mailing list archive at
>>>>>​>>>>>​> Nabble.com.
>>>>>​>>>>>​>
>>>>>​>>>>>​>
>>>>>​>>>>>​>
>>>>>​>>>>>​
>>>>>​>>>>>​ --------------------​--------------------​--------------------​---------
>>>>>​>>>>>​ To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>>>>>​>>>>>​ For additional commands, e-mail: dev-help at propel dot tigris dot org
>>>>>​>>>>>​
>>>>>​>>>>>​
>>>>>​>>>>>​
>>>>>​>>>>
>>>>>​>>>> --------------------​--------------------​--------------------​---------
>>>>>​>>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>>>>>​>>>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>>>>​>>>>
>>>>>​>>>
>>>>>​>>> --------------------​--------------------​--------------------​---------
>>>>>​>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>>>>>​>>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>>>>​>>>
>>>>>​>>>
>>>>>>>
>>>>>>> --------------------​--------------------​--------------------​---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>>>>>>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>>>>>>
>>>>>>
>>>>>> --------------------​--------------------​--------------------​---------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>>>>>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>>>>>
>>>>>
>>>>> --------------------​--------------------​--------------------​---------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>>>>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>>>>
>>>>>
>>>>
>>>> --------------------​--------------------​--------------------​---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>>>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>>>
>>>
>>> --------------------​--------------------​--------------------​---------
>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>>
>>>
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

« Previous message in topic | 23 of 25 | Next message in topic »

Messages

Show all messages in topic

r/w splitting in master-slave db replication environment Christian Abegg <abegg dot ch at gmail dot com> Christian Abegg <abegg dot ch at gmail dot com> 2007-11-02 13:09:28 PDT
     Re: [propel-dev] r/w splitting in master-slave db replication environment Cameron Brunner <cameron dot brunner at gmail dot com> Cameron Brunner <cameron dot brunner at gmail dot com> 2007-11-02 17:23:10 PDT
         Re: [propel-dev] r/w splitting in master-slave db replication environment Christian Abegg <abegg dot ch at gmail dot com> Christian Abegg <abegg dot ch at gmail dot com> 2007-11-18 08:59:06 PST
             Re: [propel-dev] r/w splitting in master-slave db replication environment Christian Abegg <abegg dot ch at gmail dot com> Christian Abegg <abegg dot ch at gmail dot com> 2007-12-02 06:26:12 PST
                 Re: [propel-dev] r/w splitting in master-slave db replication environment hlellelid Hans Lellelid 2007-12-02 17:22:35 PST
                     Re: [propel-dev] r/w splitting in master-slave db replication environment Christian Abegg <abegg dot ch at gmail dot com> Christian Abegg <abegg dot ch at gmail dot com> 2007-12-02 23:29:59 PST
                         Re: [propel-dev] r/w splitting in master-slave db replication environment hlellelid Hans Lellelid 2007-12-03 03:54:52 PST
                         Re: Re: [propel-dev] r/w splitting in master-slave db replication environment Moritz Mertinkat <moritz at mertinkat dot net> Moritz Mertinkat <moritz at mertinkat dot net> 2007-12-04 06:48:31 PST
                             Re: Re: [propel-dev] r/w splitting in master-slave db replication environment Pedram Nimreezi <zenstyle at gmail dot com> Pedram Nimreezi <zenstyle at gmail dot com> 2007-12-04 07:40:31 PST
                             Re: [propel-dev] r/w splitting in master-slave db replication environment Shane Langley <shane dot langley at gmail dot com> Shane Langley <shane dot langley at gmail dot com> 2007-12-04 11:40:14 PST
                                 Re: [propel-dev] r/w splitting in master-slave db replication environment Moritz Mertinkat <moritz at mertinkat dot net> Moritz Mertinkat <moritz at mertinkat dot net> 2007-12-04 12:11:38 PST
                                     Re: [propel-dev] r/w splitting in master-slave db replication environment Shane Langley <shane dot langley at gmail dot com> Shane Langley <shane dot langley at gmail dot com> 2007-12-04 12:48:15 PST
                                         Re: [propel-dev] r/w splitting in master-slave db replication environment hlellelid Hans Lellelid 2007-12-04 13:22:07 PST
                                             Re: [propel-dev] r/w splitting in master-slave db replication environment Christian Abegg <abegg dot ch at gmail dot com> Christian Abegg <abegg dot ch at gmail dot com> 2007-12-10 13:50:26 PST
                                         Re: [propel-dev] r/w splitting in master-slave db replication environment Moritz Mertinkat <moritz at mertinkat dot net> Moritz Mertinkat <moritz at mertinkat dot net> 2007-12-04 13:24:16 PST
                                             Re: [propel-dev] r/w splitting in master-slave db replication environment hlellelid Hans Lellelid 2008-01-04 05:57:21 PST
                                                 Re: [propel-dev] r/w splitting in master-slave db replication environment Christian Abegg <abegg dot ch at gmail dot com> Christian Abegg <abegg dot ch at gmail dot com> 2008-01-06 00:45:46 PST
                                                     Re: [propel-dev] r/w splitting in master-slave db replication environment hlellelid Hans Lellelid 2008-01-06 06:31:58 PST
                                                 Re: [propel-dev] r/w splitting in master-slave db replication environment =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2008-01-07 06:46:19 PST
                                                     Re: [propel-dev] r/w splitting in master-slave db replication environment hlellelid Hans Lellelid 2008-01-07 06:47:37 PST
                                                         Re: [propel-dev] r/w splitting in master-slave db replication environment =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2008-01-07 07:56:22 PST
                                                             Re: [propel-dev] r/w splitting in master-slave db replication environment hlellelid Hans Lellelid 2008-01-07 07:56:27 PST
                                                                 Re: [propel-dev] r/w splitting in master-slave db replication environment =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2008-01-07 08:02:14 PST
                                                                     Re: [propel-dev] r/w splitting in master-slave db replication environment hlellelid Hans Lellelid 2008-01-07 08:06:02 PST
                                                                         Re: [propel-dev] r/w splitting in master-slave db replication environment =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2008-01-07 08:32:56 PST
Messages per page: