[MDEV-20983] Page 38:4016 may be corrupted. Post encryption checksum 3690179534 stored Created: 2019-11-05 Updated: 2019-11-06 Resolved: 2019-11-06 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Encryption, Storage Engine - InnoDB |
| Affects Version/s: | 10.2.8 |
| Fix Version/s: | 10.4.1, 10.1.38, 10.2.20, 10.3.12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Emmanuel Torre | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | corruption, encryption, innodb, need_feedback | ||
| Environment: |
RH Linux 3.10.0-957.21.3.el7.x86_64, VMWare |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
hi In a Mariadb replication setup (1 master, 1 slave) We got an for no obvious reason, no HW failure or anything noticeable at OS level. Then a bit later : Got error 192 when reading table We had to switch role to let the application operate again. That went OK, although we lost the rows that could not be replicated for the corrupted table. After a while, the old master that was promoted to slaved crashed an could not be restarted, besides using recovery level 6. We ended resyncing with full backup but the issue is scary. Asking for analysis and feedback. Thank you |
| Comments |
| Comment by Elena Stepanova [ 2019-11-05 ] | |
|
10.2.8 is over 2 years old and 20 releases behind the current one. There have been numerous bugfixes since then, specifically around encryption. Please upgrade to a current version and report a bug against it if the problem persists. | |
| Comment by Marko Mäkelä [ 2019-11-06 ] | |
|
The first line of before_innocrash_20191105.txt
Note: it is showing the same checksum in all 3 places. This message is a telltale sign of severely broken logic. The code wrongly assumed that it would be impossible for the checksum of the data payload to be the same both before and after encryption. In fact, the probability of that is at least 1/4,294,967,296 (actually much more, due to checksum sloppiness issues that were addressed in The broken logic was fixed in a follow-up fix to | |
| Comment by Emmanuel Torre [ 2019-11-06 ] | |
|
thank you for the responses and explanations. We willl naturally upgrade. |