Jan Wieck wrote:
> 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?
it's the engine used in MySQL Cluster which is a shared nothing cluster 
which can used memory and disks for storing data (since 5.1).
>
>>> 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?
I think that it can happen, but I didn't encounter this situation and I 
don't know if there's a link between InnoDB recovery and binary logging 
to resolve this issue. Whenever this happen you can promote a slave to 
be the new master as when you started using MySQL replication you've 
accepted to lose information in case of a master crash. MySQL 
replication is asynchronous and there is no guarantee to not lose data.
>
>
> Jan
>