- discuss - lists.mariadb.org

Re: [Maria-discuss] Server system variables which description I haven't found
by Michal Schorm 28 Feb '19

28 Feb '19

> https://mariadb.com/kb/en/library/full-list-of-mariadb-options-system-and-s… This is the list I was looking for! Thank you. > Whether the description of each is good enough, is a separate question. I would be in favor of more verbose description. Stack trace: Does that mean without "--stack-trace" I won't get the trace? gdb: I understand it as "--gdb" is meant for runtime debugging and has no effect to the coredump files? does that mean "disable_gdb" option does not exists? (anymore?) -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, Feb 27, 2019 at 4:16 PM Elena Stepanova <elenst(a)mariadb.com> wrote: > > Hi Michal, > > On 02/27/2019 05:07 PM, Michal Schorm wrote: > > Hello everybody, > > > > In the article about "Enabling Core Dumps" [1] there is an example, > > how to properly configure the server for such cases: > > [mariadb] > > stack-trace > > core-file > > disable-gdb > > > > However, the page listing server system variables [2] does not > > describe two of them ("stack-trace", "disable-gdb") and I would like > > That's because they're not system variables, they are command-line > options. I recommend this page as a starting point, it's more universal: > > https://mariadb.com/kb/en/library/full-list-of-mariadb-options-system-and-s… > > Then, for the first one it would send you to > > https://mariadb.com/kb/en/library/mysqld-options/#-stack-trace > > for the other one, you would have to guess that you need to search for > "gdb", not "disable-gdb": > > https://mariadb.com/kb/en/library/mysqld-options/#-gdb > > Whether the description of each is good enough, is a separate question. > > /E > > > > to know what those options do. In which cases I should use each one or > > some combination. Or, since I haven't found their meaning, if there > > aren't long obsoleted. or if the are only applicable to specific > > MariaDB versions. > > Or / and I'm just seeking help on where to find simmilar variables not > > listed on the page [2]. > > > > > > [1] https://mariadb.com/kb/en/library/enabling-core-dumps/ > > [2] https://mariadb.com/kb/en/library/server-system-variables/ > > > > -- > > > > Michal Schorm > > Software Engineer > > Core Services - Databases Team > > Red Hat > > > > -- > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~maria-discuss > > Post to : maria-discuss(a)lists.launchpad.net > > Unsubscribe : https://launchpad.net/~maria-discuss > > More help : https://help.launchpad.net/ListHelp > >

2 2

[Maria-discuss] Server system variables which description I haven't found
by Michal Schorm 27 Feb '19

27 Feb '19

Hello everybody, In the article about "Enabling Core Dumps" [1] there is an example, how to properly configure the server for such cases: [mariadb] stack-trace core-file disable-gdb However, the page listing server system variables [2] does not describe two of them ("stack-trace", "disable-gdb") and I would like to know what those options do. In which cases I should use each one or some combination. Or, since I haven't found their meaning, if there aren't long obsoleted. or if the are only applicable to specific MariaDB versions. Or / and I'm just seeking help on where to find simmilar variables not listed on the page [2]. [1] https://mariadb.com/kb/en/library/enabling-core-dumps/ [2] https://mariadb.com/kb/en/library/server-system-variables/ -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat --

2 1

[Maria-discuss] MariaDB 10.1: binlog stop updating
by Benoit Plessis 22 Feb '19

22 Feb '19

Hi, I have a few mysql cluster, previously on 5.5 (debian jessie) that we are upgrading in mariadb 10.1 (debian stretch) for now. We are experiencing two major issues with the production trafic: * We saw a huge increase in on disk tmp table space used (serveurs with 4Gb of free space in / (including /tmp) had to be added an additionnal 20Gb /tmp volume and even that is no enough everytime * If the replication process has to write a tmp file to execute the query, and log slave updates is active then in the even of the /tmp volume being full, the update of the binlog will also fail erroneouslly with a "No space" error and will stop every following binlog write. 2019-02-20 15:24:12 140618945124096 [ERROR] Slave SQL: Could not execute Write_rows_v1 event on table xxx.yyyy; Error writing file '/tmp/MLxClNzW' (Errcode: 28 "No space left on device"), Error_code: 3; Error writing file '/var/lib/mysql/mysql-bin' (errno: 28 "No space left on device"), Error_code: 1026; Writing one row to the row-based binary log failed, Error_code: 1534; handler error HA_ERR_RBR_LOGGING_FAILED; the event's master log mysql-bin.006843, end_log_pos 42848762, Gtid 0-70-467485, Internal MariaDB error code: 3 2019-02-20 15:24:12 140618945124096 [Warning] Slave: Error writing file '/tmp/MLxClNzW' (Errcode: 28 "No space left on device") Error_code: 3 2019-02-20 15:24:12 140618945124096 [Warning] Slave: Error writing file '/var/lib/mysql/mysql-bin' (errno: 28 "No space left on device") Error_code: 1026 2019-02-20 15:24:12 140618945124096 [Warning] Slave: Writing one row to the row-based binary log failed Error_code: 15342019-02-20 15:24:12 140618945124096 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.006843' position 42814887 Does someone know if they have been improvement in 10.2/10.3 on theses issues ?

4 8

[Maria-discuss] “system user” in SHOW PROCESSLIST
by Felipe Gasper 15 Feb '19

15 Feb '19

Hi all, https://mariadb.com/kb/en/library/show-processlist/ ^^ The above doesn’t describe “system user” in the result of SHOW PROCESSLIST, but that’s what I observe in 10.2.21. What is the meaning of “system user” in the output of this command? Is there a list of these “special” values for the User column? Are these reserved names (i.e., no DB user should be named “system user”)? Thank you! -FG

4 4

[Maria-discuss] Lock Tables and InnoDB
by mariadb＠Biblestuph.com 06 Feb '19

06 Feb '19

I'm missing something in regard to LOCK TABLES when used with InnoDB. Per the documentation here: https://mariadb.com/kb/en/library/lock-tables-and-unlock-tables/ "LOCK TABLES works on XtraDB/InnoDB tables only if the innodb_table_locks system variable is set to 1 (the default) and autocommit is set to 0 (1 is default). Please note that no error message will be returned on LOCK TABLES with innodb_table_locks = 0." But it appears to me that LOCK TABLES *does* work even when autocommit is set to 1, thus I'm unclear as to what is meant by the statement above. Example: MariaDB [MyDB]> show variables like '%version%'; +-------------------------+----------------------+ | Variable_name | Value | +-------------------------+----------------------+ | innodb_version | 5.5.61-MariaDB-38.13 | | protocol_version | 10 | | slave_type_conversions | | | version | 5.5.62-MariaDB | | version_comment | MariaDB Server | | version_compile_machine | x86_64 | | version_compile_os | Linux | +-------------------------+----------------------+ 7 rows in set (0.00 sec) MariaDB [MyDB]> CREATE TABLE MyInnoDBTest ( -> some_number smallint(5) unsigned not null, -> some_text varchar(20) not null, -> primary key (some_number) -> ) Engine=InnoDB; Query OK, 0 rows affected (0.10 sec) MariaDB [MyDB]> INSERT INTO MyInnoDBTest ( some_number, some_text ) VALUES ( 1, 'One' ), ( 2, 'Two' ), ( 3, 'Three' ); Query OK, 3 rows affected (0.00 sec) Records: 3 Duplicates: 0 Warnings: 0 MariaDB [MyDB]> SELECT * FROM MyInnoDBTest; +-------------+-----------+ | some_number | some_text | +-------------+-----------+ | 1 | One | | 2 | Two | | 3 | Three | +-------------+-----------+ 3 rows in set (0.00 sec) MariaDB [MyDB]> SELECT @@autocommit; +--------------+ | @@autocommit | +--------------+ | 1 | +--------------+ MariaDB [MyDB]> SHOW VARIABLES LIKE 'innodb_table_locks'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | innodb_table_locks | ON | +--------------------+-------+ 1 row in set (0.00 sec) MariaDB [MyDB]> LOCK TABLE MyInnoDBTest WRITE; Query OK, 0 rows affected (0.00 sec) ---------------------- Now, in another session, I am unable to do anything with the table, which is what I would suspect if the LOCK TABLES *did* work (I had to CTRL-C out of each statement): MariaDB [MyDB]> SELECT * FROM MyInnoDBTest; ^CCtrl-C -- query killed. Continuing normally. ERROR 1317 (70100): Query execution was interrupted MariaDB [MyDB]> UPDATE MyInnoDBTest SET some_text = 'Four' WHERE some_number = 3; ^CCtrl-C -- query killed. Continuing normally. ERROR 1317 (70100): Query execution was interrupted MariaDB [MyDB]> UPDATE MyInnoDBTest SET some_text = 'Four' WHERE some_number = 4; ^CCtrl-C -- query killed. Continuing normally. ERROR 1317 (70100): Query execution was interrupted MariaDB [MyDB]> INSERT INTO MyInnoDBTest ( some_number, some_text ) VALUES ( 4, 'Four' ); ^CCtrl-C -- query killed. Continuing normally. ERROR 1317 (70100): Query execution was interrupted MariaDB [MyDB]> DELETE FROM MyInnoDBTest WHERE some_number = 3; ^CCtrl-C -- query killed. Continuing normally. ERROR 1317 (70100): Query execution was interrupted ----------------------- What am I missing? Thanks, Dan

3 3

[Maria-discuss] InnoDB, Cold Physical Backups, and Transportable Tablespaces
by mariadb＠Biblestuph.com 06 Feb '19

06 Feb '19

Trying to get my head around how (if) the transportable tablespaces feature of InnoDB can be used in conjunction with cold DB backups. I'm strictly talking here about a DB where innodb_file_per_table=1. Specifically, is "FLUSH TABLES FOR EXPORT" necessary when doing a cold backup of the DB (using innodb_fast_shutdown=0)? I.E., I originally envisioned something like this: 1.) Save a copy of all CREATE TABLE statements for all tables 2.) Shutdown the DB with innodb_fast_shutdown=0 3.) Copy the full contents of the data dir, cnf, etc. Now, my hope was that I would be able to not only restore the full DB as needed from the saved copy, but also be able to restore individual tables both to the original source DB as well as remote DBs, using the CREATE TABLE statement to create the table on the remote, ALTER TABLE ... DISCARD TABLESPACE, copy the .ibd and .frm in, and then ALTER TABLE ... IMPORT TABLESPACE. But trying this I get: ERROR 1030 (HY000): Got error -1 from storage engine I'm currently using MariaDB 5.5, thus I don't have support for FLUSH TABLES FOR EXPORT. But at this point I wasn't sure if I just need to upgrade for this to work or if I was completely barking up the wrong tree. If I did upgrade to 10.0 (or later), would my plan above work as described? Or would I also need to do the FLUSH TABLES FOR EXPORT (perhaps before step 1)? Thanks, Dan

1 0

[Maria-discuss] MyRocks startup error in MariaDB 10.2.18
by Jonas Krauss 15 Jan '19

15 Jan '19

Hi all, we had a database setup running in production for quite some time (> 5 months) and it crashed during last weekend without obvious reason. MariaDB error log stops with (seemingly most useful output set to bold): 2019-01-14 9:07:47 139766003611904 [Note] RocksDB: 2 column families found 2019-01-14 9:07:47 139766003611904 [Note] RocksDB: Column Families at start: 2019-01-14 9:07:47 139766003611904 [Note] cf=default 2019-01-14 9:07:47 139766003611904 [Note] write_buffer_size=134217728 2019-01-14 9:07:47 139766003611904 [Note] target_file_size_base=268435456 2019-01-14 9:07:47 139766003611904 [Note] cf=__system__ 2019-01-14 9:07:47 139766003611904 [Note] write_buffer_size=134217728 2019-01-14 9:07:47 139766003611904 [Note] target_file_size_base=268435456 mysqld: /home/buildbot/buildbot/build/mariadb-10.2.18/storage/rocksdb/rocksdb/db/column_family.cc:1238: *rocksdb::ColumnFamilySet::~ColumnFamilySet(): Assertion `last_ref' failed.* 190114 9:07:58 [ERROR] mysqld got signal 6 ; ... The rest is a memory dump seemingly not too helpful(?). We tried the various recovery modes of rocksdb_wal_recovery_mode (0,2,3) but none seems to have any effect, the output in the log is exactly the same. *Version and OS infos*: MariaDB version: 10.2.18-MariaDB-10.2.18+maria~stretch-log Running on Debian Linux version 4.9.0-8-amd64 ( debian-kernel(a)lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08) We use *jemalloc* as memory allocator. 64GB RAM machine with RAID1 SSD 256GB for logs and 10TB HDD for tables Here is the *rocksdb config part of the my.cnf*: plugin-load-add = ha_rocksdb.so default-storage-engine = rocksdb rocksdb_unsafe_for_binlog = 1 # enables statement based replication rocksdb_datadir = /var/local/mysql/rocksdb rocksdb_wal_dir = /var/mysql_logs/rocksdb rocksdb_tmpdir = /var/mysql_logs/rocksdb rocksdb_flush_log_at_trx_commit = 0 rocksdb_use_direct_io_for_flush_and_compaction = 0 rocksdb_use_direct_reads = 0 rocksdb_max_open_files = -1 rocksdb_max_background_jobs = 8 rocksdb_max_total_wal_size = 4G rocksdb_block_size = 64K rocksdb_block_cache_size = 16G rocksdb_table_cache_numshardbits = 6 rocksdb_new_table_reader_for_compaction_inputs = 1 rocksdb_compaction_readahead_size = 4M #rocksdb_db_write_buffer_size = 0 # max write buffer across all column families, zero = disabled #rocksdb_wal_recovery_mode = 1 rocksdb_bytes_per_sync = 4M rocksdb_wal_bytes_per_sync = 4M rocksdb_rate_limiter_bytes_per_sec = 80M # MB/s. Increase if you're running on higher spec machines rocksdb_compaction_sequential_deletes_count_sd = 1 rocksdb_compaction_sequential_deletes = 199999 rocksdb_compaction_sequential_deletes_window = 200000 #rocksdb_rpl_lookup_rows=0 rocksdb_default_cf_options=write_buffer_size=128m;max_write_buffer_number=4;target_file_size_base=256m;max_bytes_for_level_base=2560m;target_file_size_multiplier=2;level0_file_num_compaction_trigger=4;level0_slowdown_writes_trigger=10;level0_stop_writes_trigger=15;compression=kSnappyCompression;bottommost_compression=kZlibCompression;compression_opts=-14:1:0;block_based_table_factory={cache_index_and_filter_blocks=1;filter_policy=bloomfilter:10:false;whole_key_filtering=1};level_compaction_dynamic_level_bytes=true;optimize_filters_for_hits=true;compaction_pri=kMinOverlappingRatio Does anyone have a idea what could cause this crash? Google did not return helpful results, most similar thing anyone had is this in my search: https://github.com/facebook/mysql-5.6/issues/391 Any help is greatly appreciated. Best regards Jonas

1 1

[Maria-discuss] Full text search not matching 2 letter word
by Andrew Wood 09 Jan '19

09 Jan '19

Im trying to run a full text query on a two letter keyword 'K7'. I have set ft_min_word_len=2 and restarted the server and if I view the system vars in Mysql Workbench it shows it is set correctly. I have then dropped and re-created the index on the descrip column. It is an InnoDB table so I cannot do repair table. Im running the following query which I expect to match the following record but it doesnt. Full text searches for other words match OK. select * from asset where type ='DOCUMENTS' and (match(descrip) against ('K7' in boolean mode)) ; +-----+--------------------+----------------------------------------------------------------------------------------------+-----------+-------------------+--------------+-------------+ | id | type | descrip | subtype | intendeduse | location | assetfileid | +-----+--------------------+---------------------------------------------------------------------------------------------+------------+-------------------+--------------+-------------+ | 153 | DOCUMENTS | Telephone Kiosk No. 7 K7 Interior promo photo from field trial. | PHOTO | DISPLAY | STORAGE | 152 | +-----+--------------------+----------------------------------------------------------------------------------------------+------------+------------------+--------------+-------------+ Any ideas why this is not working? Thanks Andrew

2 2

[Maria-discuss] will query_response_time be removed?
by Federico Razzoli 02 Jan '19

02 Jan '19

I see that Percona has removed query_response_time in version 8.0. Does this plugin have a future in MariaDB? Cheers,Federico

2 1

[Maria-discuss] Post-MySQL(5.6) to MariaDB migration question - why are master_info_repository=TABLE and relay_log_info_repository=TABLE not supported?
by Artem Russakovskii 25 Dec '18

25 Dec '18

Hi, This is my first post to the mariadb list, as I just migrated from mysql to mariadb (OpenSUSE stopped supporting mysql after Leap 15.0). I immediately ran into an issue migrating, with the slave not starting. Upon further analysis, it turned out to be the lack of support of master_info_repository=TABLE and relay_log_info_repository=TABLE in mariadb, which means the master information effectively disappeared as far as the slave server is concerned. I am very surprised by this revelation. Not only did it break replication (I had to figure this out and reassemble the CHANGE MASTER TO command with the values fished out from the slave_master_info table), it also seems to be a step back when it comes to crash-safe replication. Does anyone have an explanation for why we're now back to master.info and relay-log.info on disk rather than nice tables in memory? See https://www.percona.com/blog/2013/09/13/enabling-crash-safe-slaves-with-mys… from years ago for more info, for example. It'd be great to hear from the core mariadb/mysql developers. The lack of master_info_repository and relay_log_info_repository support is documented here: https://mariadb.com/kb/en/library/system-variable-differences-between-maria… . Thank you. Sincerely, Artem

2 3