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 -- discuss@lists.mariadb.org To unsubscribe send an email to discuss-le...@lists.mariadb.org
