Merge work:/home/bk/mysql-4.0

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

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}.

@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