Re: bk commit into 4.1 tree (guilhem:1.1633)

On Sun, Nov 23, 2003 at 05:03:04PM +0100, guilhem@xxxxxxxxx wrote:
> 
> ChangeSet
>   1.1633 03/11/23 17:02:59 guilhem@gbichot2 +6 -0
>   Replication:
>   Now the I/O thread (in flush_master_info()) flushes the relay log to disk
>   after reading every event. Slower but provides additionnal safety in case
>   of brutal crash.
>   I had to make the flush optional (i.e. add a if(some_bool_argument) in the 
> function)
>   because sometimes flush_master_info() is called when there is no usable
>   relay log (the relay log's IO_CACHE is not initialized so can't be flushed).

> @@ -2124,6 +2101,20 @@
>                (int)(mi->ssl), mi->ssl_ca, mi->ssl_capath, mi->ssl_cert,
>                mi->ssl_cipher, mi->ssl_key);
>    flush_io_cache(file);
> +  /*
> +    Flush the relay log to disk. If we don't do it, then the relay log while
> +    have some part (its last kilobytes) in memory only, so if the slave 
> server
> +    dies now, with, say, from master's position 100 to 150 in memory only 
> (not
> +    on disk), and with position 150 in master.info, then when the slave
> +    restarts, the I/O thread will fetch binlogs from 150, so in the relay log
> +    we will have "[0, 100] U [150, infinity[" and nobody will notice it, so 
> the
> +    SQL thread will jump from 100 to 150, and replication will silently 
> break.
> +
> +    When we come to this place in code, relay log may or not be initialized;
> +    the caller is responsible for setting 'flush_relay_log_cache' 
> accordingly.
> +  */
> +  if (flush_relay_log_cache)
> +    flush_io_cache(mi->rli.relay_log.get_log_file());

Shouldn't that flush be done before the flush_io_cache(file) call above,
so that the relay log is flushed before master.info is?

Tim.

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    
http://lists.mysql.com/internals?unsub=gcdmd-internals@xxxxxxxxxxx