Shlomi Noach 1e10f1f29e Solved various race conditions: ... - Operation would terminate after events lock noticed but before applying all events: race condition where the event would be captured asynchronously. The event is now handled sequentially with the DML events, hence now safe. - Multiple rowcopy operations would still write to `rowCopyComplete` channel. This is still the case, but now we only wait for the first and then just flush (read and discard) any others, to avoid blocking - Events DML listener is only added after table creation: the problem was that with very busy tables, the events func buffer would fill up, and the "tables-created" event would be blocked. - `waitForEventsUpToLock()` unifies the waiting on all variants of complete-migration - With `--test-on-replica`, now stopping replication "nicely", using `master_pos_wait()` - With `--test-on-replica`, not throttling on replication after replication is stopped (duh) - More debug output		2016-05-16 11:03:15 +02:00
..
binlog.go	.	2016-04-06 13:05:21 +02:00
connection.go	detecting master (includes sanity checks). Introducing Applier. Creating and altering ghost table	2016-04-04 15:29:02 +02:00
instance_key_map.go	- added throttle-control-replicas flag, a list of control replicas	2016-05-01 21:36:36 +03:00
instance_key.go	- working POC of row-copy iteration cycle	2016-04-06 13:05:58 +02:00
utils.go	Solved various race conditions:	2016-05-16 11:03:15 +02:00