Determining Root Cause of Aria Recoveries?

I recently migrated (on a WHM Cpanel system) from MySQL to MariaDB (unintentionally as I moved servers and WHM on Almalinux 8 or 9 refaults to MariaDB instead of MySQL - or at least the VDS host's image has it configured that way.) I found that I had out of a couple hundred tables one table with a gazillion fields that made the rows too long for InnoDB, so until I have a chance to edit the fields or break up the table into multiple tables I changed the storage engine to Aria which is supposedly and improved version of MyISAM. (I tried some other config changes but they didn't work so the simplest way was to change the engine to MyISAM or Aria.)

For the first time in 8 years of running my app, I just once saw a message from the PHP script that it couldn't connect to the database. But an immediate reload and it was fine.

So I found the Aria log, and it shows at that precise moment it was doing a recovery that took about 1.5-2 seconds and so I just happen to hit the server during that 2 second period when Aria was doing the recovery. Not surprised it took close to 2 seconds as its the largest table in the DB.

The log shows it's doing a recovery ON AVERAGE once a day. This is a low usage server with maybe 20 users using a custom CRM system. So it's nowhere close to enterprise level usage.

My frustration is there's no information that will help me determine what is the cause of initiating the recovery in the first place? Is there another log that would shed light? Or is this just typical of Aria doing an occasional recovery with most systems? That's not acceptable as even though it's rare to hit the server at the same time, there are a growing number of system users so eventually the probability a user will get the unable to connect to DB message is increasing. Should I just change the engine to MyISAM? I've never in 8 years had any DB corruption issue on MySQL.

Or, should I change back to MySQL. Performance is not a concern on this server. The CPU and RAM is way underutilized and there's maybe only 20 application users at a the same time max.

But I'd still like to know what is triggering the recovery.

Here's the Aria log: 2024-01-26 10:03:41 0 [Note] mariadbd: Aria engine: starting recovery recovered pages: 0% 12% 24% 40% 53% 63% 74% 87% 100% (0.0 seconds); tables to flush: 2 1 0 (0.0 seconds); 2024-01-26 10:03:41 0 [Note] mariadbd: Aria engine: recovery done 2024-01-26 10:03:41 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2024-01-26 10:03:41 0 [Note] InnoDB: Number of pools: 1 2024-01-26 10:03:41 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions 2024-01-26 10:03:41 0 [Note] InnoDB: Using Linux native AIO 2024-01-26 10:03:41 0 [Note] InnoDB: Initializing buffer pool, total size = 2147483648, chunk size = 134217728 2024-01-26 10:03:41 0 [Note] InnoDB: Completed initialization of buffer pool 2024-01-26 10:03:41 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=31696277488,31740145040 2024-01-26 10:03:42 0 [Note] InnoDB: To recover: 6499 pages 2024-01-26 10:03:42 0 [Note] InnoDB: 128 rollback segments are active. 2024-01-26 10:03:42 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1" 2024-01-26 10:03:42 0 [Note] InnoDB: Creating shared tablespace for temporary tables 2024-01-26 10:03:42 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2024-01-26 10:03:42 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. 2024-01-26 10:03:42 0 [Note] InnoDB: 10.6.16 started; log sequence number 31744231888; transaction id 2583251 2024-01-26 10:03:42 0 [Note] Plugin 'FEEDBACK' is disabled. 2024-01-26 10:03:42 0 [Note] Plugin 'unix_socket' is disabled. 2024-01-26 10:03:42 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool 2024-01-26 10:03:42 0 [Note] Server socket created on IP: '0.0.0.0'. 2024-01-26 10:03:42 0 [Note] Server socket created on IP: '::'. 2024-01-26 10:03:43 0 [Note] /usr/sbin/mariadbd: ready for connections.