- discuss - lists.mariadb.org

[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

[Maria-discuss] Large query performance degrade after converting table from MyISAM to InnoDB
by Conor Murphy 17 Dec '18

17 Dec '18

Hi, I'm trying to covert an existing database from MyISAM to InnoDB. The conversion completed okay, but I'm seeing one particular query causing problems, with MyISAM it was taking ~ 6 minutes to complete, with InnoDB it's taking nearly 14 hours The query is as follows SELECT procid, UNIX_TIMESTAMP(MAX(time)), COUNT(*) AS num FROM proc_stats GROUP BY procid HAVING num < 100 EXPLAIN SELECT procid, UNIX_TIMESTAMP(MAX(time)), COUNT(*) AS num FROM proc_stats GROUP BY procid HAVING num < 100 +------+-------------+------------+-------+---------------+--------+---------+------+-----------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+------------+-------+---------------+--------+---------+------+-----------+-------+ | 1 | SIMPLE | proc_stats | index | NULL | pidIdx | 2 | NULL | 956928549 | | +------+-------------+------------+-------+---------------+--------+---------+------+-----------+-------+ | proc_stats | CREATE TABLE `proc_stats` ( `time` datetime NOT NULL, `siteid` smallint(5) unsigned DEFAULT NULL, `serverid` smallint(5) unsigned NOT NULL, `procid` smallint(5) unsigned NOT NULL, `cpu` smallint(5) unsigned DEFAULT NULL, `mem` mediumint(8) unsigned NOT NULL, `thr` smallint(5) unsigned NOT NULL, `fd` smallint(5) unsigned DEFAULT NULL, `rss` mediumint(8) unsigned DEFAULT NULL, `nproc` tinyint(3) unsigned NOT NULL DEFAULT '0', `sample_interval` smallint(5) unsigned DEFAULT NULL, KEY `pidIdx` (`procid`), KEY `serverTimeIdx` (`serverid`,`time`), KEY `siteIdIdx` (`siteid`,`time`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 /*!50100 PARTITION BY RANGE ( TO_DAYS(time)) (PARTITION P20120101 VALUES LESS THAN (734868) ENGINE = InnoDB, PARTITION P20151201 VALUES LESS THAN (736298) ENGINE = InnoDB, PARTITION P20160101 VALUES LESS THAN (736329) ENGINE = InnoDB, PARTITION P20160201 VALUES LESS THAN (736360) ENGINE = InnoDB, PARTITION P20160301 VALUES LESS THAN (736389) ENGINE = InnoDB, PARTITION P20160401 VALUES LESS THAN (736420) ENGINE = InnoDB, PARTITION P20160501 VALUES LESS THAN (736450) ENGINE = InnoDB, PARTITION P20160601 VALUES LESS THAN (736481) ENGINE = InnoDB, PARTITION P20160701 VALUES LESS THAN (736511) ENGINE = InnoDB, PARTITION P20160801 VALUES LESS THAN (736542) ENGINE = InnoDB, PARTITION P20160901 VALUES LESS THAN (736573) ENGINE = InnoDB, PARTITION P20161001 VALUES LESS THAN (736603) ENGINE = InnoDB, PARTITION P20161101 VALUES LESS THAN (736634) ENGINE = InnoDB, PARTITION P20161201 VALUES LESS THAN (736664) ENGINE = InnoDB, PARTITION P20170101 VALUES LESS THAN (736695) ENGINE = InnoDB, PARTITION P20170201 VALUES LESS THAN (736726) ENGINE = InnoDB, PARTITION P20170301 VALUES LESS THAN (736754) ENGINE = InnoDB, PARTITION P20170401 VALUES LESS THAN (736785) ENGINE = InnoDB, PARTITION P20170501 VALUES LESS THAN (736815) ENGINE = InnoDB, PARTITION P20170601 VALUES LESS THAN (736846) ENGINE = InnoDB, PARTITION P20170701 VALUES LESS THAN (736876) ENGINE = InnoDB, PARTITION P20170801 VALUES LESS THAN (736907) ENGINE = InnoDB, PARTITION P20170901 VALUES LESS THAN (736938) ENGINE = InnoDB, PARTITION P20171001 VALUES LESS THAN (736968) ENGINE = InnoDB, PARTITION P20171101 VALUES LESS THAN (736999) ENGINE = InnoDB, PARTITION P20171201 VALUES LESS THAN (737029) ENGINE = InnoDB, PARTITION P20180101 VALUES LESS THAN (737060) ENGINE = InnoDB, PARTITION Q201804 VALUES LESS THAN (737150) ENGINE = InnoDB, PARTITION Q201807 VALUES LESS THAN (737241) ENGINE = InnoDB, PARTITION Q201810 VALUES LESS THAN (737333) ENGINE = InnoDB, PARTITION Q201901 VALUES LESS THAN (737425) ENGINE = InnoDB, PARTITION QMAXVALUE VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */ | While the query is running, all I can see in the processlist is | 64313 | statsadm| 64313 | statsadm | priv:41254 | statsdb | Query | 13001 | Sending data | SELECT procid, MAX(time), COUNT(*) AS num FROM proc_stats GROUP BY procid HAVING num < 100 | 0.000 | Version is 5.5.60-MariaDB Any suggestions on how to localize why the query is taking so long with InnoDB? Thanks, Conor

4 9

[Maria-discuss] Missing rights on 'CREATE ALGORITHM=UNDEFINED DEFINER...'
by Thomas Plant 13 Dec '18

13 Dec '18

Hello all, I have a request from a user who can not create a view in his database. He has the following rights granted: +----------------------------------------------------------------------------------------------------------------+ | Grants for user@% | +----------------------------------------------------------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'user'@'%' IDENTIFIED BY PASSWORD '***************' | | GRANT ALL PRIVILEGES ON `dbname`.* TO 'user'@'%' | +----------------------------------------------------------------------------------------------------------------+ The view he tries to create looks like these: CREATE ALGORITHM=UNDEFINED DEFINER=`xxxxxxxxxxx`(a)`xx.xxx.xxx.x/xxx.xxx.xxx.x` SQL SECURITY DEFINER VIEW `jos_docman_file_counts` AS select `jos_docman_documents`.`storage_path` AS `storage_path`,count(0) AS `count` from `jos_docman_documents` where (`jos_docman_documents`.`storage_type` = 'file') group by `jos_docman_documents`.`storage_path`; And gets as error: #1227 - Access denied; you need (at least one of) the SUPER privilege(s) for this operation What SUPER privilege is needed for this view? The Database is MariaDB 10.1 on Centos 7. Thanks for any hint about his. Greetings, Thomas

2 3

[Maria-discuss] Updating user's max_connections without restart
by Staffan 28 Nov '18

28 Nov '18

Hi, I've tried to change a user's max_connections after the limit has been reached (connection attempts return "has exceeded the 'max_connections_per_hour' resource"). With MariaDB 10.2.18, running using the official docker image, we have "select @@max_connections;" returning 100. We have a user created "WITH MAX_CONNECTIONS_PER_HOUR 50". Now if we bump in to this limit I fail to allow more connections by increasing it. I've tried the following methods (using both 0 and a high value): ALTER USER 'site_devkit_live_index'@'%' WITH MAX_CONNECTIONS_PER_HOUR 0; UPDATE mysql.user SET max_connections = 0 WHERE user='site_devkit_live_index'; FLUSH PRIVILEGES; GRANT USAGE ON *.* TO 'site_devkit_live_index'@'%' WITH MAX_CONNECTIONS_PER_HOUR 0; The following indicates that the updates work: USE mysql; SELECT host, user, max_user_connections, max_connections FROM user; I've also tried deleting and re-creating the user. What would it take to make these updates affect the current instance? We'd like to avoid restarts. regards /Staffan

2 2