Plugin aria init function returned error

Arch Linux

You are not logged in.

#1 2013-03-25 23:29:10

[SOLVED] Cannot start mysqld after switching to MariaDB

I just switched to MariaDB as recommended.
After installing MariaDB and running

, I get this error message:

Last edited by lonaowna (2013-03-26 01:23:20)

#2 2013-03-25 23:39:28

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

Hi ! I come here because I have a trouble since the last update of Mysqld :
I cannot start the daemon with

I have these problems when i look in journalctl -xn :

When I try with mysqld, I have

And when I look in /var/lib/mysql/server.err I have these lines

When I try mysqld_safe, here is what I get

Resolution
===== It’s a good thing to make a post :
It allows me to order my ideas and I find the solution here http://serverfault.com/questions/104014 … erent-size

I juste deleted the files /var/lib/mysqld/ib_logfile0 and /var/lib/mysql/ib_logfile1
First, I had a problem about the file who is in the future (WTF ?:p) But after, it worked !
Thanks Anyway !

Last edited by shox (2013-03-25 23:51:43)

#3 2013-03-26 00:15:06

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

Merging with the solved Mysqld thread.

Registered Linux User #482438

#4 2013-03-26 01:22:47

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

Thanks! I almost used the same solution: I had to delete

#5 2013-03-27 10:14:33

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

I’ve tried both solutions but I’m still unable to start the mysqld.service
What else can I try?

code for systemctl status mysqld.service

code for journalctl -xn

code for mysql_upgrade

Last edited by Box0 (2013-03-27 10:26:32)

#6 2013-03-27 10:50:09

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

As far as I know, you have to get mysql_upgrade to work. Did you use the -p option? If so, did you get the password typed correctly?

«It is very difficult to educate the educated.»

#7 2013-03-27 12:03:38

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

I get the output posted in my previous message after running both mysql_upgrade and mysql_upgrade -p.

I don’t even reach the step where it asks to insert your password.

#8 2013-06-23 13:29:55

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

Hello,
I have the same problem, Tried all the solutions but didn worked for me.
@Box0: Did you able to find a solution for this ?

#9 2013-07-03 20:55:55

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

Bumping this, as I think solving it will fix my Amarok crashing problem. I’ve only just now got around to switching from the outdated mysql to MariaDB. I tried the solutions here and none of them work.

Here’s my journalctl -xn output:

and the systemctl status for mysqld.service:

Arch Linux Plasma 5 | AMD Ryzen 7 1700 | 16GB DDR4 RAM | Nvidia GeForce GTX 980

#10 2013-10-13 04:36:40

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

I juste deleted the files /var/lib/mysqld/ib_logfile0 and /var/lib/mysql/ib_logfile1
First, I had a problem about the file who is in the future (WTF ?:p) But after, it worked !
Thanks Anyway !

I decided to finally upgrade on the home server and ran into the same exact problem. I can confirm that removing the above two log files also resolved my issue.

#11 2014-07-30 06:31:37

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

OK, so I had a similar error:

Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [Note] Plugin ‘FEEDBACK’ is disabled.
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [ERROR] Can’t open the mysql.plugin table. Please run mysql_upgrade to create it.
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [Note] Recovering after a crash using mysql-bin
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [Note] Starting crash recovery.
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [Note] Crash recovery finished.
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1146: Table ‘mysql.gtid_slave_pos’ doesn’t exist
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [ERROR] Can’t open and lock privilege tables: Table ‘mysql.servers’ doesn’t exist
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [Note] Server socket created on IP: ‘0.0.0.0’.
Jul 29 22:50:22 SMILEplug mysqld[4503]: 140729 22:50:22 [ERROR] Fatal error: Can’t open and lock privilege tables: Table ‘mysql.user’ doesn’t exist
Jul 29 22:50:22 SMILEplug systemd[1]: mysqld.service: main process exited, code=exited, status=1/FAILURE

I solved it with the following commands:

1. Delete everything in /var/lib/mysql
2. mysql_install_db —user=mysql —ldata=/var/lib/mysql/ —basedir=/usr

#12 2014-07-31 20:07:35

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

I had a similar problem and none of the above worked.
Even though I had just installed mariadb and rebooted (shutdown -r now), it seemed that starting over so to speak fixed the problem

sudo systemctl stop mysqld
sudo rm -R /var/lib/mysql
sudo pacman -R mariadb && sudo pacman -S mariadb

Instead of trying to start the service I followed the instructions provided by the mariadb install:

You can start the MariaDB daemon with:
cd ‘/usr’ ; sudo /usr/bin/mysqld_safe —datadir=’/var/lib/mysql’

I then could run the mysql_upgrade as root.

I **haven’t** run the mysqld via systemctl start however.

#13 2016-07-11 13:11:44

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

I have same issue
[suzan@suzzu

]$ sudo systemctl start mysqld
[sudo] password for suzan:
Job for mysqld.service failed because a timeout was exceeded.
See «systemctl status mysqld.service» and «journalctl -xe» for details.
[suzan@suzzu

]$ sudo systemctl status mysqld
[sudo] password for suzan:
* mysqld.service — MariaDB database server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; disabled; vendor preset: disabled)
Active: activating (start-post) (Result: exit-code) since Mon 2016-07-11 18:55:13 NPT; 49s ago
Process: 28647 ExecStart=/usr/bin/mysqld —pid-file=/run/mysqld/mysqld.pid (code=exited, status=1/FAILURE)
Main PID: 28647 (code=exited, status=1/FAILURE); : 28648 (mysqld-post)
Tasks: 2 (limit: 512)
CGroup: /system.slice/mysqld.service
`-control
|-28648 /bin/sh /usr/bin/.
`-29044 sleep 1

Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [Note] Plugin ‘FEEDBACK’ is disabled.
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [ERROR] Could not open mysql.plugin table. Some plugins may be not l
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [Note] Recovering after a crash using mysql-bin
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [Note] Starting crash recovery.
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [Note] Crash recovery finished.
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869392640 [Warning] Failed to load slave replication state from table mysql.gt
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [ERROR] Can’t open and lock privilege tables: Table ‘mysql.servers’
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [Note] Server socket created on IP: ‘::’.
Jul 11 18:55:14 suzzu mysqld[28647]: 2016-07-11 18:55:14 139673869412288 [ERROR] Fatal error: Can’t open and lock privilege tables: Table ‘my
Jul 11 18:55:14 suzzu systemd[1]: mysqld.service: Main process exited, code=exited, status=1/FAILURE
lines 1-21/21 (END)

#14 2016-07-11 13:29:03

Re: [SOLVED] Cannot start mysqld after switching to MariaDB

If the solution that worked for lonaowna doesn’t work for you, then you don’t have the same problem. Open a new topic about your issue and link back to this one if you think it is still relevant after three years.

Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Источник

Тема: По моему убил панель, как восстановить?

Опции темы

Поиск по теме

По моему убил панель, как восстановить?

Решил обновить mariaDB
Обновил по инструкции в инете, все ок, панель ее видит базы работают, нашел ошибки:

[ERROR] mysqld: Can’t lock aria control file ‘/var/lib/mysql/aria_log_control’ for exclusive use, error: 11. Will retry for 0 seconds
[ERROR] Plugin ‘Aria’ init function returned error.
[ERROR] Plugin ‘Aria’ registration as a STORAGE ENGINE failed.
[Warning] Could not open mysql.plugin table: «Unknown storage engine ‘Aria’». Some options may be missing from the help text

начал пробовать найти решение, что сделал конкретно не помню но повредил базу данных сайта.
Что дернуло меня не знаю, видимо усталость было уже утро.
Удалил Mariadb и поставил заново, сайт заработал, все бы ничего но при удалении удалились какие то пакеты ISPmanager, я видел но уже не мог остановить.
Сайт работает, не знаю все ли, типа продления сертификата, и еще чего что зависит от панели.
Сама панель нет, вернее я не могу зайти, пишет:

Не удается получить доступ к сайту
Сайт 193.106.92.73 не позволяет установить соединение..

Запустил то что знаю, результат:

[root@webserver var]# rpm -qa | grep ispmanager
[root@webserver var]#

[root@webserver var]# ps aux | grep core
root 663 0.0 0.0 1979920 16512 ? Sl 02:25 0:15 bin/core core
root 19511 0.0 0.0 112836 984 pts/1 S+ 16:08 0:00 grep —color=auto core

[root@webserver var]# ps aux | grep ihttpd
root 19562 0.0 0.0 112832 984 pts/1 S+ 16:09 0:00 grep —color=auto ihttpd

[root@webserver var]# service ihttpd status
Redirecting to /bin/systemctl status ihttpd.service
Unit ihttpd.service could not be found.

Я любитель, если что то и делаю то по инструкции, тут нештатная для меня ситуация и я завис.

Источник

MariaDB in Tiny Core linux

This article was last edited over 3 years ago. Information here may no longer be accurate. Please proceed with caution, and feel free to contact me.

To use MariaDB with Tiny Core Linux you must provide a data directory that is persistent and writeable. By default, if you install the MariaDB extension and try to run it, you will most likely see an error like this.

I have documented some instructions here that can be used to create a persistent writeable data directory for MariaDB so that it can run properly.

For this to work we need a persistent /opt mount point.

I’m assuming you understand persistence in Tiny Core linux, that you already have persistence working, and that you have enough space on your disk for these instructions to work.

Install MariaDB

Copy MariaDB’s data directory to the persistent opt directory

The data directory in the MariaDB extension has a number of files that are symlinked to readonly files. It is critical that you use the -L flag here as it will copy the symlinked targets rather than the symlinks.

Let’s also delete the existing InnoDB files while we’re at it. Most important to me is that we delete the InnoDB log files as they take up about 100MB, which is much larger than I’d prefer.

We’re going to specify a smaller log file size later on.

Configure MariaDB

Edit /opt/bootlocal.sh and add the following lines.

This is not a “standard” approach for making configuration change in Tiny Core Linux, but I find that it’s the simplest and most reliable.

Make a copy of my.cnf so we can change the configuration.

Uncomment the following line in /opt/mysql/my.cnf so we use a smaller InnoDB log file size.

Reboot to start mysqld

With our changes to bootlocal.sh , mysqld should automatically start up on our next reboot and use our configuration changes.

Voila! mysqld should be running, and you should be able to connect to your server using the mysql client (it may take a couple of seconds before you can connect).

Connect to mysql

From within Tiny Core you should be able to use the mysql client to connect to the server.

Notes

I can confirm that this minimal installation of MariaDB is sufficient to run WordPress, and I will soon post another article explaining how to get WordPress up and running in Tiny Core Linux.

In case you are interested, here is a much more verbose command that can also be used to run mysqld .

Note that this command specifies a —datadir option so that mysqld uses the data directory we setup on /opt . The —innodb_log_file_size is also being explicitly set.

It’s not running!

If the server is not running, check the log file or use ps ax | grep -i mysql to verify mysqld is actually running.

Also, double check your symlinks and the data directory on /opt/mysql .

Why not just leverage Tiny Core’s backup system and use .filetool.lst?

Yes, it is possible to solve this problem without needing to change the location of the data directory. You could edit /opt/.filetool.lst and add usr/local/mysql/data as a persistent directory.

It’s probably just me, but I was seeing some reliability issues with that method. It seemed like my changes to .filetool.lst to persist the data directory were not always loading on reboot.

But more than anything, the reason I decided against that route is that I do not like the idea that I must execute the Tiny Core backup command to save changes to my databases. What if my machine suddenly loses power? None of the MySQL data would be saved because I never had a chance to run backup .

I prefer having data saved to my opt directory. My /opt mount is persistent and mounted directly from an attached disk, and so all changes are saved to that persistent disk immediately. It may decrease the life of my flash drive, but this is a very lightly used server I’m configuring, so I’ll take the risk.

Источник

Laragon – MySQL database not starting after crash – Quick Fix

Cannot find checkpoint record at LSN

When your Laragon app will get shutdown unexpected, it might cause you an issue where MySQL database will not start, and you will be redirected to log file for more details. The most common problem is “Unknown storage engine ‘Aria’”. The solution is very straight forward so don’t get stressed out. The fix is here.

As instructed by Laragon error prompt. Go to the MySQL log.

Could not open mysql.plugin table: “Unknown storage engine ‘Aria’”. Some plugins may be not loaded

The full error log in my case is placed under C:laragon.dvdatamariadb-10.6mysql.log (in default installation it would be placed under C:laragondatamysqlmysql.log ). If you wonder why is my path different it is because i do have multiple instances of laragon installed on my PC in different directory such as laragon.dv, laragon.bc, and laragon (default installation). I also install MariaDB engine instead default MySQL so keep that in mind to not get confused.
The error log would look something like this:

If you find a similar issue in your log file, you are in the right place.
This issue can occur when we shout down PC while having Laragon app started and connected to MySQL database. This will cause a crash on restart. The quick fix to the above issue is simple, to remove all files from our database folder which are prepended with a arial_log text string.

Path to below folder C:laragondatamariadb-10.6 (your path might look differently, like this: C:laragondatamysql depending on what database engine are you using.)

Now remove all files starting with text: arial_log.. .. Like in the example above. Done!
After that, stop and start your Laragon app. Your database should spin again!
Simple as that! If this tutorial did not solve your issue, fallow this instead: “Laragon database crashed“.

Let me know if this post helped solve your issue. Good luck!

Источник

Hi ! I come here because I have a trouble since the last update of Mysqld :
I cannot start the daemon with

sudo systemctl start mysqld

I have these problems when i look in journalctl -xn :

mars 26 00:22:14 server mysqld[11593]: InnoDB: Error: log file ./ib_logfile0 is of different size 0 3174400 bytes
mars 26 00:22:14 server mysqld[11593]: InnoDB: than specified in the .cnf file 0 5242880 bytes!
mars 26 00:22:14 server mysqld[11593]: 130326  0:22:14 [ERROR] Plugin 'InnoDB' init function returned error.
mars 26 00:22:14 server mysqld[11593]: 130326  0:22:14 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
mars 26 00:22:14 server mysqld[11593]: 130326  0:22:14 [ERROR] Unknown/unsupported storage engine: InnoDB
mars 26 00:22:14 server mysqld[11593]: 130326  0:22:14 [ERROR] Aborting
mars 26 00:22:14 server mysqld[11593]: 130326  0:22:14 [Note] /usr/bin/mysqld: Shutdown complete
mars 26 00:22:14 server systemd[1]: mysqld.service: main process exited, code=exited, status=1/FAILURE

When I try with mysqld, I have

130326  0:23:21 [Warning] Can't create test file /var/lib/mysql/server.lower-test
130326  0:23:21 [Warning] Can't create test file /var/lib/mysql/server.lower-test
mysqld: Can't change dir to '/var/lib/mysql/' (Errcode: 13)
130326  0:23:21 [ERROR] Aborting
130326  0:23:21 [Note] mysqld: Shutdown complete

And when I look in /var/lib/mysql/server.err I have these lines

130207 23:32:56 mysqld_safe mysqld from pid file /var/lib/mysql/server.pid ended
130322 00:25:27 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130322  0:25:27 InnoDB: The InnoDB memory heap is disabled
130322  0:25:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130322  0:25:27 InnoDB: Compressed tables use zlib 1.2.7
130322  0:25:27 InnoDB: Initializing buffer pool, size = 128.0M
130322  0:25:27 InnoDB: Completed initialization of buffer pool
130322  0:25:27 InnoDB: highest supported file format is Barracuda.
InnoDB: Error: tried to read 65536 bytes at offset 0 3173376.
InnoDB: Was only able to read 1024.
InnoDB: Fatal error: cannot read from file. OS error number 17.
130322  0:25:30  InnoDB: Assertion failure in thread 139785666135872 in file os0file.c line 2538
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
23:25:30 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 134074 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/bin/mysqld(my_print_stacktrace+0x29)[0x78ae99]
/usr/bin/mysqld(handle_fatal_signal+0x471)[0x67ad71]
/usr/lib/libpthread.so.0(+0xf1e0)[0x7f226299a1e0]
/usr/lib/libc.so.6(gsignal+0x35)[0x7f22615612c5]
/usr/lib/libc.so.6(abort+0x148)[0x7f2261562748]
/usr/bin/mysqld[0x8f2ac0]
/usr/bin/mysqld[0x8af1a0]
/usr/bin/mysqld[0x8e187c]
/usr/bin/mysqld[0x8e75ef]
/usr/bin/mysqld[0x834204]
/usr/bin/mysqld[0x7fe61f]
/usr/bin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x67ccf1]
/usr/bin/mysqld[0x59ad94]
/usr/bin/mysqld(_Z11plugin_initPiPPci+0xa42)[0x59f342]
/usr/bin/mysqld[0x524328]
/usr/bin/mysqld(_Z11mysqld_mainiPPc+0x447)[0x529187]
/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7f226154da15]
/usr/bin/mysqld[0x51ff89]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
130322 00:25:30 mysqld_safe mysqld from pid file /var/lib/mysql/server.pid ended
130326 00:24:58 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130326  0:24:58 InnoDB: The InnoDB memory heap is disabled
130326  0:24:58 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130326  0:24:58 InnoDB: Compressed tables use zlib 1.2.7
130326  0:24:58 InnoDB: Initializing buffer pool, size = 128.0M
130326  0:24:58 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 3174400 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!
130326  0:24:58 [ERROR] Plugin 'InnoDB' init function returned error.
130326  0:24:58 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
130326  0:24:58 [ERROR] Unknown/unsupported storage engine: InnoDB
130326  0:24:58 [ERROR] Aborting

130326  0:24:58 [Note] /usr/bin/mysqld: Shutdown complete

130326 00:24:58 mysqld_safe mysqld from pid file /var/lib/mysql/server.pid ended
130326 00:25:33 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql/
130326  0:25:33 InnoDB: The InnoDB memory heap is disabled
130326  0:25:33 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130326  0:25:33 InnoDB: Compressed tables use zlib 1.2.7
130326  0:25:33 InnoDB: Initializing buffer pool, size = 128.0M
130326  0:25:33 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 3174400 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!
130326  0:25:33 [ERROR] Plugin 'InnoDB' init function returned error.
130326  0:25:33 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
130326  0:25:33 [ERROR] Unknown/unsupported storage engine: InnoDB
130326  0:25:33 [ERROR] Aborting

130326  0:25:33 [Note] /usr/bin/mysqld: Shutdown complete

130326 00:25:33 mysqld_safe mysqld from pid file /var/lib/mysql//server.pid ended

When I try mysqld_safe, here is what I get

130326 00:24:58 mysqld_safe Logging to '/var/lib/mysql/server.err'.
130326 00:24:58 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130326 00:24:58 mysqld_safe mysqld from pid file /var/lib/mysql/server.pid ended

Resolution
===== It’s a good thing to make a post :
It allows me to order my ideas and I find the solution here http://serverfault.com/questions/104014 … erent-size

I juste deleted the files /var/lib/mysqld/ib_logfile0 and /var/lib/mysql/ib_logfile1
First, I had a problem about the file who is in the future (WTF ?:p) But after, it worked !
Thanks Anyway !

Last edited by shox (2013-03-25 23:51:43)

Cannot find checkpoint record at LSN

When your Laragon app will get shutdown unexpected, it might cause you an issue where MySQL database will not start, and you will be redirected to log file for more details. The most common problem is “Unknown storage engine ‘Aria’”. The solution is very straight forward so don’t get stressed out. The fix is here.

As instructed by Laragon error prompt. Go to the MySQL log.

Could not open mysql.plugin table: “Unknown storage engine ‘Aria’”. Some plugins may be not loaded

The full error log in my case is placed under C:laragon.dvdatamariadb-10.6mysql.log (in default installation it would be placed under C:laragondatamysqlmysql.log ). If you wonder why is my path different it is because i do have multiple instances of laragon installed on my PC in different directory such as laragon.dv, laragon.bc, and laragon (default installation). I also install MariaDB engine instead default MySQL so keep that in mind to not get confused.
The error log would look something like this:

Cannot find checkpoint record at LSN (1,0x65548)
2021-12-15 15:03:16 0 [ERROR] mysqld: Aria recovery failed. Please run aria_chk -r on all Aria tables (*.MAI) and delete all aria_log.######## files
2021-12-15 15:03:16 0 [ERROR] Plugin 'Aria' init function returned error.
2021-12-15 15:03:16 0 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
2021-12-15 15:03:16 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2021-12-15 15:03:16 0 [Note] InnoDB: Number of pools: 1
2021-12-15 15:03:16 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2021-12-15 15:03:16 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728
2021-12-15 15:03:16 0 [Note] InnoDB: Completed initialization of buffer pool
2021-12-15 15:03:16 0 [ERROR] InnoDB: Page [page id: space=0, page number=4] log sequence number 234591275 is in the future! Current system log sequence number 185498210.
2021-12-15 15:03:16 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2021-12-15 15:03:16 0 [Note] InnoDB: 128 rollback segments are active.
2021-12-15 15:03:16 0 [ERROR] InnoDB: Page [page id: space=0, page number=465] log sequence number 388269238 is in the future! Current system log sequence number 185498210.
2021-12-15 15:03:16 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2021-12-15 15:03:16 0 [ERROR] InnoDB: Page [page id: space=0, page number=407] log sequence number 388269374 is in the future! Current system log sequence number 185498210.
2021-12-15 15:03:16 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2021-12-15 15:03:16 0 [ERROR] InnoDB: Page [page id: space=0, page number=448] log sequence number 387834748 is in the future! Current system log sequence number 185498210.
2021-12-15 15:03:16 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2021-12-15 15:03:16 0 [ERROR] InnoDB: Page [page id: space=0, page number=470] log sequence number 262503819 is in the future! Current system log sequence number 185498210.
2021-12-15 15:03:16 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2021-12-15 15:03:16 0 [ERROR] InnoDB: Page [page id: space=0, page number=473] log sequence number 387808465 is in the future! Current system log sequence number 185498210.
2021-12-15 15:03:16 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2021-12-15 15:03:16 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2021-12-15 15:03:16 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2021-12-15 15:03:16 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2021-12-15 15:03:16 0 [Note] InnoDB: 10.6.3 started; log sequence number 185498198; transaction id 309973
2021-12-15 15:03:16 0 [Note] Plugin 'FEEDBACK' is disabled.
2021-12-15 15:03:16 0 [Note] InnoDB: Loading buffer pool(s) from C:laragon.dvdatamariadb-10.6ib_buffer_pool
2021-12-15 15:03:16 0 [ERROR] Could not open mysql.plugin table: "Unknown storage engine 'Aria'". Some plugins may be not loaded
2021-12-15 15:03:16 0 [ERROR] Failed to initialize plugins.
2021-12-15 15:03:16 0 [ERROR] Aborting

If you find a similar issue in your log file, you are in the right place.
This issue can occur when we shout down PC while having Laragon app started and connected to MySQL database. This will cause a crash on restart. The quick fix to the above issue is simple, to remove all files from our database folder which are prepended with a arial_log text string.

Path to below folder C:laragondatamariadb-10.6 (your path might look differently, like this: C:laragondatamysql depending on what database engine are you using.)

Now remove all files starting with text: arial_log.... Like in the example above. Done!
After that, stop and start your Laragon app. Your database should spin again!
Simple as that! If this tutorial did not solve your issue, fallow this instead: “Laragon database crashed“.

Let me know if this post helped solve your issue. Good luck!

To use MariaDB with Tiny Core Linux you must provide a data
directory that is persistent and writeable. By default, if you
install the MariaDB extension and try to run it, you will most
likely see an error like this.

150126  3:12:11 [ERROR] mysqld: File '/tmp/tcloop/mariadb/usr/local/mysql/data/aria_log_control' not found (Errcode: 30 "Read-only file system")
150126  3:12:11 [ERROR] mysqld: Got error 'Can't open file' when trying to use aria control file '/tmp/tcloop/mariadb/usr/local/mysql/data/aria_log_control'
150126  3:12:11 [ERROR] Plugin 'Aria' init function returned error.
150126  3:12:11 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.
150126  3:12:11 [Note] InnoDB: Using mutexes to ref count buffer pool pages
150126  3:12:11 [Note] InnoDB: The InnoDB memory heap is disabled
150126  3:12:11 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
150126  3:12:11 [Note] InnoDB: Memory barrier is not used
150126  3:12:11 [Note] InnoDB: Compressed tables use zlib 1.2.8
150126  3:12:11 [Note] InnoDB: Not using CPU crc32 instructions
150126  3:12:11 [Note] InnoDB: Initializing buffer pool, size = 128.0M
150126  3:12:11 [Note] InnoDB: Completed initialization of buffer pool
150126  3:12:11 [ERROR] InnoDB: ./ibdata1 can't be opened in read-write mode
150126  3:12:11 [ERROR] InnoDB: The system tablespace must be writable!
150126  3:12:11 [ERROR] Plugin 'InnoDB' init function returned error.
150126  3:12:11 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
150126  3:12:11 [Note] CONNECT: Version 1.03.0005 Nov 26 2014 11:30:51
150126  3:12:11 [Note] Plugin 'FEEDBACK' is disabled.
150126  3:12:11 [ERROR] Unknown/unsupported storage engine: InnoDB
150126  3:12:11 [ERROR] Aborting

150126  3:12:11 [Note] unregister_replicator OK
150126  3:12:11 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

I have documented some instructions here that can be used to
create a persistent writeable data directory for MariaDB so that
it can run properly.

For this to work we need a persistent /opt mount
point.

I’m assuming you understand persistence in Tiny Core linux,
that you already have persistence working, and that you have
enough space on your disk for these instructions to work.

Install MariaDB

tce-load -wi mariadb mariadb-client

Copy MariaDB’s data directory to the persistent
opt directory

The data directory in the MariaDB extension has a number of files
that are symlinked to readonly files. It is critical that you use
the -L flag here as it will copy the symlinked
targets rather than the symlinks.

mkdir /opt/mysql
cp -Lr /usr/local/mysql/data /opt/mysql/

Let’s also delete the existing InnoDB files while
we’re at it. Most important to me is that we delete the
InnoDB log files as they take up about 100MB, which is much larger
than I’d prefer.

sudo rm -rf /opt/mysql/data/ib*

We’re going to specify a smaller log file size later on.

Configure MariaDB

Edit /opt/bootlocal.sh and add the following lines.

# MySQL
rm -rf /usr/local/mysql/data
ln -s /opt/mysql/data /usr/local/mysql/data
ln -sf /opt/mysql/my.cnf /usr/local/mysql/my.cnf
sudo -u tc /usr/local/mysql/bin/mysqld_safe 2>&1 > /dev/null &

This is not a “standard” approach for making
configuration change in Tiny Core Linux, but I find that
it’s the simplest and most reliable.

Make a copy of my.cnf so we can change the
configuration.

sudo cp /usr/local/share/mariadb/my.cnf /opt/mysql/

Uncomment the following line in /opt/mysql/my.cnf so
we use a smaller InnoDB log file size.

innodb_log_file_size = 5M

Reboot to start mysqld

With our changes to bootlocal.sh,
mysqld should automatically start up on our next
reboot and use our configuration changes.

sudo reboot

Voila! mysqld should be running, and you should be
able to connect to your server using the mysql client
(it may take a couple of seconds before you can connect).

Connect to mysql

From within Tiny Core you should be able to use the
mysql client to connect to the server.

mysql -u root

Notes

I can confirm that this minimal installation of MariaDB is
sufficient to run WordPress, and I will soon post another article
explaining how to get WordPress up and running in Tiny Core Linux.

In case you are interested, here is a much more verbose command
that can also be used to run mysqld.

/usr/local/mysql/bin/mysqld 
  --basedir=/usr/local/mysql 
  --datadir=/opt/mysql/data 
  --plugin-dir=/usr/local/mysql/lib/plugin 
  --log-error=/var/log/mysql.err 
  --pid-file=/var/run/mysql.pid 
  --socket=/tmp/mysql.sock 
  --innodb_log_file_size=5M 
  --port=3306 &

Note that this command specifies a --datadir option
so that mysqld uses the data directory we setup on
/opt. The --innodb_log_file_size is also
being explicitly set.

It’s not running!

If the server is not running, check the log file or use
ps ax | grep -i mysql to verify
mysqld is actually running.

Also, double check your symlinks and the data directory on
/opt/mysql.

Why not just leverage Tiny Core’s backup system and use
.filetool.lst?

Yes, it is possible to solve this problem without needing to
change the location of the data directory. You could edit
/opt/.filetool.lst and add
usr/local/mysql/data as a persistent directory.

It’s probably just me, but I was seeing some reliability
issues with that method. It seemed like my changes to
.filetool.lst to persist the
data directory were not always loading on reboot.

But more than anything, the reason I decided against that route is
that I do not like the idea that I must execute the Tiny Core
backup command to save changes to my databases. What
if my machine suddenly loses power? None of the MySQL data would
be saved because I never had a chance to run backup.

I prefer having data saved to my opt directory. My
/opt mount is persistent and mounted directly from an
attached disk, and so all changes are saved to that persistent
disk immediately. It may decrease the life of my flash drive, but
this is a very lightly used server I’m configuring, so
I’ll take the risk.

root@localhost:/var/log/mysql# cat error.log

2020—01—19  6:18:46 0 [ERROR] mysqld: Can‘t lock aria control file ‘/var/lib/mysql/aria_log_control‘ for exclusive use, error: 11. Will retry for 30 seconds

2020-01-19  6:19:17 0 [ERROR] mysqld: Got error ‘Could not get an exclusive lock; file is probably in use by another process‘ when trying to use aria control file ‘/var/lib/mysql/aria_log_control‘

2020-01-19  6:19:17 0 [ERROR] Plugin ‘Aria‘ init function returned error.

2020-01-19  6:19:17 0 [ERROR] Plugin ‘Aria‘ registration as a STORAGE ENGINE failed.

2020-01-19  6:19:17 0 [Note] InnoDB: Using Linux native AIO

2020-01-19  6:19:17 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins

2020-01-19  6:19:17 0 [Note] InnoDB: Uses event mutexes

2020-01-19  6:19:17 0 [Note] InnoDB: Compressed tables use zlib 1.2.11

2020-01-19  6:19:17 0 [Note] InnoDB: Number of pools: 1

2020-01-19  6:19:17 0 [Note] InnoDB: Using SSE2 crc32 instructions

2020-01-19  6:19:17 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M

2020-01-19  6:19:17 0 [Note] InnoDB: Completed initialization of buffer pool

2020-01-19  6:19:17 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().

2020-01-19  6:19:17 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=2137316301

2020-01-19  6:19:17 0 [Note] InnoDB: 128 out of 128 rollback segments are active.

2020-01-19  6:19:17 0 [Note] InnoDB: Removed temporary tablespace data file: «ibtmp1»

2020-01-19  6:19:17 0 [Note] InnoDB: Creating shared tablespace for temporary tables

2020-01-19  6:19:17 0 [Note] InnoDB: Setting file ‘./ibtmp1‘ size to 12 MB. Physically writing the file full; Please wait …

2020-01-19  6:19:17 0 [Note] InnoDB: File ‘./ibtmp1‘ size is now 12 MB.

2020-01-19  6:19:17 0 [Note] InnoDB: Waiting for purge to start

2020-01-19  6:19:17 0 [Note] InnoDB: 10.3.18 started; log sequence number 2137316310; transaction id 2275296

2020-01-19  6:19:17 0 [Note] Plugin ‘FEEDBACK‘ is disabled.

2020—01—19  6:19:17 0 [ERROR] Aria engine is not enabled or did not start. The Aria engine must be enabled to continue as mysqld was configured with —with—aria—tmp—tables

2020—01—19  6:19:17 0 [ERROR] Aborting

root@localhost:/var/log/mysql#