July 2016 - discuss - lists.mariadb.org

[Maria-discuss] why stdout? -> [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 115096
by Reindl Harald 05 Jul '20

05 Jul '20

Aug 6 12:24:24 testserver mysqld: 150806 12:24:24 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 115096 ... why is this now stdout instead mysql logs? on systemd based distributions that spits now to the global syslog and finally on machines restarting 2 instances every hour for backup reasons it annoys until 10.0.19 or 10.0.20 that was not this way

5 13

[Maria-discuss] MariaDB Knowledge base - 500 error
by Karthick Subramanian 21 Oct '16

21 Oct '16

Did anyone facing this 500 error while accessing the Maria DB Knowledge Base. Thank you. Don't know to whom we need to report this, so sending to this mail ID. Sorry if it cause any inconvenient for others. When we click the Support in MariaDb website, getting below error: Database Error: *There seems to be a problem connecting to the database server specified in your configuration file. Please contact your local system administrator for further assistance. *

4 3

[Maria-discuss] Virtual CHECK constraint using Virtual columns
by Peter Laursen 16 Oct '16

16 Oct '16

As described in this Blog http://mablomy.blogspot.dk/2016/04/check-constraint-for-mysql-not-null-on.h…. A very nice hack/trick IMO. However it is not working with MariaDB as VC's cannot be declared NOT NULL. What prevents that? -- Peter -- Webyog

3 7

Re: [Maria-discuss] Semi-sync replication hangs when changing binlog filename.
by Joseph Glanville 16 Aug '16

16 Aug '16

Hi Pavel. Yes, by "binlog filename changes" I mean the master begins writing to a new binlog file. Output of all the requested commands are in this gist: https://gist.github.com/josephglanville/7b96c34bb6e79ace33e56627672b98a5 Joseph Glanville Sent from Polymail<https://polymail.io/?utm_source=polymail&utm_medium=referral&utm_campaign=s…> On Fri, 29 Jul 2016 at 3:08 PM Pavel Ivanov <Pavel Ivanov <mailto:Pavel%20Ivanov%20<pivanof(a)google.com>> > wrote: By "binlog filename changes" you mean when master starts writing binlogs into a new file? Can you clarify how the replication stalls? What "show processlist" shows at that time on master and on slave? What does "show slave status" show on the slave? On Thu, Jul 28, 2016 at 10:03 PM, Will Fong wrote: > Hi Joseph, > > On Fri, Jul 29, 2016 at 10:11 AM, Joseph Glanville wrote: >> However whenever the binlog filename changes the replication stalls >> indefinitely. > > Interesting! I may have reproduced this, but it was only a quick test. > Let me (or someone else) dig into this more. > > Thanks for reporting this. > -will > > > -- > Will Fong, Senior Support Engineer > MariaDB Corporation > > _______________________________________________ > 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

4 16

[Maria-discuss] Known limitation with TokuDB in Read Free Replication & parallel replication ?
by jocelyn fournier 10 Aug '16

10 Aug '16

Hi, After upgrading from TokuDB Enterprise with MariaDB 5.5 to MariaDB 10.1.14, I tried to enable the parallel replication (parallel_mode=optimistic, slave_parallel_threads=4) on a GTID enabled RFR slave, but it leads to random failures. (both master & slave are running 10.1.14) E.g : Could not execute Update_rows_v1 event on table sc_2.sc_param_index; Can't find record in 'sc_param_index', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.008418, end_log_pos 217608066 If I issue a start slave (with sql_slave_skip_counter=0) : Could not execute Update_rows_v1 event on table sc_2.sc_log_cron; Can't find record in 'sc_log_cron', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.008418, end_log_pos 218275984 If I put back slave_parallel_threads to 0, the slave keeps replicating happily without any issue. Is this a known limitation with TokuDB ? Tokudb configuration : tokudb_rpl_lookup_rows=0 tokudb_rpl_unique_checks=0 tokudb_pk_insert_mode=2 tokudb_directio = 1 Thanks and regards, Jocelyn Fournier

3 18

[Maria-discuss] Help on ERROR 1819 (HY000): Your password does not satisfy the current policy requirements
by Karthick Subramanian 07 Aug '16

07 Aug '16

Dear Experts, I almost tried all sort of combinations that I think of very difficult to crack, but repeatedly failed to satisfy MariaDB not throw this error. Can anyone guide me on what is the specific needs for successful password. Warning message: +---------+------+----------------------------------------------------------------+ | Level | Code | Message | +---------+------+----------------------------------------------------------------+ | Warning | 1819 | cracklib: error loading dictionary | | Error | 1819 | Your password does not satisfy the current policy requirements | +---------+------+----------------------------------------------------------------+ Regards, Karth

2 2

[Maria-discuss] Semi-sync replication hangs when changing binlog filename.
by Joseph Glanville 29 Jul '16

29 Jul '16

Hi, I am using semi-sync replication with the `rpl_semi_sync_master_timeout` set to a very high value to ensure commits aren't committed on the master unless they have been replicated to the slave. However whenever the binlog filename changes the replication stalls indefinitely. A trace of this interaction between the master and the semi-sync slave is here: https://gist.github.com/josephglanville/e87ae96b9be9125427b58cd3a43d5c1e The semi-sync settings I have configured on the master are: rpl_semi_sync_master_wait_point = "AFTER_SYNC" rpl_semi_sync_master_timeout = 18446744073709551615 # effectively infinite as we don't want to fallback to async repl rpl_semi_sync_master_enabled = 1 rpl_semi_sync_master_wait_no_slave = 1 # don't allow writes if slave isn't connected Up until the binlog filename change everything works as expected. Anyone have any ideas on how to fix the problem or is this a bug in semi-sync replication? Joseph.

3 3

[Maria-discuss] Orphaned TokuDB tables
by Reinis Rozitis 29 Jul '16

29 Jul '16

Hello, tldr - Is there a way (similarly as with the InnoDB workaround of DROP TABLE `#mysql50##sql-..') to delete an orphaned TokuDB table (and/or clean the information_schema.tokudb_file_map)? Or should I address this to Percona/Toku people? The long version: I have noticed on one db instance (currently running 10.0.26) and orphaned table (no idea how it got there): ls -la /data/mysql/db/ -rw-r----- 1 mysql mysql 1114 Jul 29 01:41 #sql-6f2d_9.frm -rw-r----- 1 mysql mysql 908 Jul 29 01:41 #sql-6f2d_9.par Also: MariaDB [(none)]> SELECT * FROM information_schema.tokudb_file_map limit 10; +--------------------------------+-----------------------------------------------------+--------------+------------+-----------------------+ | dictionary_name | internal_file_name | table_schema | table_name | table_dictionary_name | +--------------------------------+-----------------------------------------------------+--------------+------------+-----------------------+ | ./db/#sql-6f2d_9#P#p1-key-aid | ./_db_sql_6f2d_9_P_p1_key_aid_1734_2_1b_B_0.tokudb | db | #sql | 6f2d_9#P#p1-key-aid | | ./db/#sql-6f2d_9#P#p1-main | ./_db_sql_6f2d_9_P_p1_main_1734_2_1b_B_1.tokudb | db | #sql | 6f2d_9#P#p1-main | | ./db/#sql-6f2d_9#P#p1-status | ./_db_sql_6f2d_9_P_p1_status_1609_1_1b.tokudb | db | #sql | 6f2d_9#P#p1-status | .... While I can DROP the table: MariaDB [db]> drop table `#mysql50##sql-6f2d_9`; Query OK, 0 rows affected, 1 warning (3.99 sec) And even physically delete the ./_db_sql_6f2d_9_P* files from the root datadir it never disappears from the information_schema tables. It doesn't seem to currently affect anything but I wanted to know if maybe there is a workaround or other ways to rebuild to Toku directory (without dumping/reimporting the whole database). rr

2 2

[Maria-discuss] Crash when adding a column to a very large table
by Mark Wadham 27 Jul '16

27 Jul '16

Hi, MariaDB 10.1.16 with a 3-node galera cluster. We had 187GB free disk space and had the gcache set to 800GB. We started firing write traffic at the cluster and then began testing the process of performing DDL on a single node in RSU mode. Our command was a single ALTER TABLE statement that added a column to a ~160GB table. While this was occurring we were firing around 20GB/hour of write traffic at the cluster which was being collected in the gcache for catchup after the node completed the DDL. At around 3h 45min into the DDL process the node performing it crashed with an error indicating it was unable to write to a temporary ibdata file. There was still plenty of disk space available. Full crash log is below, if anyone can shed light on this we'd be very grateful. My own research so far suggests that the problem is because the ALTER TABLE statement inserts all of the rows into the newly rebuilt table at once, effectively requiring a rollback to be created for every row in the table and this is just too much for *some limit* that I haven't worked out yet. I saw a suggestion[1] to increase the number of ibdata files but this doesn't really make sense to me given that we have two and the second one is set to autoextend. It's a very slow debug process so I'd like to get a reasonable idea of what happened here before starting another test run. Thanks, Mark [1] http://dba.stackexchange.com/questions/68319/mysql-index-creation-failing-o… -------------------- 2016-07-27 8:45:59 140258863733504 [Note] InnoDB: Online DDL : Start 2016-07-27 8:45:59 140258863733504 [Note] InnoDB: Online DDL : Start reading clustered index of the table and create temporary files 2016-07-27 9:42:23 140258863733504 [Note] InnoDB: Online DDL : End of reading clustered index of the table and create temporary files 2016-07-27 9:42:23 140258863733504 [Note] InnoDB: Online DDL : Start merge-sorting index `PRIMARY` (1 / 4), estimated cost : 14.7886 2016-07-27 9:42:23 140258863733504 [Note] InnoDB: Online DDL : merge-sorting has estimated 72714 runs 2016-07-27 11:47:05 140258863733504 [Note] InnoDB: Online DDL : End of merge-sorting index `PRIMARY` (1 / 4) 2016-07-27 11:47:05 140258863733504 [Note] InnoDB: Online DDL : Start building index `PRIMARY` (1 / 4), estimated cost : 22.1242 2016-07-27 12:26:52 7f908fbfdb00 InnoDB: Error: Write to file ./db/#sql-ib16588-3044794026.ibd failed at offset 54409560064. InnoDB: 1048576 bytes should have been written, only 991232 were written. InnoDB: Operating system error n2016-07-27 12:26:52 140258863733504 [Note] InnoDB: Online DDL : Completed 2016-07-27 12:26:53 7f908fbfdb00 InnoDB: Assertion failure in thread 140258863733504 in file handler0alter.cc line 137 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 160727 12:26:53 [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.1.16-MariaDB key_buffer_size=33554432 read_buffer_size=16777216 max_used_connections=4 max_threads=770 thread_count=11 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 37895560 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7ebbabfb9008 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 = 0x7f908fbfd180 thread_stack 0x48400 (my_addr_resolve failure: fork) /usr/sbin/mysqld(my_print_stacktrace+0x2b) [0x555e557caaab] /usr/sbin/mysqld(handle_fatal_signal+0x475) [0x555e55327ef5] /lib64/libpthread.so.0(+0xf100) [0x7f90982ce100] /lib64/libc.so.6(gsignal+0x37) [0x7f909663b5f7] /lib64/libc.so.6(abort+0x148) [0x7f909663cce8] /usr/sbin/mysqld(+0x734ff9) [0x555e55491ff9] /usr/sbin/mysqld(+0x736eec) [0x555e55493eec] /usr/sbin/mysqld(+0x3a4c24) [0x555e55101c24] /usr/sbin/mysqld(mysql_alter_table(THD*, char*, char*, HA_CREATE_INFO*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool)+0x27f9) [0x555e5523dff9] /usr/sbin/mysqld(Sql_cmd_alter_table::execute(THD*)+0x5d7) [0x555e5527f8b7] /usr/sbin/mysqld(mysql_execute_command(THD*)+0x140f) [0x555e551b533f] /usr/sbin/mysqld(mysql_parse(THD*, char*, unsigned int, Parser_state*)+0x28d) [0x555e551bd1ed] /usr/sbin/mysqld(+0x4602ec) [0x555e551bd2ec] /usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x1c63) [0x555e551bf673] /usr/sbin/mysqld(do_command(THD*)+0x16b) [0x555e551c023b] /usr/sbin/mysqld(do_handle_one_connection(THD*)+0x17f) [0x555e5527c74f] /usr/sbin/mysqld(handle_one_connection+0x47) [0x555e5527c8a7] /lib64/libpthread.so.0(+0x7dc5) [0x7f90982c6dc5] /lib64/libc.so.6(clone+0x6d) [0x7f90966fcc9d] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7ebb7102f020): is an invalid pointer Connection ID (thread ID): 212 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=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=off 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: alter table delivery_person add column boris int(11) null 160727 12:26:58 mysqld_safe Number of processes running now: 0 160727 12:26:58 mysqld_safe WSREP: not restarting wsrep node automatically 160727 12:26:58 mysqld_safe mysqld from pid file /mysql/data/galera0.pid ended

1 0

[Maria-discuss] Finicky syntax with RETURNING?
by Rhys.Campbell＠swisscom.com 27 Jul '16

27 Jul '16

Hello All, I'm having a bit of an issue with the RETURNING feature of DELETE<https://mariadb.com/kb/en/mariadb/delete/>. This was introduced in MariaDB 10.0.5. Specifically there seems to be an issue when using aliases with the RETURNING keyword. It involves a query like this. A user came to me with queries of this form that were running slowly. Here is the explain plan... EXPLAIN DELETE from t1 where id in (select id from t1 where acc_id = 9999) \G *************************** 1. row *************************** id: 1 select_type: PRIMARY table: t1 type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 4675 Extra: Using where *************************** 2. row *************************** id: 2 select_type: DEPENDENT SUBQUERY table: t2 type: unique_subquery possible_keys: XXXXXXXXXX key: PRIMARY key_len: 4 ref: func rows: 1 Extra: Using where 2 rows in set (0.00 sec) You can see it's being forced to run a table scan and run the subquery for each row. This was fixed by properly aliasing the query... EXPLAIN EXTENDED DELETE uc from t1 AS uc where uc. id in (select p. id from t2 p where p.acc_id = 9999) \G *************************** 1. row *************************** id: 1 select_type: PRIMARY table: p type: ref possible_keys: XXXXXXXXXXXXXXXXXXXXXXXX key: uk_XXXXXXXXXXXXXXXXXXXX key_len: 4 ref: const rows: 1 filtered: 100.00 Extra: Using index *************************** 2. row *************************** id: 1 select_type: PRIMARY table: uc type: ref possible_keys: XXXXXXXXXXXXXXXXXXX key: XXXXXXXXXXXXXX key_len: 4 ref: XXXXXXXXXXXXXX rows: 1 filtered: 100.00 Extra: 2 rows in set (0.00 sec) There now seems to be an issue when attempting to use the RETURNING keyword with this aliases version of the query. I have tried numerous versions of this query... EXPLAIN DELETE uc FROM t1 AS uc WHERE uc.id IN (SELECT p.id FROM t2 AS p WHERE p.account_id = 9999) RETURNING uc.some_id; EXPLAIN DELETE uc FROM t1 uc INNER JOIN t2 p ON uc.id = p.id WHERE p.acc_id = 9999 RETURNING some_id; All of these produce a SQL syntax error. I've tried a range of ways of writing this, using different joins, subqueries, with and without the AS keyword. The issues seems to be with aliases. The only version I can seem to get to work is this (note the removal of the aliases)... EXPLAIN DELETE FROM t1 WHERE id IN (SELECT id FROM t2 WHERE acc_id = 9999) RETURNING some_id; But then that creates the slow table scan problem again. Anyone have any experience of this? Cheers, Rhys

2 3