[MDEV-23691] S3 storage engine: delayed slave can drop the table Created: 2020-09-08 Updated: 2020-10-21 Resolved: 2020-10-21 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - S3 |
| Affects Version/s: | 10.5 |
| Fix Version/s: | 10.5.7 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Sergei Petrunia | Assignee: | Michael Widenius |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Description |
|
The s3_slave_ignore_updates option is supposed to allow running a master-slave setup where both master and slave are pointed at the same S3 storage. Yet, in some scenarios, slave will drop the table, destroying the data that the master has put there. Put this into suite/s3/rpl_a.cnf:
Put this into suite/s3/rpl_a.test:
|
| Comments |
| Comment by Sergei Petrunia [ 2020-09-08 ] | ||||||||||||||||||
|
Debug printout on the slave (the printout patch: https://gist.github.com/spetrunia/a3a941eeec55273fc806bf88d872e6c3 )
Note that some of these statements might be ignored on the slave. But also note the calls to ha_s3::delete_table(). | ||||||||||||||||||
| Comment by Sergei Petrunia [ 2020-09-08 ] | ||||||||||||||||||
|
A bit more detail about what happens on the slave here:
So, the slave will drop the table in S3 when creating the InnoDB table (the first segment). This is wrong (as the table in S3 might be the newer version that has more data) Then, ALTER TABLE ... engine=s3 is ignored. This is why we get "Table doesn't exist" error in the original testcase. | ||||||||||||||||||
| Comment by Michael Widenius [ 2020-09-12 ] | ||||||||||||||||||
|
The slave should not be able to drop an S3 table. There is a bug in 10.5 introduced with the fix for force drop table that affects S3 that I have been working on fixing for the last two days (hope to have a final patch by tomorrow) | ||||||||||||||||||
| Comment by Michael Widenius [ 2020-10-21 ] | ||||||||||||||||||
|
Pushed into 10.5 tree |