diff --git a/Docs/manual.texi b/Docs/manual.texi index 89df7ed532741fd92b3bdc10a1280cf488248cbd..d6e9210e4de858482f10ad7ebb9ad0d8711861f5 100644 --- a/Docs/manual.texi +++ b/Docs/manual.texi @@ -23430,7 +23430,7 @@ check @code{Slave_open_temp_tables} variable to see if it is 0, then issue with @code{SLAVE START} and see if you have better luck next time. There will be a cleaner solution, but it has to wait until version 4.0. -In earlier versions temporary tables are not being replicated properly - we +In earlier versions temporary tables are not replicated properly - we recommend that you either upgrade, or execute @code{SET SQL_LOG_BIN=0} on your clients before all queries with temp tables. @item @@ -23503,11 +23503,6 @@ and @code{FLUSH SLAVE} commands. In Version 3.23.26 we have renamed them to what they do. The old @code{FLUSH} variants still work, though, for compatibility. -@item -Starting in Version 3.23.21, you can use @code{LOAD TABLE FROM MASTER} for -network backup and to set up replication initially. We have recently -received a number of bug reports concerning it that we are investigating, so -we recommend that you use it only in testing until we make it more stable. @item Starting in Version 3.23.23, you can change masters and adjust log position with @code{CHANGE MASTER TO}. @@ -23521,6 +23516,39 @@ with a different name on the slave. @item Starting in Version 3.23.28, you can use @code{PURGE MASTER LOGS TO 'log-name'} to get rid of old logs while the slave is running. +@item +Due to the non-transactional nature of MyISAM tables, it is possible to have +a query that will only partially update a table and return an error code. This +can happen, for example, on a multi-row insert that has one row violating a +key constraint, or if a long update query is killed after updating some of the +rows. If that happens on the master, the slave thread will exit and wait for +the DBA to decide what to do about it unless the error code is legitimate and +the query execution results in the same error code. If this error code +validation behaviour is not desirable, some ( or all) errors could be masked +out with @code{slave-skip-errors} option starting in Version 3.23.47. +@item +While individual tables can be excluded from replication with +@code{replicate-do-table}/@code{replicate-ignore-table} or +@code{replicate-wild-do-table}/@code{replicate-wild-ignore-table}, there +are currently some design deficiencies that in some rather rare cases +produce unexpected results. The replication protocol does not inform the +slave explicitly which tables are going to be modified by the query - so +the slave has to parse the query to know this. To avoid redundant +parsing for queries that will end up actually being executed, table +exclusion is currently implemented by sending the query to the standard +MySQL parser, which will short-circuit the query and report success if +it detects that the table should be ignored. In addition to several +inefficiencies, this approach is also more bug prone, and there are two +known bugs as of Version 3.23.49 - because the parser automatically opens +the table when parsing some queries the ignored table has to exist on +the slave. The other bug is that if the ignored table gets partially +updated, the slave thread will not notice that the table actually should +have been ignored and will suspend the replication process. While the +above bugs are conceptually very simple to fix, we have not yet found a way +to do this without a sigficant code change that would compromize the stability +status of 3.23 branch. There exists a workaround for both if in the rare case +it happens to affect your application - use @code{slave-skip-errors}. + @end itemize