[MDEV-20897] MariaDB crashed on INSERT (item.cc:6620) Created: 2019-10-25  Updated: 2020-10-17

Status: Open
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.4.8
Fix Version/s: 10.4

Type: Bug Priority: Major
Reporter: Sebastian Stamm Assignee: Marko Mäkelä
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Windows Server 2012 R2


Issue Links:
Relates
relates to MDEV-20906 MariaDB crashed on DELETE (lock0priv.... Closed

 Description   

191025 13:17:07 [ERROR] mysqld got exception 0xc0000005 ;
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.
 
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
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.
 
Server version: 10.4.8-MariaDB
key_buffer_size=134217728
read_buffer_size=67108864
max_used_connections=36
max_threads=65537
thread_count=11
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 266289 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x26cea8e048
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...
mysqld.exe!save_int_value_in_field()[item.cc:6620]
mysqld.exe!fill_record()[sql_base.cc:8491]
mysqld.exe!fill_record_n_invoke_before_triggers()[sql_base.cc:8663]
mysqld.exe!mysql_insert()[sql_insert.cc:961]
mysqld.exe!mysql_execute_command()[sql_parse.cc:4529]
mysqld.exe!mysql_parse()[sql_parse.cc:7914]
mysqld.exe!dispatch_command()[sql_parse.cc:1845]
mysqld.exe!do_command()[sql_parse.cc:1359]
mysqld.exe!threadpool_process_request()[threadpool_common.cc:366]
mysqld.exe!tp_callback()[threadpool_common.cc:193]
KERNEL32.DLL!VirtualUnlock()
ntdll.dll!RtlGetActiveActivationContext()
ntdll.dll!RtlFreeUnicodeString()
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x26b64b1360): insert into Performance (flightRecordId, cashunitErrors, errors, jams, limitedService, logicalExceptions, movedNotes, movedVoucher, nonTechLimitedService, oosErrors, oosJamsHead, oosJamsSafe, unrecoveredErrors, useCase, useCases) values (2834658, 0, 4, 0, 0, 0, 1847, 0, 0, 0, 0, 0, 0, 'ALL', 134)
Connection ID (thread ID): 5572018
Status: NOT_KILLED
 
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on
 
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.
Writing a core file at D:\MariaDB 10.4\data\

Getting even worser:

2019-10-25 13:45:38 46150 [ERROR] InnoDB: Unable to decompress .\fcc_1290\inventorydata.ibd[page id: space=2586, page number=108374]
2019-10-25 13:45:38 46150 [Warning] InnoDB:  Error code: 107 btr_pcur_open_low  level: 0 called from file: D:\winx64-packages\build\src\storage\innobase\row\row0row.cc line: 1225 table: `fcc_1290`.`inventorydata` index: `PRIMARY`
2019-10-25 13:45:38 3 [ERROR] InnoDB: Unable to decompress .\fcc_1290\cashflowstack.ibd[page id: space=2583, page number=323198]
191025 13:45:38 [ERROR] mysqld got exception 0xc0000005 ;
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.
 
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
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.
 
Server version: 10.4.8-MariaDB
key_buffer_size=134217728
read_buffer_size=67108864
max_used_connections=43
max_threads=65537
thread_count=22
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 266289 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0xdfbc466988
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...
2019-10-25 13:45:38 46147 [ERROR] InnoDB: Unable to decompress .\fcc_1290\histogramentry.ibd[page id: space=2585, page number=24568]
2019-10-25 13:45:38 46147 [Warning] InnoDB:  Error code: 107 btr_pcur_open_low  level: 0 called from file: D:\winx64-packages\build\src\storage\innobase\row\row0row.cc line: 1225 table: `fcc_1290`.`histogramentry` index: `PRIMARY`
InnoDB: using atomic writes.



 Comments   
Comment by Elena Stepanova [ 2019-11-05 ]

Did the first failure also have preceding InnoDB errors, and if so, could you please include them into the quoted fragment?
Does the failure always happen when you run the same INSERT? If so, can you provide the output of

SHOW CREATE TABLE Performance;
SHOW INDEX IN Performance;

and also paste or attach your config file?

Comment by Sebastian Stamm [ 2019-11-06 ]

It is independent from the tables. But i guess related to InnoDB and MDEV-20906

[mysqld]
 
port=1434
 
core_file
 
datadir=D:/MariaDB 10.4/data
tmpdir=D:/MariaDB 10.4/temp
 
character-set-server=utf8
 collation-server=utf8_general_ci
 
default-storage-engine=innodb
 
skip_name_resolve
 
max_connections=200
max_connect_errors=50
 
query_cache_size=16M
 
tmp_table_size=2G
max_heap_table_size=2G
 
max_allowed_packet=64M
group_concat_max_len = 32768
table_definition_cache=2048
 
sort_buffer_size=64M
read_buffer_size=64M
 
mrr_buffer_size=16M
 
join_cache_level=8
join_buffer_size=32M
join_buffer_space_limit=64M
 
#*** INNODB Specific options ***
 
innodb_buffer_pool_size=10G
innodb_sort_buffer_size=16M
 
innodb_log_file_size=512M
innodb_log_buffer_size=64M
innodb_log_files_in_group = 4
 
# 0 -> Better performance than 2
innodb_flush_log_at_trx_commit=0
innodb_flush_neighbors=0
 
innodb_read_io_threads=32
innodb_write_io_threads=24
 
innodb_lru_scan_depth=2048
 
innodb_io_capacity = 100000
 
innodb_max_dirty_pages_pct = 60
innodb_lock_wait_timeout = 120
 
innodb_doublewrite = 0
 
[mysqldump]
quick
max_allowed_packet = 32M
 
[client]
plugin-dir=D:/MariaDB 10.4/lib/plugin

Comment by Archie Cobbs [ 2019-12-03 ]

We experienced a similar crash today. First time we've seen this crash.

First sign of trouble was these log messages repeated a bunch of times (note I've truncated the long hex lines):

2019-12-03 14:05:23 140526568023808 [ERROR] InnoDB: Database page corruption on disk or a failed file read of tablespace pcom/Pid page [page id: space=155, page number=2649]. You may have to recover from a backup.
2019-12-03 14:05:23 140526568023808 [Note] InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 0000000000000a5900000a6000000895000000527e4370d845bf00000000000000000000009b ... 
InnoDB: End of page dump
2019-12-03 14:05:23 140526568023808 [Note] InnoDB: Uncompressed page, stored checksum in field1 0, calculated checksums for field1: crc32 0, innodb 2678771645,  page type 17855 == INDEX.none 3735928559, stored checksum in field2 0, c
2019-12-03 14:05:23 140526568023808 [Note] InnoDB: Page may be an index page where index id is 443
2019-12-03 14:05:23 140526568023808 [Note] InnoDB: Index 443 is `UKov21uy8ka3a3p94g40s1ljl3l` in table `pcom`.`Pid`
2019-12-03 14:05:23 140526568023808 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try 
2019-12-03 14:05:23 140526568023808 [ERROR] InnoDB: Database page corruption on disk or a failed file read of tablespace pcom/Pid page [page id: space=155, page number=2649]. You may have to recover from a backup.
2019-12-03 14:05:23 140526568023808 [Note] InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 0000000000000a5900000a6000000895000000527e4370d845bf00000000000000000000009b ...
InnoDB: End of page dump
2019-12-03 14:05:24 140526568023808 [Note] InnoDB: Uncompressed page, stored checksum in field1 0, calculated checksums for field1: crc32 0, innodb 2678771645,  page type 17855 == INDEX.none 3735928559, stored checksum in field2 0, c
2019-12-03 14:05:24 140526568023808 [Note] InnoDB: Page may be an index page where index id is 443
2019-12-03 14:05:24 140526568023808 [Note] InnoDB: Index 443 is `UKov21uy8ka3a3p94g40s1ljl3l` in table `pcom`.`Pid`
2019-12-03 14:05:24 140526568023808 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try 
2019-12-03 14:05:24 140526568023808 [ERROR] InnoDB: Database page corruption on disk or a failed file read of tablespace pcom/Pid page [page id: space=155, page number=2649]. You may have to recover from a backup.
2019-12-03 14:05:24 140526568023808 [Note] InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 0000000000000a5900000a6000000895000000527e4370d845bf00000000000000000000009b ...

Then finally this:

2019-12-03 14:05:31 140526568023808 [Note] InnoDB: Uncompressed page, stored checksum in field1 0, calculated checksums for field1: crc32 0, innodb 2678771645,  page type 17855 == INDEX.none 3735928559, stored checksum in field2 0, c
2019-12-03 14:05:31 140526568023808 [Note] InnoDB: Page may be an index page where index id is 443
2019-12-03 14:05:31 140526568023808 [Note] InnoDB: Index 443 is `UKov21uy8ka3a3p94g40s1ljl3l` in table `pcom`.`Pid`
2019-12-03 14:05:31 140526568023808 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try 
2019-12-03 14:05:31 140526568023808 [ERROR] [FATAL] InnoDB: Unable to read page [page id: space=155, page number=2649] into the buffer pool after 100. The most probable cause of this error may be that the table has been corrupted. Se
191203 14:05:31 [ERROR] 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.
 
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
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.
 
Server version: 10.2.25-MariaDB-log
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=29
max_threads=153
thread_count=34
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467240 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7fcecc08d638
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 = 0x7fcee42b1cf8 thread_stack 0x49000
/usr/sbin/mysqld(my_print_stacktrace+0x3c)[0x560a2f71ff9c]
/usr/sbin/mysqld(handle_fatal_signal+0x533)[0x560a2f24bc73]
/lib64/libpthread.so.0(+0x12360)[0x7fcf062c6360]
/lib64/libc.so.6(gsignal+0x110)[0x7fcf05656160]
/lib64/libc.so.6(abort+0x151)[0x7fcf05657741]
/usr/sbin/mysqld(+0x915fad)[0x560a2f4fbfad]
/usr/sbin/mysqld(+0x95404b)[0x560a2f53a04b]
/usr/sbin/mysqld(+0x932bd3)[0x560a2f518bd3]
/usr/sbin/mysqld(+0x879875)[0x560a2f45f875]
/usr/sbin/mysqld(+0x87d823)[0x560a2f463823]
/usr/sbin/mysqld(+0x87dd16)[0x560a2f463d16]
/usr/sbin/mysqld(+0x88cd04)[0x560a2f472d04]
/usr/sbin/mysqld(+0x7e299f)[0x560a2f3c899f]
/usr/sbin/mysqld(_ZN7handler12ha_write_rowEPh+0x16f)[0x560a2f25578f]
/usr/sbin/mysqld(_Z12write_recordP3THDP5TABLEP12st_copy_info+0x618)[0x560a2f0a2ab8]
/usr/sbin/mysqld(_Z12mysql_insertP3THDP10TABLE_LISTR4ListI4ItemERS3_IS5_ES6_S6_15enum_duplicatesb+0x1252)[0x560a2f0abff2]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x2a28)[0x560a2f0c0158]
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x2e9)[0x560a2f0c5b09]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x2007)[0x560a2f0c88a7]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x176)[0x560a2f0c9166]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP7CONNECT+0x204)[0x560a2f18a194]
/usr/sbin/mysqld(handle_one_connection+0x34)[0x560a2f18a374]
/lib64/libpthread.so.0(+0x7569)[0x7fcf062bb569]
/lib64/libc.so.6(clone+0x3f)[0x7fcf05718a2f]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7fcecc0eb6c0): is an invalid pointer
Connection ID (thread ID): 30
Status: NOT_KILLED
 
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_key
 
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.
 
We think the query pointer is invalid, but we will try to print it anyway. 
Query: insert into Pid (patient, type, pid) values (155086, 'EPIC', 'M001615646')
 
Writing a core file...
Working directory at /var/lib/mysql
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        unlimited            unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             31824                31824                processes 
Max open files            4183                 4183                 files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       31824                31824                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        
Core pattern: |/bin/false
 
2019-12-03 14:05:31 139909435925056 [Warning] InnoDB: Using innodb_file_format is deprecated and the parameter may be removed in future releases. See https://mariadb.com/kb/en/library/xtradbinnodb-file-format/
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Uses event mutexes
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Compressed tables use zlib 1.2.11
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Using Linux native AIO
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Number of pools: 1
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Using SSE2 crc32 instructions
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Completed initialization of buffer pool
2019-12-03 14:05:31 139908875114240 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Highest supported file format is Barracuda.
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Starting crash recovery from checkpoint LSN=354306747034
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 3 row operations to undo
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Trx id counter is 508367104
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Starting final batch to recover 1798 pages from redo log.
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: 128 out of 128 rollback segments are active.
2019-12-03 14:05:31 139908866721536 [Note] InnoDB: Starting in background the rollback of recovered transactions
2019-12-03 14:05:31 139908866721536 [ERROR] InnoDB: Database page corruption on disk or a failed file read of tablespace pcom/Pid page [page id: space=155, page number=2649]. You may have to recover from a backup.
2019-12-03 14:05:31 139908866721536 [Note] InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 0000000000000a5900000a6000000895000000527e4370d845bf00000000000000000000009b...
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Creating shared tablespace for temporary tables
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
000006c9d8080a2002082bb44d3030313631353236374d45444954454348800000000006c9d8040a00021000...
2019-12-03 14:05:31 139909435925056 [Note] InnoDB: Waiting for purge to start
5b000a0bc3040a000a70003e4d30303136313737363545504943800000000002fd2e080a200a78ff844d303031...
InnoDB: End of page dump
2019-12-03 14:05:31 139908866721536 [Note] InnoDB: Uncompressed page, stored checksum in field1 0, calculated checksums for field1: crc32 0, innodb 2678771645,  page type 17855 == INDEX.none 3735928559, stored checksum in field2 0, c
2019-12-03 14:05:31 139908866721536 [Note] InnoDB: Page may be an index page where index id is 443
2019-12-03 14:05:31 139908866721536 [Note] InnoDB: Index 443 is `UKov21uy8ka3a3p94g40s1ljl3l` in table `pcom`.`Pid`
2019-12-03 14:05:31 139908866721536 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try 
2019-12-03 14:05:31 139908866721536 [ERROR] InnoDB: Database page corruption on disk or a failed file read of tablespace pcom/Pid page [page id: space=155, page number=2649]. You may have to recover from a backup.
2019-12-03 14:05:31 139908866721536 [Note] InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 0000000000000a5900000a6000000895000000527e4370d845bf00000000000000000000009b003f3eb8820a3...
2019-12-03 14:05:31 139909435925056 [Note] Recovering after a crash using tc.log
2019-12-03 14:05:32 139909435925056 [Note] Crash recovery finished.
InnoDB: End of page dump
2019-12-03 14:05:32 139908866721536 [Note] InnoDB: Uncompressed page, stored checksum in field1 0, calculated checksums for field1: crc32 0, innodb 2678771645,  page type 17855 == INDEX.none 3735928559, stored checksum in field2 0, c
2019-12-03 14:05:32 139908866721536 [Note] InnoDB: Page may be an index page where index id is 443
2019-12-03 14:05:32 139908866721536 [Note] InnoDB: Index 443 is `UKov21uy8ka3a3p94g40s1ljl3l` in table `pcom`.`Pid`
2019-12-03 14:05:32 139908866721536 [Note] InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try 
2019-12-03 14:05:32 139908866721536 [ERROR] InnoDB: Database page corruption on disk or a failed file read of tablespace pcom/Pid page [page id: space=155, page number=2649]. You may have to recover from a backup.
2019-12-03 14:05:32 139908866721536 [Note] InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 0000000000000a5900000a6000000895000000527e4370d845bf00000000000000000000009b003f3eb8820a3...
080a20030010364d3030313631353635314d45444954454348800000000003af0a040a000308003e4d3030313...
313345504943800000000008c0a7080a20095002e34d3030313631373631334d4544495445434880000000000...
2019-12-03 14:05:32 139909435925056 [ERROR] mysqld: Table 'db' is marked as crashed and should be repaired
2019-12-03 14:05:32 139909435925056 [Warning] Checking table:   './mysql/db'
2019-12-03 14:05:32 139909435925056 [ERROR] mysql.db: 1 client is using or hasn't closed the table properly
00000000036e8f040a0009b0003e4d3030313631373638354550494380000000000260c0080a2009b808724d3...
2019-12-03 14:05:32 139909435925056 [Note] Added new Master_info '' to hash table
2019-12-03 14:05:32 139909435925056 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.2.25-MariaDB-log'  socket: '/run/mysql/mysql.sock'  port: 3306  SUSE package

Using InnoDB recovery modes, we were able to mysqldump all of the other tables, and then SELECT * FROM `Pid` ORDER BY `patient`, `pid` to get all of the Pid table's data. So this allowed us to reconstruct the complete database.

Additional info (note, this was after we rebuilt the database but using the exact same schema):

SHOW CREATE TABLE Pid:

CREATE TABLE `Pid` (
  `patient` bigint(20) NOT NULL,
  `pid` varchar(32) COLLATE utf8mb4_bin NOT NULL,
  `type` varchar(8) COLLATE utf8mb4_bin NOT NULL,
  PRIMARY KEY (`patient`,`type`),
  UNIQUE KEY `UKov21uy8ka3a3p94g40s1ljl3l` (`pid`,`type`),
  CONSTRAINT `FK5wteflfdggheps2n5qx7rj05l` FOREIGN KEY (`patient`) REFERENCES `Patient` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

SHOW INDEX IN Pid:

+-------+------------+-----------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name                    | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------+------------+-----------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Pid   |          0 | PRIMARY                     |            1 | patient     | A         |           0 |     NULL | NULL   |      | BTREE      |         |               |
| Pid   |          0 | PRIMARY                     |            2 | type        | A         |           0 |     NULL | NULL   |      | BTREE      |         |               |
| Pid   |          0 | UKov21uy8ka3a3p94g40s1ljl3l |            1 | pid         | A         |           0 |     NULL | NULL   |      | BTREE      |         |               |
| Pid   |          0 | UKov21uy8ka3a3p94g40s1ljl3l |            2 | type        | A         |           0 |     NULL | NULL   |      | BTREE      |         |               |
+-------+------------+-----------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

/etc/my.cnf:

# The following options will be passed to all MariaDB clients
[client]
# Please note that storing the password in this file is not safe. For this
# purpose you can, for example, list your password in the [client] section
# of the '~/.my.cnf' configuration file with an access mode set to 400 or 600.
# password   = your_password
# port       = 3306
# socket     = /run/mysql/mysql.sock
 
# The MariaDB server
[mysqld]
 
# For security reasons, bind to 127.0.0.1 by default to enable networking
# only on the loopback interface.
bind-address    = 127.0.0.1
 
# If log-error is not set, mysqld will write to "/var/lib/mysql/$HOSTNAME.err"
# which is not beneficial for rotating the log file if it grows in size.
log-error       = /var/log/mysql/mysqld.log
 
# Enable the slow query log to see queries with especially long duration
# slow_query_log=1
# slow_query_log_file = /var/log/mysql/mysqld_slow.log
 
# Operations 'LOAD DATA', 'SELECT ... INTO' and 'LOAD FILE()' will only
# work with files in the specified directory
secure_file_priv = /var/lib/mysql-files
 
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
 
# Using newer file format that supports dynamic and compressed row formats.
# If you are using replication you have to make sure, that these options are
# set everywhere the same way (probably comment them out is the easiest way)
innodb_file_format=Barracuda
innodb_file_per_table=ON
 
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin=mysql-bin
# binlog_format=mixed
 
# Remove leading # if you want to store your database elsewhere
# datadir	= /var/lib/mysql
 
# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id	= 1
 
# These are commonly set, remove the # and set as required.
# port = 3306
# socket = /run/mysql/mysql.sock
 
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M 
 
# Configure the MariaDB server to use SSL 
# ssl-ca=/etc/mysql/ssl/ca-cert.pem
# ssl-cert=/etc/mysql/ssl/server-cert.pem
# ssl-key=/etc/mysql/ssl/server-key.pem
 
sql_mode=NO_ENGINE_SUBSTITUTION
 
[mysqld_multi]
mysqld     = /usr/bin/mysqld_safe
mysqladmin = /usr/bin/mysqladmin
log        = /var/log/mysqld_multi.log
 
# If you want to use mysqld_multi uncomment 1 or more mysqld sections
# below or add your own ones.
 
# WARNING
# --------
# If you uncomment mysqld1 than make absolutely sure, that database mysql,
# configured above, is not started.  This may result in corrupted data!
#
# [mysqld1]
# port       = 3306
# datadir    = /var/lib/mysql
# pid-file   = /var/lib/mysql/mysqld.pid
# socket     = /var/lib/mysql/mysql.sock
# user       = mysql
 
# [mysqld2]
# port       = 3307
# datadir    = /var/lib/mysql-databases/mysqld2
# pid-file   = /var/lib/mysql-databases/mysqld2/mysql.pid
# socket     = /var/lib/mysql-databases/mysqld2/mysql.sock
# user       = mysql
 
# [mysqld3]
# port       = 3308
# datadir    = /var/lib/mysql-databases/mysqld3
# pid-file   = /var/lib/mysql-databases/mysqld3/mysql.pid
# socket     = /var/lib/mysql-databases/mysqld3/mysql.sock
# user       = mysql
 
# [mysqld6]
# port       = 3309
# datadir    = /var/lib/mysql-databases/mysqld6
# pid-file   = /var/lib/mysql-databases/mysqld6/mysql.pid
# socket     = /var/lib/mysql-databases/mysqld6/mysql.sock
# user       = mysql
 
!includedir /etc/my.cnf.d

/etc/my.cnf.d/pcom-mysql.cnf:

[mysqld]
character_set_server            = utf8mb4
bind-address                    = 127.0.0.1
max_allowed_packet              = 16M
#transaction_isolation           = READ-COMMITTED
 
# Log slow queries
slow_query_log                  = ON
slow_query_log_file             = /var/log/mysql/slow.log
long_query_time                 = 2.0
min_examined_row_limit          = 1000
 
# Query cache
query_cache_type                = 1
query_cache_size                = 16M
 
# Timeouts
innodb_lock_wait_timeout        = 15
 
# Expire old binary log files
expire_logs_days                = 7

Comment by Roel Van de Paar [ 2020-08-18 ]

$ /test/MD110820-mariadb-10.5.6-linux-x86_64-opt/bin/perror 107
OS error code 107:  Transport endpoint is not connected

Alike to MDEV-20906 I suspect hardware issues (disk or memory) to be the cause here. Please run an exhaustive disk and memory check. I would also recommend checking your I/O subsystem based on the issues seen (I/O subsystem logs, raid controller validation/cable and connection integrity/drives firmware upgrade etc.)

Comment by Archie Cobbs [ 2020-09-15 ]

FWIW, my crash occurred on a virtual machine system running on VMWare vSphere, so technically it couldn't have (directly) been a hardware problem.

In theory I suppose it could have been a vSphere bug, though that starts to sound a little contrived... it's always easier to blame the "container" :)

Comment by Roel Van de Paar [ 2020-09-16 ]

https://www.google.com/search?q=%22Transport+endpoint+is+not+connected%22

Generated at Thu Feb 08 09:03:01 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.