MySQL InnoDB Weird Query Performance

I designed two tables, both using InnoDB. The first one has columns “Offset, Size, and ColumnToBeIndexed” with BIGINT “Offset” being the primary key, and the second one has columns “OffsetAndSize, and ColumnToBeIndexed” with BIGINT “OffsetAndSize” being the primary key. And there are both 15 millions rows in each table. I added indexes to both tables on “ColumnToBeIndexed.”My two queries for them are “SELECT Offset, Size FROM someTable WHERE ColumnToBeIndex BETWEEN 20 AND 10000 ORDER BY Offset ASC” and “SELECT OffsetAndSize FROM someTable WHERE ColumnToBeIndex BETWEEN 20 AND 10000 ORDER BY OffsetAndSize ASC.” Because the second query could use the secondary index and does not need to look up the clustered index to find the “size” information, I expected that the second query on the second table performs better than the first query on the first table. However, as the test came out, it turned out that the first query performs better every single time. Does anybody out there know what seems to be the problem?

MySQL innoDB cluster auto rejoin failed

3 node cluster, single primary. heavy read/write was happening on the master node. Restart the Master node. Then node 3 became the master. After the restart, the old master was in recovery state

"recoveryStatusText": "Distributed recovery in progress",                  "role": "HA",                  "status": "RECOVERING"    select * from gr_member_routing_candidate_status; +------------------+-----------+---------------------+----------------------+ | viable_candidate | read_only | transactions_behind | transactions_to_cert | +------------------+-----------+---------------------+----------------------+ | NO               | YES       |                   0 |                 8401 | +------------------+-----------+---------------------+----------------------+ 

this trx_to_cert never decreased even after 15mins,

then I tried to reboot node2

this also went to recovery mode.

Finally restart the node3, that’s all

It is saying no eligible primary in the cluster. Not able to recover it.

ERROR LOG:

2020-06-03T15:24:19.735261Z 2 [Note] Plugin group_replication reported: '[GCS] Configured number of attempts to join: 0' 2020-06-03T15:24:19.735271Z 2 [Note] Plugin group_replication reported: '[GCS] Configured time between attempts to join: 5 seconds' 2020-06-03T15:24:19.735285Z 2 [Note] Plugin group_replication reported: 'Member configuration: member_id: 1; member_uuid: "41add3fb-9abc-11ea-a59d-42010a00040b"; single-primary mode: "true"; group_replication_auto_increment_increment: 7; ' 2020-06-03T15:24:19.748017Z 6 [Note] 'CHANGE MASTER TO FOR CHANNEL 'group_replication_applier' executed'. Previous state master_host='<NULL>', master_port= 0, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='<NULL>', master_port= 0, master_log_file='', master_log_pos= 4, master_bind=''. 2020-06-03T15:24:19.846752Z 9 [Note] Slave SQL thread for channel 'group_replication_applier' initialized, starting replication in log 'FIRST' at position 0, relay log './dev-mysql-01-relay-bin-group_replication_applier.000002' position: 4 2020-06-03T15:24:19.846765Z 2 [Note] Plugin group_replication reported: 'Group Replication applier module successfully initialized!' 2020-06-03T15:24:19.868161Z 0 [Note] Plugin group_replication reported: 'XCom protocol version: 3' 2020-06-03T15:24:19.868183Z 0 [Note] Plugin group_replication reported: 'XCom initialized and ready to accept incoming connections on port 33061' 2020-06-03T15:24:21.722047Z 2 [Note] Plugin group_replication reported: 'This server is working as secondary member with primary member address dev-mysql-03:3306.' 2020-06-03T15:24:21.722179Z 0 [ERROR] Plugin group_replication reported: 'Group contains 3 members which is greater than auto_increment_increment value of 1. This can lead to an higher rate of transactional aborts.' 2020-06-03T15:24:21.722427Z 24 [Note] Plugin group_replication reported: 'Establishing group recovery connection with a possible donor. Attempt 1/10' 2020-06-03T15:24:21.722550Z 0 [Note] Plugin group_replication reported: 'Group membership changed to dev-mysql-01:3306, dev-mysql-03:3306, dev-mysql-02:3306 on view 15910200188085516:19.' 2020-06-03T15:24:21.803914Z 24 [Note] 'CHANGE MASTER TO FOR CHANNEL 'group_replication_recovery' executed'. Previous state master_host='<NULL>', master_port= 0, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='dev-mysql-02', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''. 2020-06-03T15:24:21.855802Z 24 [Note] Plugin group_replication reported: 'Establishing connection to a group replication recovery donor bd472ec4-9abc-11ea-976d-42010a00040c at dev-mysql-02 port: 3306.' 2020-06-03T15:24:21.856155Z 26 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information. 2020-06-03T15:24:21.862169Z 26 [Note] Slave I/O thread for channel 'group_replication_recovery': connected to master 'mysql_innodb_cluster_1@dev-mysql-02:3306',replication started in log 'FIRST' at position 4 2020-06-03T15:24:21.918855Z 27 [Note] Slave SQL thread for channel 'group_replication_recovery' initialized, starting replication in log 'FIRST' at position 0, relay log './dev-mysql-01-relay-bin-group_replication_recovery.000001' position: 4 2020-06-03T15:24:42.718769Z 0 [Note] InnoDB: Buffer pool(s) load completed at 200603 15:24:42 2020-06-03T15:24:55.206155Z 41 [Note] Got packets out of order 2020-06-03T15:29:29.682585Z 0 [Warning] Plugin group_replication reported: 'Members removed from the group: dev-mysql-02:3306' 2020-06-03T15:29:29.682635Z 0 [Note] Plugin group_replication reported: 'The member with address dev-mysql-02:3306 has unexpectedly disappeared, killing the current group replication recovery connection' 2020-06-03T15:29:29.682635Z 0 [Note] Plugin group_replication reported: 'The member with address dev-mysql-02:3306 has unexpectedly disappeared, killing the current group replication recovery connection' 2020-06-03T15:29:29.682729Z 27 [Note] Error reading relay log event for channel 'group_replication_recovery': slave SQL thread was killed 2020-06-03T15:29:29.682759Z 0 [Note] Plugin group_replication reported: 'Group membership changed to dev-mysql-01:3306, dev-mysql-03:3306 on view 15910200188085516:20.' 2020-06-03T15:29:29.683116Z 27 [Note] Slave SQL thread for channel 'group_replication_recovery' exiting, replication stopped in log 'mysql-bin.000009' at position 846668856 2020-06-03T15:29:29.689073Z 26 [Note] Slave I/O thread killed while reading event for channel 'group_replication_recovery' 2020-06-03T15:29:29.689089Z 26 [Note] Slave I/O thread exiting for channel 'group_replication_recovery', read up to log 'mysql-bin.000009', position 846668856 2020-06-03T15:29:29.700329Z 24 [Note] Plugin group_replication reported: 'Retrying group recovery connection with another donor. Attempt 2/10' 

How to improve performance for read only innodb MySQL Database

I have a particular task which is to maximize the concurrent performance. There is only one particular type of query, which is

select * from table where col1 between ? and ? and col2 between ? and ? 

I have created a composite index for (col1, col2). The table is about 20G in size and 100 million rows

However, even in peak concurrent requests, the CPU utilization for MySQL is only 30%. I have tried various techniques like increase max_connections, innodb_buffer_pool_instances but none of them are working.

How to maximize the configuration so that it can perform such read-only query to extreme?

MySQL 5.6 row format changes when changing storage engine from MyISAM to InnoDB

I am testing an upgrade of all existing MySQL 5.6 tables from MyISAM to InnoDB. I converted all row formats to ‘dynamic’ first for all the tables to be on Barracuda then running “alter table engine = InnoDB” for 16 tables. 12 of the 16 tables changed file formats as well without an alter table command. I am at a loss to understand this. I think this may be related to the .frm files, but I’m not sure how. I’ve checked environment variables:

innodb_file_format is showing Barracuda

innodb_file_format_check is ON

A couple of the tables: Articletranslations is showing as compressed, pubmedabstractauthors and pubmedtranslated are showing as compact. The create table statements from tables that I had changed to dynamic file format before changing the storage engine to InnoDB.

Table: articletranslations

Create Table: CREATE TABLE `articletranslations` (   `TranslationID` int(11) NOT NULL AUTO_INCREMENT,   `ArticleID` int(11) NOT NULL,   `language` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,   `TextContent` longtext COLLATE utf8_unicode_ci,   `Name` text COLLATE utf8_unicode_ci,   `Tags` varchar(1000) COLLATE utf8_unicode_ci DEFAULT NULL,   `Detail_Abstract` longtext COLLATE utf8_unicode_ci,   `Disclosures` varchar(2000) COLLATE utf8_unicode_ci DEFAULT NULL,   `Discussion` longtext COLLATE utf8_unicode_ci,   `Acknowledgements` longtext COLLATE utf8_unicode_ci,   `D` longtext COLLATE utf8_unicode_ci,   `Materials` text COLLATE utf8_unicode_ci,   `HTMLTopContent` text COLLATE utf8_unicode_ci,   `Rep_Results` longtext COLLATE utf8_unicode_ci,   `Introduction` text COLLATE utf8_unicode_ci,   `IsMachine` tinyint(1) NOT NULL DEFAULT '1',   `DateTranslated` datetime DEFAULT CURRENT_TIMESTAMP,   PRIMARY KEY (`TranslationID`),   KEY `ArticleTranslations_Language_ArticleID` (`language`,`ArticleID`),   KEY `ArticleTranslations_ArticleID` (`ArticleID`) ) ENGINE=InnoDB AUTO_INCREMENT=177437 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ROW_FORMAT=COMPRESSED 

Table: pubmedabstractauthors

Create Table: CREATE TABLE `pubmedabstractauthors` (   `AuthorID` int(11) NOT NULL AUTO_INCREMENT,   `ForeName` varchar(255) NOT NULL,   `LastName` varchar(255) NOT NULL,   `Initials` varchar(255) NOT NULL,   PRIMARY KEY (`AuthorID`),   KEY `names` (`ForeName`,`LastName`,`Initials`) ) ENGINE=InnoDB AUTO_INCREMENT=712515 DEFAULT CHARSET=latin1 

Table: pubmedtranslated

Create Table: CREATE TABLE `pubmedtranslated` (   `PMID` int(11) NOT NULL,   `ArticleTitle` text COLLATE utf8_unicode_ci NOT NULL,   `ArticleAbstract` text COLLATE utf8_unicode_ci NOT NULL,   `LanguageID` smallint(6) NOT NULL,   PRIMARY KEY (`PMID`,`LanguageID`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci 

MySQL import – all rows missing except those in final INSERT of InnoDB tables

This is a very strange bug. I’m using this on a mac:

mysql Ver 15.1 Distrib 10.4.6-MariaDB, for osx10.13 (x86_64)

If I import an SQL dump of a WordPress DB (so not very complicated structure, but some long lines) from the command line, the table structure for all tables appears normal, but lots of content is missing from InnoDB tables.

Specifically, where the INSERTS have been ‘chunked’ into groups of records, only the final group is there. If I use --skip-extended-insert to write a statement for every record, only one record is ever in the InnoDB table.

MyISAM data seems fine.

I’ve tried dropping and recreating the database, could there be some corruption elsewhere?

Mysql 5.7.25 crash on first query to corrupted innodb table

Setup:

Ubuntu 18.04.1 LTS 4.15.0-34-generic #37-Ubuntu Docker: 18.06.1-ce build e68fc7a mysql:5@sha256:e47e309f72c831cf880cc0e1990b9c5ac427016acdc71346a36c83806ca79bb4  mysql --version = Ver 14.14 Distrib 5.7.25, for Linux (x86_64) using  EditLine wrapper 

Log:

07:17:39 UTC - mysqld got signal 11 ; 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. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail.  key_buffer_size=8388608 read_buffer_size=131072 max_used_connections=6 max_threads=151 thread_count=5 connection_count=5 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68196 K  bytes of memory Hope that's ok; if not, decrease some variables in the equation.  Thread pointer: 0x7f9814012240 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 = 7f98580a4e80 thread_stack 0x40000 mysqld(my_print_stacktrace+0x2c)[0x560da4deb81c] mysqld(handle_fatal_signal+0x479)[0x560da4716879] /lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7f987679b0c0] mysqld(_Z32page_cur_search_with_match_bytesPK11buf_block_tPK12dict_index_tPK8dtuple_t15page_cur_mode_tPmS9_S9_S9_P10page_cur_t+0x167)[0x560da4eb2be7] mysqld(_Z27btr_cur_search_to_nth_levelP12dict_index_tmPK8dtuple_t15page_cur_mode_tmP9btr_cur_tmPKcmP5mtr_t+0x989)[0x560da4fd81a9] mysqld(+0xe682d9)[0x560da4f2c2d9] mysqld(_Z15row_search_mvccPh15page_cur_mode_tP14row_prebuilt_tmm+0x1b9e)[0x560da4f3307e] mysqld(_ZN11ha_innobase10index_readEPhPKhj16ha_rkey_function+0x244)[0x560da4e2ee24] mysqld(_ZN7handler17ha_index_read_mapEPhPKhm16ha_rkey_function+0x30f)[0x560da476830f] mysqld(+0xac68f4)[0x560da4b8a8f4] mysqld(_Z10sub_selectP4JOINP7QEP_TABb+0x105)[0x560da4b8dbb5] mysqld(_ZN4JOIN4execEv+0x370)[0x560da4b86a30] mysqld(_Z12handle_queryP3THDP3LEXP12Query_resultyy+0x233)[0x560da4bf5eb3] mysqld(+0x61cf32)[0x560da46e0f32] mysqld(_Z21mysql_execute_commandP3THDb+0x460d)[0x560da4bb972d] mysqld(_Z11mysql_parseP3THDP12Parser_state+0x395)[0x560da4bbbff5] mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0xfc4)[0x560da4bbd0b4] mysqld(_Z10do_commandP3THD+0x197)[0x560da4bbe487] mysqld(handle_connection+0x278)[0x560da4c7af38] mysqld(pfs_spawn_thread+0x1b4)[0x560da5153164] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494)[0x7f9876791494] /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f9874fddacf]  Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (7f98141c3520): SELECT `id`, `state`, `param`, `cursor_row`, `cursor_column`, `can_send`, `createdAt`, `updatedAt`, `userId`, `botId` FROM `states` AS `state` WHERE `state`.`userId` = 131913 AND `state`.`botId` = 3202 LIMIT 1 Connection ID (thread ID): 863486 Status: NOT_KILLED  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. 

Probebly unrelated but repeated a lot:

2019-06-12T14:52:32.090130Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 10295ms. The settings might not be optimal. (flushed=9 and evicted=0, during the time.) 2019-06-12T14:53:56.177026Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 8427ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) 2019-06-12T15:03:05.055209Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 6080ms. The settings might not be optimal. (flushed=3 and evicted=0, during the time.) 2019-06-12T15:03:52.398646Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5042ms. The settings might not be optimal. (flushed=168 and evicted=0, during the time.) 

more logs and settings


Default settings from the docker have not been changed. It runs fine and queries to all unaffected tables work fine, but any queries, even CHECK TABLE on the affected table crashed the server instantly.

I haven’t attempted data recovery and simply dropped and restored the table from backups. However, this is the second time in 2 months that this has happened (to different tables, but both were tables with more writes compared to the rest).

How can I diagnose the cause of corruption or make it less likely?

What I’ve checked so far:

  • The included log is the first sign of anything going wrong, the previous log entry is from 30min before and unrelated. And while crash with a corrupted table is reproducible I have no way of reproducing the corruption and higher log verbosity is unideal on the production server under load.
  • dmesg | egrep -i 'killed process' is empty, the box has 4gb of ram and swap enabled. I don’t think the tables got corrupted due to oom kill in the middle of a write.

innodb file per table

We are running with shared tablespace on MySQL database server in our environment. We are looking to enable file per table on database. We want to know

  • What would be ideal plan to enable file per table on server ?
  • What would be the consequences for same ?
  • Is their precautionary steps to be performed ?
  • If any issue occurs how can we revert to shared tablespace ?

Database Statistics :

Logical DB size : 860 GB Physical DB size : 1450 GB

InnoDB Non Locking Select Statement Using db_query in Drupal 6

From a thread on stackoverflow, I found a way to implement Select query in InnoDB table without locking.
Ref: https://stackoverflow.com/questions/917640/any-way-to-select-without-causing-locking-in-mysql/918092

The example statement given there was this:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ; SELECT * FROM TABLE_NAME ; COMMIT 

Now if I want to implement a similar statement using db_query() can I do so by issuing three consecutive calls like this

db_query("SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED") db_query("SELECT * FROM TABLE_NAME") db_query("COMMIT") 

Note: db_query doesn’t support multi line statements on Drupal 6.

Espaço consumido MyISAM vs InnoDB

No MYSQL versão 5.7 o engine InnoDB ainda consome muito mais espaço em disco que o engine MyISAM?

Tenho uma tabela com engine MyISAM com 70 mil inserts por dia e por isso, estou querendo mudar para InnoDB por ter um desempenho superior em escrita, mas sera que o desempenho de escrita no InnoDB vai compensar tanto que o MyISAM? já que com a mudança para InnoDB o aumento de espaço em disco consumido será significativo.

MariaDB 10.3 InnoDB random crash due to memory exhaust on VPS

after migrating to new VPS my server occassionally experiences database crashes. This may happen 1-2x in 2-3 days. Server runs MariaDB 10.3 on CentOS 7 with nginx 1.16. Virtual server has 1 GB memory, no swap. During normal day-peak traffic I see cca 600 – 700 MB of memory occupied, 300 – 400 MB free.

I found logs in /var/log/messages (bellow) from which I understood that InnoDB crashes due to memory exhaust (pls correct me if I misread). But I did not find any DDoS attack or other suspicious activity at the time of crash.

Is there any way to figure out, what’s the reason of memory exhaust? Should I tune up some InnoDB buffer/setting .. ? What should I do to prevent from crashes?

On previous VPS was server running with this configuration for 4-5 years without crash (Maria 10.1 / nginx / CentOS 6).

I am not an database expert, so I will appreciate any advice. Thank you.

Here is /var/log/messages: (crash started at 22:20)

May 27 22:20:01 mysite systemd: Created slice User Slice of root. May 27 22:20:01 mysite systemd: Started Session 28800 of user root. May 27 22:20:01 mysite systemd: Created slice User Slice of nginx. May 27 22:20:01 mysite systemd: Started Session 28801 of user nginx. May 27 22:20:11 mysite kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 May 27 22:20:11 mysite kernel: mysqld cpuset=/ mems_allowed=0 May 27 22:20:11 mysite kernel: CPU: 0 PID: 26756 Comm: mysqld Not tainted 3.10.0-957.12.1.el7.x86_64 #1 May 27 22:20:11 mysite kernel: Hardware name: OpenStack Foundation OpenStack Nova, BIOS 1.10.1-1ubuntu1~cloud0 04/01/2014 May 27 22:20:11 mysite kernel: Call Trace: May 27 22:20:11 mysite kernel: [<ffffffff96363021>] dump_stack+0x19/0x1b May 27 22:20:11 mysite kernel: [<ffffffff9635da4a>] dump_header+0x90/0x229 May 27 22:20:11 mysite kernel: [<ffffffff95d01092>] ? ktime_get_ts64+0x52/0xf0 May 27 22:20:11 mysite kernel: [<ffffffff95d582df>] ? delayacct_end+0x8f/0xb0 May 27 22:20:11 mysite kernel: [<ffffffffc033f71a>] ? virtballoon_oom_notify+0x2a/0x70 [virtio_balloon] May 27 22:20:11 mysite kernel: [<ffffffff95dba634>] oom_kill_process+0x254/0x3d0 May 27 22:20:11 mysite kernel: [<ffffffff95dba0dd>] ? oom_unkillable_task+0xcd/0x120 May 27 22:20:11 mysite kernel: [<ffffffff95dba186>] ? find_lock_task_mm+0x56/0xc0 May 27 22:20:11 mysite kernel: [<ffffffff95dbae76>] out_of_memory+0x4b6/0x4f0 May 27 22:20:11 mysite kernel: [<ffffffff9635e54e>] __alloc_pages_slowpath+0x5d6/0x724 May 27 22:20:11 mysite kernel: [<ffffffff95dc1254>] __alloc_pages_nodemask+0x404/0x420 May 27 22:20:11 mysite kernel: [<ffffffff95e0e148>] alloc_pages_current+0x98/0x110 May 27 22:20:11 mysite kernel: [<ffffffff95db6497>] __page_cache_alloc+0x97/0xb0 May 27 22:20:11 mysite kernel: [<ffffffff95db90f8>] filemap_fault+0x298/0x490 May 27 22:20:11 mysite kernel: [<ffffffffc01fdd0e>] __xfs_filemap_fault+0x7e/0x1d0 [xfs] May 27 22:20:11 mysite kernel: [<ffffffff95cc2e00>] ? wake_bit_function+0x40/0x40 May 27 22:20:11 mysite kernel: [<ffffffffc01fdf0c>] xfs_filemap_fault+0x2c/0x30 [xfs] May 27 22:20:11 mysite kernel: [<ffffffff95de462a>] __do_fault.isra.59+0x8a/0x100 May 27 22:20:11 mysite kernel: [<ffffffff95de4bdc>] do_read_fault.isra.61+0x4c/0x1b0 May 27 22:20:11 mysite kernel: [<ffffffff95de9584>] handle_pte_fault+0x2f4/0xd10 May 27 22:20:11 mysite kernel: [<ffffffff95dec0bd>] handle_mm_fault+0x39d/0x9b0 May 27 22:20:11 mysite kernel: [<ffffffff963705e3>] __do_page_fault+0x203/0x4f0 May 27 22:20:11 mysite kernel: [<ffffffff963709b6>] trace_do_page_fault+0x56/0x150 May 27 22:20:11 mysite kernel: [<ffffffff9636ff42>] do_async_page_fault+0x22/0xf0 May 27 22:20:11 mysite kernel: [<ffffffff9636c788>] async_page_fault+0x28/0x30 May 27 22:20:11 mysite kernel: Mem-Info: May 27 22:20:11 mysite kernel: active_anon:187693 inactive_anon:17396 isolated_anon:0#012 active_file:1781 inactive_file:3687 isolated_file:0#012 unevictable:0 dirty:0 writeback:0 unstable:0#012 slab_reclaimable:3639 slab_unreclaimable:7716#012 mapped:10218 shmem:27944 pagetables:13399 bounce:0#012 free:12232 free_pcp:30 free_cma:0 May 27 22:20:11 mysite kernel: Node 0 DMA free:4592kB min:708kB low:884kB high:1060kB active_anon:8412kB inactive_anon:996kB active_file:0kB inactive_file:216kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB mlocked:0kB dirty:0kB writeback:0kB mapped:472kB shmem:1420kB slab_reclaimable:60kB slab_unreclaimable:380kB kernel_stack:16kB pagetables:728kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:48 all_unreclaimable? yes May 27 22:20:11 mysite kernel: lowmem_reserve[]: 0 972 972 972 May 27 22:20:11 mysite kernel: Node 0 DMA32 free:44212kB min:44344kB low:55428kB high:66516kB active_anon:742360kB inactive_anon:68588kB active_file:7124kB inactive_file:14532kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1032048kB managed:998980kB mlocked:0kB dirty:0kB writeback:0kB mapped:40400kB shmem:110356kB slab_reclaimable:14496kB slab_unreclaimable:30484kB kernel_stack:2704kB pagetables:52868kB unstable:0kB bounce:0kB free_pcp:240kB local_pcp:240kB free_cma:0kB writeback_tmp:0kB pages_scanned:15611 all_unreclaimable? yes May 27 22:20:11 mysite kernel: lowmem_reserve[]: 0 0 0 0 May 27 22:20:11 mysite kernel: Node 0 DMA: 2*4kB (EM) 3*8kB (EM) 5*16kB (UE) 4*32kB (UE) 2*64kB (UM) 1*128kB (E) 2*256kB (UE) 3*512kB (UEM) 2*1024kB (UE) 0*2048kB 0*4096kB = 4592kB May 27 22:20:11 mysite kernel: Node 0 DMA32: 403*4kB (UEM) 597*8kB (UEM) 288*16kB (UEM) 116*32kB (UEM) 41*64kB (UEM) 30*128kB (UEM) 18*256kB (UEM) 18*512kB (UEM) 7*1024kB (UEM) 1*2048kB (U) 0*4096kB = 44212kB May 27 22:20:11 mysite kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB May 27 22:20:11 mysite kernel: 33433 total pagecache pages May 27 22:20:11 mysite kernel: 0 pages in swap cache May 27 22:20:11 mysite kernel: Swap cache stats: add 0, delete 0, find 0/0 May 27 22:20:11 mysite kernel: Free swap  = 0kB May 27 22:20:11 mysite kernel: Total swap = 0kB May 27 22:20:11 mysite kernel: 262010 pages RAM May 27 22:20:11 mysite kernel: 0 pages HighMem/MovableOnly May 27 22:20:11 mysite kernel: 8288 pages reserved May 27 22:20:11 mysite kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name May 27 22:20:11 mysite kernel: [ 1321]     0  1321     9404      357      23        0             0 systemd-journal May 27 22:20:11 mysite kernel: [ 1349]     0  1349    11119      141      24        0         -1000 systemd-udevd May 27 22:20:11 mysite kernel: [ 1573]     0  1573    13880      114      28        0         -1000 auditd May 27 22:20:11 mysite kernel: [ 1933]    81  1933    14524      138      34        0          -900 dbus-daemon May 27 22:20:11 mysite kernel: [ 1961]     0  1961    48774      118      35        0             0 gssproxy May 27 22:20:11 mysite kernel: [ 2001]     0  2001     6594       83      17        0             0 systemd-logind May 27 22:20:11 mysite kernel: [ 2027]   999  2027   153158     1754      59        0             0 polkitd May 27 22:20:11 mysite kernel: [ 2116]   998  2116    29446      115      30        0             0 chronyd May 27 22:20:11 mysite kernel: [ 2385]     0  2385    89521     5530      94        0             0 firewalld May 27 22:20:11 mysite kernel: [ 2961]     0  2961    26866      500      49        0             0 dhclient May 27 22:20:11 mysite kernel: [ 3022]     0  3022   143481     2781      98        0             0 tuned May 27 22:20:11 mysite kernel: [ 3189]     0  3189    22577      280      44        0             0 master May 27 22:20:11 mysite kernel: [ 3191]    89  3191    22647      286      43        0             0 qmgr May 27 22:20:11 mysite kernel: [ 3228]     0  3228    28216      255      58        0         -1000 sshd May 27 22:20:11 mysite kernel: [ 3229]     0  3229    66328     1182      59        0             0 rsyslogd May 27 22:20:11 mysite kernel: [ 3235]     0  3235    31579      170      18        0             0 crond May 27 22:20:11 mysite kernel: [ 3236]     0  3236    27526       33      10        0             0 agetty May 27 22:20:11 mysite kernel: [ 3237]     0  3237    27526       33      11        0             0 agetty May 27 22:20:11 mysite kernel: [15958]     0 15958   130428     6710     147        0             0 php-fpm May 27 22:20:11 mysite kernel: [15982]     0 15982    14721      288      25        0             0 nginx May 27 22:20:11 mysite kernel: [15983]   997 15983    15403      975      31        0             0 nginx May 27 22:20:11 mysite kernel: [21323]   997 21323   245378    11185     347        0             0 php-fpm May 27 22:20:11 mysite kernel: [21327]   997 21327   246079    12329     348        0             0 php-fpm May 27 22:20:11 mysite kernel: [21331]   997 21331   244508     9902     345        0             0 php-fpm May 27 22:20:11 mysite kernel: [21582]   997 21582   225663    12179     340        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 4073]   997  4073   224018     8808     337        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 4076]   997  4076   223517     8433     335        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5510]   997  5510   244374     7954     342        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5517]   997  5517   244782     8575     344        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5519]   997  5519   244994     9463     345        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5520]   997  5520   244763     8907     344        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5521]   997  5521   223316     8418     335        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5522]   997  5522   244493     8212     343        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5523]   997  5523   223509     9244     335        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5524]   997  5524   223996     8921     336        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5527]   997  5527   224017     8661     335        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5536]   997  5536   244945     9254     346        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5546]   997  5546   223528     8214     334        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5551]   997  5551   244849     8735     343        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5557]   997  5557   223438     8154     333        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5558]   997  5558   244862     8565     344        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5559]   997  5559   244877     8601     343        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5561]   997  5561   223924     8706     338        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5562]   997  5562   224018     8866     336        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5563]   997  5563   224008     9187     335        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5564]   997  5564   244965     8904     344        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5566]   997  5566   244403     8290     348        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5567]   997  5567   244920     9447     344        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5568]   997  5568   244514     8736     343        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5569]   997  5569   223477     7876     334        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5570]   997  5570   224004     9054     335        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5574]   997  5574   223319     7945     333        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5575]   997  5575   244729     8709     343        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5576]   997  5576   223435     8296     336        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5577]   997  5577   244711     8679     343        0             0 php-fpm May 27 22:20:11 mysite kernel: [ 5578]   997  5578   244467     8119     344        0             0 php-fpm May 27 22:20:11 mysite kernel: [26393]   996 26393   302816    41380     170        0             0 mysqld May 27 22:20:11 mysite kernel: [10107]    89 10107    22603      271      45        0             0 pickup May 27 22:20:11 mysite kernel: [11273]     0 11273    45598      242      45        0             0 crond May 27 22:20:11 mysite kernel: [11274]     0 11274    45598      242      45        0             0 crond May 27 22:20:11 mysite kernel: [11275]     0 11275    28294       45      11        0             0 sh May 27 22:20:11 mysite kernel: [11276]   997 11276    28294       43      11        0             0 sh May 27 22:20:11 mysite kernel: [11277]   997 11277    96384     2413     139        0             0 php May 27 22:20:11 mysite kernel: [11278]     0 11278    50559     1613      54        0             0 python May 27 22:20:11 mysite kernel: Out of memory: Kill process 26393 (mysqld) score 163 or sacrifice child May 27 22:20:11 mysite kernel: Killed process 26393 (mysqld) total-vm:1211264kB, anon-rss:165520kB, file-rss:0kB, shmem-rss:0kB May 27 22:20:11 mysite systemd: mariadb.service: main process exited, code=killed, status=9/KILL May 27 22:20:11 mysite systemd: Unit mariadb.service entered failed state. May 27 22:20:11 mysite systemd: mariadb.service failed. May 27 22:20:11 mysite systemd: Removed slice User Slice of nginx. May 27 22:20:16 mysite systemd: mariadb.service holdoff time over, scheduling restart. May 27 22:20:16 mysite systemd: Stopped MariaDB 10.3.14 database server. May 27 22:20:16 mysite systemd: Starting MariaDB 10.3.14 database server... May 27 22:20:16 mysite mysqld: 2019-05-27 22:20:16 0 [Note] /usr/sbin/mysqld (mysqld 10.3.14-MariaDB-log) starting as process 11329 ... May 27 22:20:17 mysite systemd: Started MariaDB 10.3.14 database server. May 27 22:20:27 mysite systemd: Removed slice User Slice of root. May 27 22:21:02 mysite systemd: Created slice User Slice of nginx. May 27 22:21:02 mysite systemd: Started Session 28802 of user nginx. 

And here is corresponding /var/log/mysql/errors.log from that crash:

Version: '10.3.14-MariaDB-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MariaDB Server 2019-05-27 22:20:16 0 [Note] InnoDB: Using Linux native AIO 2019-05-27 22:20:16 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2019-05-27 22:20:16 0 [Note] InnoDB: Uses event mutexes 2019-05-27 22:20:16 0 [Note] InnoDB: Compressed tables use zlib 1.2.7 2019-05-27 22:20:16 0 [Note] InnoDB: Number of pools: 1 2019-05-27 22:20:16 0 [Note] InnoDB: Using SSE2 crc32 instructions 2019-05-27 22:20:16 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M 2019-05-27 22:20:16 0 [Note] InnoDB: Completed initialization of buffer pool 2019-05-27 22:20:16 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2019-05-27 22:20:16 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=699238373 2019-05-27 22:20:17 0 [Note] InnoDB: 128 out of 128 rollback segments are active. 2019-05-27 22:20:17 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1" 2019-05-27 22:20:17 0 [Note] InnoDB: Creating shared tablespace for temporary tables 2019-05-27 22:20:17 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2019-05-27 22:20:17 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. 2019-05-27 22:20:17 0 [Note] InnoDB: Waiting for purge to start 2019-05-27 22:20:17 0 [Note] InnoDB: 10.3.14 started; log sequence number 699238382; transaction id 395866 2019-05-27 22:20:17 0 [Note] Plugin 'FEEDBACK' is disabled. 2019-05-27 22:20:17 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool 2019-05-27 22:20:17 0 [Note] Recovering after a crash using tc.log 2019-05-27 22:20:17 0 [Note] InnoDB: Buffer pool(s) load completed at 190527 22:20:17 2019-05-27 22:20:17 0 [Note] Starting crash recovery... 2019-05-27 22:20:17 0 [Note] Crash recovery finished. 2019-05-27 22:20:17 0 [Note] Server socket created on IP: '::'. 2019-05-27 22:20:17 0 [Note] Reading of all Master_info entries succeded 2019-05-27 22:20:17 0 [Note] Added new Master_info '' to hash table 2019-05-27 22:20:17 0 [Note] /usr/sbin/mysqld: ready for connections. Version: '10.3.14-MariaDB-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MariaDB Server