April 2023 - discuss - lists.mariadb.org

[Maria-discuss] Question regarding mariadb-dump/mysqldump and rocksdb
by Jonas Krauss 16 May '23

16 May '23

Hi MariaDB, in Myrocks / Facebook MySQL there was a useful addition to mysqldump which makes queries issued by the dumper not add to the block cache of the rocksdb instance. It was added quite some time ago: https://github.com/facebook/mysql-5.6/commit/2223479fea78a246884c5a09ef4d02… The corresponding server variable used is *rocksdb_skip_fill_cache* Is this active in MariaDB's version of mysqldump as well? The server variable exists in MariaDB's MyRocks (checked for 10.6.12) but I have not found a reference in MariaDB's source code when searching for rocksdb_skip_fill_cache. If it is not active it would be great if it could be added in a future version. Best Jonas

2 2

[Maria-discuss] mariadb crash und recovery
by Radisson97＠gmx.de 14 May '23

14 May '23

Hello list, i had a crash at weekend with no apparend cause. The aria engine did a recovery without furture problems. Maybe that is a hint that somebody can make use of. Hints welcome. CU from log: 230416 7:20:17 [ERROR] 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. 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.5.15-MariaDB-0+deb11u1-log key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=86 max_threads=252 thread_count=38 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 685818 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x7f01e4000c58 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 = 0x7f02b6894d38 thread_stack 0x49000 ??:0(my_print_stacktrace)[0x5559d92bb54e] ??:0(handle_fatal_signal)[0x5559d8dbaf65] sigaction.c:0(__restore_rt)[0x7f043591a140] ??:0(_ma_state_info_write)[0x5559d8fafc73] ??:0(_ma_state_info_write)[0x5559d8fb1737] ??:0(_ma_state_info_write)[0x5559d8fb946c] ??:0(handler::ha_write_row(unsigned char const*))[0x5559d8dc7aa8] ??:0(MyCTX_nopad::finish(unsigned char*, unsigned int*))[0x5559d8ff40da] ??:0(handler::ha_write_row(unsigned char const*))[0x5559d8dc7aa8] ??:0(write_record(THD*, TABLE*, st_copy_info*, select_result*))[0x5559d8b8787d] ??:0(mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool, select _result*))[0x5559d8b8f8a4] ??:0(mysql_execute_command(THD*))[0x5559d8bc2716] ??:0(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x5559d8bc65db] ??:0(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x5559d8bc8a5d] ??:0(do_command(THD*))[0x5559d8bca2de] ??:0(do_handle_one_connection(CONNECT*, bool))[0x5559d8cbbfb2] ??:0(handle_one_connection)[0x5559d8cbc22d] ??:0(MyCTX_nopad::finish(unsigned char*, unsigned int*))[0x5559d8ff811b] nptl/pthread_create.c:478(start_thread)[0x7f043590eea7] x86_64/clone.S:97(__GI___clone)[0x7f0435525def] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f01e4010440): INSERT INTO messwerte VALUES ( 83110995 , 1200 , 909 , 331 , '2023-04-16 05:20:00' , '2023-04-16 05: 20:00' , 0.0703000000000000013766765505351941101253032684326171875 , 0.001000000000000000020816681711721685132943093776702880 859375 , 0 , 0 , 0 , 0 , 60 , 0 ) Connection ID (thread ID): 5463672 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=o n,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subque ry_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_increment al=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,rowi d_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains information that should help you find out what is causing the crash. Writing a core file... Working directory at /home/kpc/kpc.dbs 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 0 unlimited bytes Max resident set unlimited unlimited bytes Max processes 127976 127976 processes Max open files 32313 32313 files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 127976 127976 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: core 230416 07:20:19 mysqld_safe Number of processes running now: 0 230416 07:20:19 mysqld_safe mysqld restarted 2023-04-16 7:20:19 0 [Note] /usr/sbin/mariadbd (mysqld 10.5.15-MariaDB-0+deb11u1-log) starting as process 415 ... 2023-04-16 7:20:20 0 [Note] mariadbd: Aria engine: starting recovery recovered pages: 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% (0.0 seconds); tables to flush: 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 (0.1 seconds); 2023-04-16 7:20:20 0 [Note] mariadbd: Aria engine: recovery done

4 3

[Maria-discuss] mysql.innodb-table-stats-and mysql.innodb-index-stats are not updating properly
by ragul rangarajan 21 Apr '23

21 Apr '23

Hello all, I am facing a weird issue with my DB table where its Index and table stats not getting updated with values automatically in MariaDB 10.6.7 The table has more than a billion records. On querying the stats of the table, I could not see any stats for the table that begin automatically calculated until we do a mysql restart or ANALYZE TABLE. Once triggered we can able to see the index values are calculated and updated in this table 127.0.0.1:3307> SELECT * FROM mysql.innodb_table_stats ;+---------------+-------------------------------------+---------------------+---------+----------------------+--------------------------+| database_name | table_name | last_update | n_rows | clustered_index_size | sum_of_other_index_sizes |+---------------+-------------------------------------+---------------------+---------+----------------------+--------------------------+| DB | TableStats#P#p2023_04_11_13_00_00 | 2023-04-11 12:00:11 | 0 | 1 | 0 || DB | TableStats#P#p2023_04_11_14_00_00 | 2023-04-11 13:00:10 | 0 | 1 | 0 || DB | TableStats#P#p2023_04_11_15_00_00 | 2023-04-11 14:00:04 | 0 | 1 | 0 || DB | TableStats#P#p2023_04_11_16_00_00 | 2023-04-11 15:00:04 | 0 | 1 | 0 |+---------------+-------------------------------------+---------------------+---------+----------------------+--------------------------+ 127.0.0.1:3307> SELECT * FROM mysql.innodb_index_stats;+---------------+-------------------------------------+------------+---------------------+--------------+------------+-------------+------------------------------------------------------------+| database_name | table_name | index_name | last_update | stat_name | stat_value | sample_size | stat_description |+---------------+-------------------------------------+------------+---------------------+--------------+------------+-------------+------------------------------------------------------------+| DB | TableStats#P#p2023_04_11_16_00_00 | PRIMARY | 2023-04-11 15:00:04 | n_diff_pfx01 | 0 | 1 | AgentId || DB | TableStats#P#p2023_04_11_16_00_00 | PRIMARY | 2023-04-11 15:00:04 | n_diff_pfx02 | 0 | 1 | AgentId,rackNr || DB | TableStats#P#p2023_04_11_16_00_00 | PRIMARY | 2023-04-11 15:00:04 | n_leaf_pages | 1 | NULL | Number of leaf pages in the index || DB | TableStats#P#p2023_04_11_16_00_00 | PRIMARY | 2023-04-11 15:00:04 | size | 1 | NULL | Number of pages in the index |+---------------+-------------------------------------+------------+---------------------+--------------+------------+-------------+------------------------------------------------------------+ As per the documentation https://mariadb.com/kb/en/innodb-persistent-statistics/, enabling *innodb_stats_auto_recalc* parameter should update the index value automatically which was not happening for me even though the changes are 10% of the row got affected within few days. The same was working for other DB table which is of lower load. Is there any way to debug why the calculation was not updated properly with values or any way to reduce the sample size? *Thanks and Regards,* Ragul R

2 2

[Maria-discuss] DELETE query hanging on Statistics (10.6.12)
by mariadb＠Biblestuph.com 14 Apr '23

14 Apr '23

With this table: CREATE TABLE t1 ( label varchar(100) NOT NULL, dt datetime NOT NULL, success tinyint(1) NOT NULL, PRIMARY KEY (label,dt), KEY dt (dt), KEY success (success,dt) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 ROW_FORMAT=DYNAMIC I have a DELETE query that has been stuck in Statistics for nearly an hour now: DELETE MyDB.t1 FROM MyDB.t1 WHERE dt <= '2023-02-21 08:06:46' AND dt >= '2023-02-21 08:03:48' This statement runs several times per hour to trim the table (and has for years). It has run fine against my 10.6.12 DB (this is a downstream replica DB) for a couple weeks now(when I upgraded the replica); but suddenly today produced the hang. Any ideas why? The table has nearly 15 million rows; but the rows are more or less evenly spaced across datetimes. Also I find that I cannot kill the query using KILL 12345; the KILL statement just comes back immediately without reporting an error and the statement continues. Is there no way to kill this statement without crashing the DB? Again, this is a replica statement that is executing. I had planned to stop the query, execute an ANALYZE TABLE t1 and then try it again, but I don't seem to be able to kill the query. Thank you! Dan

3 5

[Maria-discuss] Privilege Question
by Scott Canaan 06 Apr '23

06 Apr '23

We are on MariaDB 10.5.18. There is a requirement to send all syslog data to a central syslog server. In the past, we did it using a login called ITS_READ. It has limited privs on purpose, but used to be able to execute the SET GLOBAL statements that we needed. Those statements are: SET GLOBAL server_audit_output_type=SYSLOG; SET GLOBAL server_audit_logging=1; SET GLOBAL server_audit_syslog_facility=LOG_LOCAL2; SET GLOBAL server_audit_events="connect,table,query_ddl,query_dcl"; Now, it doesn't have the privs needed to do that. In looking online, I found that there is a "new" privilege (in MySQL 8), called system_variables_admin that allows the user to execute SET GLOBAL statements. However, when I try to grant that privilege, I get an error: MariaDB [(none)]> grant system_variables_admin to 'ITS_READ'@'localhost'; ERROR 1959 (OP000): Invalid role specification `system_variables_admin` It seems that the only other option is to grant the SUPER privilege, which we don't want to do. How do I get around this, or do I just tell the sysadmins they can't have the syslog data? Scott Canaan '88 Sr Database Administrator Information & Technology Services Finance & Administration Rochester Institute of Technology o: (585) 475-7886 | f: (585) 475-7520 srcdco(a)rit.edu<mailto:srcdco@rit.edu> | c: (585) 339-8659 CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

3 3

[Maria-discuss] Disable validation for `DATETIME` columns
by William Edwards 03 Apr '23

03 Apr '23

Hi, Is it possible to disable validation for `DATETIME` columns? Context: A customer uses the Europe/Amsterdam session time zone. Therefore, they cannot insert dates during the hour in which DST starts and ends. Using the UTC session time zone would solve the issue. However, they also use auto-converting `TIMESTAMP` columns. Switching to a different session time zone would cause issues with those. Relaxing constraints with `sql_mode=NO_ZERO_DATE,NO_ZERO_IN_DATE,ALLOW_INVALID_DATES` does not suffice. With kind regards, William Edwards

2 3

[Maria-discuss] Column named 'row_number' gives error in 10.11
by Keith Edmunds 02 Apr '23

02 Apr '23

I have a table that includes an int column named row_number. This worked fine until I upgraded Debian from 11 to 12 which upgraded MariaDB from 10.5 to 10.11. I now get errors when referencing that column for updates. If I put backticks around the column name the update runs without error. Is this an expected behaviour change from 10.5 → 10.11? Example: CREATE DATABASE test; USE test; CREATE TABLE `kae` ( `id` int(11) NOT NULL, `row_number` int(11) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci; INSERT INTO `kae` (`id`, `row_number`) VALUES (1, 0); UPDATE kae SET row_number=12 WHERE id=1; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'row_number=12 WHERE id=1' at line 1

4 8