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 hlellelid
Full name Hans Lellelid
Date 2008-01-07 07:56:27 PST
Message 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@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
>>>>>​>>>>>​>
>>>>>​>>>>>​>
>>>>>​>>>>>​>
>>>>>​>>>>>​>
>>>>>​>>>>>​ --
>>>>>​>>>>>​ 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
>

« Previous message in topic | 22 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: