An error occurred fetching the project authors.
- 02 Jun, 2010 1 commit
-
-
Luis Soares authored
When using Unique Keys with nullable parts in RBR, the slave can choose the wrong row to update. This happens because a table with an unique key containing nullable parts cannot strictly guarantee uniqueness. As stated in the manual, for all engines, a UNIQUE index allows multiple NULL values for columns that can contain NULL. We fix this at the slave by extending the checks before assuming that the row found through an unique index is is the correct one. This means that when a record (R) is fetched from the storage engine and a key that is not primary (K) is used, the server does the following: - If K is unique and has no nullable parts, it returns R; - Otherwise, if any field in the before image that is part of K is null do an index scan; - If there is no NULL field in the BI part of K, then return R. A side change: renamed the existing test case file and added a test case covering the changes in this patch.
-
- 27 Sep, 2009 1 commit
-
-
Luis Soares authored
HA_ERR_WRONG_INDEX In RBR, disabling keys on slave table will break replication when updating or deleting a record. When the slave thread tries to find the row, by searching in the storage engine, it checks whether the table has a key or not. If it has one, then the slave thread uses it to search the record. Nonetheless, the slave only checks whether the key exists or not, it does not verify if it is active. Should the key be disabled (eg, DBA has issued an ALTER TABLE ... DISABLE KEYS) then it will result in error: HA_ERR_WRONG_INDEX. This patch addresses this issue by making the slave thread also check whether the key is active or not before actually using it.
-