replication documentation update

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