mirror of
https://github.com/MariaDB/server.git
synced 2025-01-28 17:54:16 +01:00
969669767b
The root cause is the WAL logging of file operation when the actual operation fails afterwards. It creates a situation with a log entry for a operation that would always fail. I could simulate both the backup scenario error and Innodb recovery failure exploiting the weakness. We are following WAL for file rename operation and once logged the operation must eventually complete successfully, or it is a major catastrophe. Right now, we fail for rename and handle it as normal error and it is the problem. I created a patch to address RENAME operation to a non existing schema where the destination schema directory is missing. The patch checks for the missing schema before logging in an attempt to avoid the failure after WAL log is written/flushed. I also checked that the schema cannot be dropped or there cannot be any race with other rename to the same file. This is protected by the MDL lock in SQL today. The patch should this be a good improvement over the current situation and solves the issue at hand. |
||
|---|---|---|
| .. | ||
| archive | ||
| blackhole | ||
| cassandra | ||
| columnstore | ||
| connect | ||
| csv | ||
| example | ||
| federated | ||
| federatedx | ||
| heap | ||
| innobase | ||
| maria | ||
| mroonga | ||
| myisam | ||
| myisammrg | ||
| oqgraph | ||
| perfschema | ||
| rocksdb | ||
| sequence | ||
| sphinx | ||
| spider | ||
| test_sql_discovery | ||
| tokudb | ||