On 10/28/2011 05:50 PM, Rick James wrote:
> Anyone happen to understand how (or if) DETERMINISTIC in Stored
> Programs interacts with Replication?
Either DETERMINISTIC, NO SQL, or READS SQL is required (for stored
functions) to be possible to log the creation of the function to the
binary log, but does not really "mean" anything except that. There is no
checking that the function supplied really is deterministic (or does not
contain any SQL or only read SQL).
Just my few cents,
> On 10/28/11 12:03 AM, Johan De Meersman wrote:
>> ----- Original Message -----
>>> From: "Rick James"<rjames@stripped>
>>> The potential flaw in semi-sync is that it acks once the data gets to
>>> the relay log; it does not wait for the write to be applied to the
>>> table. Granted, it would take two serious crashes to cause loss of a
>> Correct, thank you :-)
>> It amazes me how many people run replication, but how little is
>> actually understood about it :-)
>> MySQL's semi-synchronous feature is not that a quorum of slaves
>> confirms the update (as Cassandra does, like Marcus points out); it
>> is semi-synchronous because the slave must acknowledge that it has
>> _received_ the update (ie, written to the relay log), whereas a fully
>> synchronous replication requires that the slave acknowledges that it
>> has _applied_ the update.
>> When the master writes statements to the binary log, most
>> non-deterministic expressions (autoincrement, now(), ...) get
>> replaced by the actual values that were applied; thus ensuring that
>> the slave does indeed apply exactly the same data. Not *all* of those
>> get translated, though - a typical example being "insert as select"
>> where the select has no explicit ordering - and those cases, if you
>> have them, can be accomodated by using row-based replication instead
>> of statement-based. Look at the documentation before making a
>> decision :-)