There are several newer 10.11 versions since 10.11.10. The most recent is 10.11.13 which was released on 22. May: https://mariadb.com/docs/release-notes/mariadb-community-server-release-notes/mariadb-10-11-series/mariadb-10.11.13-release-notes
I think upgrading to the most recent "patch" version should almost always be the first step when faced with a problem like this. I'm surprised RH hasn't made these newer versions available yet, but you can consider switching from using the versions provided by RH for RHEL9 to versions built and provided by MariaDB Foundation (mariadb.org) for RHEL9. They have a very nifty repo config tool that will create a /etc/yum.repos.d/mariadb.repo file for you here: https://mariadb.org/download/?t=repo-config Karl On Tue, 15 Jul 2025 at 12:42, sacawulu via discuss < [email protected]> wrote: > Hi ajin, > > Thanks for your valuable answer. > > It could very well be that your point 4) applies to us: > > > You’re on 10.11.10—make sure you're on the latest minor build of that > series.Some earlier builds had InnoDB corruption issues, especially when > under VMware disk pressure. > > We are on the version that comes with the OS (RHEL9.6) mariadb 10.11.10, > and there is no more info on minor build versions, only this: > > > MariaDB [(none)]> SELECT VERSION(); > > +------------------+ > > | VERSION() | > > +------------------+ > > | 10.11.10-MariaDB | > > +------------------+ > > 1 row in set (0.000 sec) > > Things have been running quite stable the last months, so that's good, > the sad thing is that we did not really fix anything. :-/ > > Anyway, your reply was appreciated: thank you. We will update when a > newer version comes available. > > MJ > > > On 7/15/25 07:57, ajin.p--- via discuss wrote: > > 1. Check for hardware or virtual layer problems > > > > Even if the VM appears healthy, corruption can stem from: > > > > Underlying storage issues on the VMware host > > > > XFS-specific bugs under high I/O > > > > Bad memory (try memtest86+ if possible) > > > > vSphere snapshot issues (some I/O flush bugs have caused table > corruption) > > > > 2. MariaDB-side logging > > > > Enable these settings to catch file-level errors: > > > > ini > > Copy > > Edit > > innodb_strict_mode = ON > > innodb_force_recovery = 0 # only increase when needed > > log_error = /var/log/mariadb/mariadb.log > > Also, use CHECK TABLE mydb.idm_usc regularly to spot early signs. > > > > 3. Switch storage engine (if possible) > > > > If you're still using MyISAM tables for some data, consider converting > everything to InnoDB, as MyISAM is much more prone to corruption. > > > > sql > > Copy > > Edit > > ALTER TABLE tablename ENGINE=InnoDB; > > 4. Upgrade or patch MariaDB > > > > You’re on 10.11.10—make sure you're on the latest minor build of that > series. Some earlier builds had InnoDB corruption issues, especially when > under VMware disk pressure. > > > > 5. App-level sanity > > > > Although PHP scripts can't cause corruption directly, unsafe query > patterns (like simultaneous large inserts/updates with no transactions) can > stress InnoDB. Review logs or audit for any heavy or abnormal load patterns > around crash time. > > > > As a last resort, if it keeps recurring and CHECK TABLE or REPAIR TABLE > can't fix it, you might consider a repair tool. Some admins have reported > success with Stellar Repair for MySQL, especially when dumps are incomplete > or corruption prevents reads. It can repair InnoDB/MyISAM tables and export > clean SQL for re-import. Learn more : www.stellarinfo.com/mysql-repair.php > > _______________________________________________ > > discuss mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > discuss mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ discuss mailing list -- [email protected] To unsubscribe send an email to [email protected]
