@@ -1186,6 +1186,26 @@ int init_relay_log_info(RELAY_LOG_INFO* rli, const char* info_fname)
1186
1186
strmov (strcend (tmp,' .' )," -relay-bin" );
1187
1187
opt_relay_logname=my_strdup (tmp,MYF (MY_WME));
1188
1188
}
1189
+
1190
+ /*
1191
+ The relay log will now be opened, as a SEQ_READ_APPEND IO_CACHE. It is
1192
+ notable that the last kilobytes of it (8 kB for example) may live in memory,
1193
+ not on disk (depending on what the thread using it does). While this is
1194
+ efficient, it has a side-effect one must know:
1195
+ the size of the relay log on disk (displayed by 'ls -l' on Unix) can be a
1196
+ few kilobytes less than one would expect by doing SHOW SLAVE STATUS; this
1197
+ happens when only the IO thread is started (not the SQL thread). The
1198
+ "missing" kilobytes are in memory, are preserved during 'STOP SLAVE; START
1199
+ SLAVE IO_THREAD', and are flushed to disk when the slave's mysqld stops. So
1200
+ this does not cause any bug. Example of how disk size grows by leaps:
1201
+
1202
+ Read_Master_Log_Pos: 7811 -rw-rw---- 1 guilhem qq 4 Jun 5 16:19 gbichot2-relay-bin.002
1203
+ ...later...
1204
+ Read_Master_Log_Pos: 9744 -rw-rw---- 1 guilhem qq 8192 Jun 5 16:27 gbichot2-relay-bin.002
1205
+
1206
+ See how 4 is less than 7811 and 8192 is less than 9744.
1207
+ */
1208
+
1189
1209
if (open_log (&rli->relay_log , glob_hostname, opt_relay_logname,
1190
1210
" -relay-bin" , opt_relaylog_index_name,
1191
1211
LOG_BIN, 1 /* read_append cache */ ,
0 commit comments