On 9/15/2007 4:19 PM, Cyril SCETBON wrote:
> 
> Jan Wieck wrote:
>> On 9/14/2007 3:10 PM, Dmitry Koterov wrote:
>>> MySQL has the "binary log" to which all data is appended before it is 
>>> committed to the real table. All MySQL replicas are simply replaying 
>>> this binary log from a specified position, so it is quite close to 
>>> what Slony does (but Slony uses its own event log, not built-in as in 
>>> MySQL). Seems an asynchronous statement-based replication does not 
>>> exists in the world at all.
>>
>> According to the MySQL 5.1 manual
>>
>>     http://dev.mysql.com/doc/refman/5.1/en/binary-log.html
>>
>> it contains statements. Seems people aren't exactly sure what a 
>> statement is in MySQL land.
>>
>> Then again:
>>
>> "The format of the events recorded in the binary log is dependent on 
>> the binary logging format. Three format types are supported, row-based 
>> logging, statement-based logging and mixed-base logging. The binry 
>> logging format used deoends on the MySQL version. For more information 
>> on logging formats, see Section 5.11.4.1, “Binary Logging Formats”."
>>
>> Which is as best confusing. So different versions support different 
>> logging formats, and they are not all available at the same time? And 
>> what the heck is mixed-based? 
> If you use for example the NDB engine, which is used in MySQL Cluster, 
> MySQL chooses to switch to ROW based statement to provide replication 
> between 2 different clusters.

NDB ... that was the in-memory shared nothing table handler that asked 
for a little more physical RAM than your entire DB is in size, wasn't it?

>> Have MySQL (which is known to make pretty bad judgments when it comes 
>> the integrity and consistency of YOUR data) chose when to aim for row 
>> based and when statement based might be "faster"?
>>
>> Further down it explains that writes to the log are handled like 
>> MyISAM writes. Which doesn't really mean much to me, but maybe someone 
>> can tell if that means that a transaction, done and committed against 
>> InnoDB tables, could be recovered in a server crash situation but lost 
>> from the "binary log"? Or is that something 100% guaranteed 
>> impossible? The manual isn't quite clear about that.
> Binary Log is not guaranteed to be written on disk cause it uses the 
> filesystem cache as MyISAM does. So the situation you described can happen

So that means what? A server crash of the master, although it recovered 
just fine and all InnoDB tables are consistent, forces me to rebuild all 
slaves from scratch because I don't know if I lost any replication log? 
Why doesn't that sound right to me?


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #