re-using unused LOCK_active_mi to serialize all administrative
commands related to replication:
START SLAVE, STOP SLAVE, RESET SLAVE, CHANGE MASTER, init_slave()
(replication autostart at server startup), end_slave() (replication
autostop at server shutdown), LOAD DATA FROM MASTER.
This protects us against a handful of deadlocks (like BUG#2921
when two START SLAVE, but when two STOP SLAVE too).
Removing unused variables.
ChangeSet 1.1620.12.1 and ChangeSet 1.1625.2.1
from 4.1. This makes the slave I/O thread flush the relay log
after every event, which provides additional safety in case
of brutal crash (reduces chances to lose a part of the relay log).
- the one about BUG#2921
- the one about relay log flushing
Both will be rewritten in a next changeset
(this one will not be pushed before the next changeset).
INSERT DELAYED works only for one-row inserts (in latest 4.0 versions
at least). So killing a delayed_insert thread does not spoil replication:
the rows which actually went into the table are exactly those listed
in the binlog. So when the delayed_insert thread is killed, don't log
it as 'killed', because it causes superfluous stops on the slave.
Allow one to force lower_case_table_names to 0, even if the file system is case insensitive. This fixes some issues on Mac OS X (Bug #2994)
Added variables "lower_case_file_system", "version_compile_os" and "license"
even if the thread was killed, we write the DROP with error_code=0.
This will remove unneeded stops on slave, and will lose nothing:
if a real update was killed, this real update will be logged with the
nonzero error code and will cause the stop on slave.
"(binlog, position) stored by InnoDB for a replication slave can be wrong".
This code contains conditional #if to distinguish between versions;
it should be merged into 4.1 and 5.0.
Make the drop InnoDB database operation aware of the setting FOREIGN_KEY_CHECKS=0; DROP DATABASE seems to work ok anyway, but that is because MySQL first calls DROP TABLE for each table which has an .frm file
Allow always DROPping of a table which is only referenced by FOREIGN KEY constraints from the same table
Many files:
Do not let REPLACE to perform internally an UPDATE if the table is referenced by a FOREIGN KEY: the manual says that REPLACE must resolve a duplicate key error semantically with DELETE(s) + INSERT, and not by an UPDATE; the internal update caused foreign key checks and cascaded operations to behave in a semantically wrong way
