did you ever use mytop?
It would be helfpull too.
Just as question, what says top, when yxou have 800% Usage?
What about IOWAit, swap usage?
on mysql, maybe execute:
mysql> show engine innodb status \G;
Do you have DB Locks? Concurrent access on same data rows?
Maybe also have a look on the myql processes they are running:
mysql> show full ...
service mariadb restart; journalctl -xe
So you can ensure no other messages will push mysql/mariadb output outside the view of -xe.
Maybe database never got initialized.
So it might help to know the content of /etc/my.cnf.
let uns know, where datadir is located.
datadir = /var/lib/mysql
But afaik it changes in some distribution and ...
Suggestions for your my.cnf [mysqld] section
tmp_table_size=128M # from 200M to stay under 1% RAM
max_heap_table_size=128M # from 32M normally matched to tmp_table_size
join_buffer_size=1M # from 200M per connection RAM requested for function
innodb_log_file_size=384M # to be REMOVED, there is another later for 4G
innodb_log_buffer_size=512M # from 1G -...
Benchmarking is tricky business. Some Benchmarks are good at comparing two different hardware/software configurations, but few Benchmarks are good at returning realistic estimates of absolute capability of a system.
This example seems to have slammed the server with 40 identical, CPU-bound, queries within very few milliseconds. Since there are only 24, ...
What if it doesn't bother me to lose some datas ? Loosing like 1 hour of data acquisition is not a problem but I really need the replication to recover automaticaly and with reliability
I don't like this way. Better find out why and stop mariadb to pruge / reset master after restart. That would be the best solution.
Well, create an simple ...
There are several solutions to fix this problem, but not automatically!
But @ first the error message would be helpfull to understand the cause.
Typically the slave tries to reconnect to the master and continues replication by itself. So the question it, what is the current problem?
Solution #1 Skip Error
Dataloss may happen!
I had exactly the same problem when trying to move MariaDB database files to an ISCSI share. When my share was mounted and properly formatted, SELinux tags the directory as system_u:object_r:unlabeled_t. You can check the label of your directory by running the following command... ls -Zd
SELinux does not like surprises. So to get MariaDB running after ...
When SELinux is enabled, your containers' volumes should be placed in subdirectories of /var/lib/docker/volumes. Volumes in your home directory will have SELinux contexts that do not allow Docker containers to access them.
You need to shutdown the container, delete ./mysql/mysql.sock from the host and start it again. For some reason there already is a socket file there and it needs to be removed to start the service correctly.
After looking at the logs via terminal tail -f /var/log/syslog | grep mysql I could see dns resolve errors every few seconds. Adding skip-name-resolve to the mysql.cnf file and restarting the nodes, this issue went away. The reason it started happening up was due to a downstream router blocking internet access to the subnet. This is a closed system but does ...
The innodb_force_recovery server system variable sets the recovery mode. A mode of 0 is normal use, while the higher the mode, the more stringent the restrictions. Higher modes incorporate all limitations of the lower modes.
Generally, it is best to start with a recovery mode of 1, and increase in single increments if needs be. With a recovery mode < 4, ...
Kuba Witek, 800% busy for a short time might be tolerable. Divide your CPU busy (reported by TOP) by core count for effective system busy. To determine your core count, from LX Command Prompt, iostat -xm 5 3 and press enter will usually reveal your core count. For instance 800/12 means your CPU was busy 66% of the time observed. If it stays pegged at 800% ...