- discuss - lists.mariadb.org

[Maria-discuss] stability of 10.4.7
by Tom Ryan 07 Sep '19

07 Sep '19

We had been using 10.2.x for some time in a galera config with wonderful stability. A disk issue caused us to temporarily have to utilize a single 10.3.x instance (again with no stability issues). After we resolved our disk issue, we decided to move to 10.4.7 (since it was the second stable version) and listed on the website as the "stable version". Unfortunately, nodes in the cluster crash just about everyday. one node usually fails and then another node drops, with errors like 190906 14:37:59 [ERROR] mysqld got signal 11 ; Sep 6 14:37:59 node-2 mysqld[1846]: This could be because you hit a bug. It is also possible that this binary Sep 6 14:37:59 node-2 mysqld[1846]: or one of the libraries it was linked against is corrupt, improperly built, Sep 6 14:37:59 node-2 mysqld[1846]: or misconfigured. This error can also be caused by malfunctioning hardware. Sep 6 14:37:59 node-2 mysqld[1846]: To report this bug, see https://mariadb.com/kb/en/reporting-bugs Sep 6 14:37:59 node-2 mysqld[1846]: We will try our best to scrape up some info that will hopefully help Sep 6 14:37:59 node-2 mysqld[1846]: diagnose the problem, but since we have already crashed, Sep 6 14:37:59 node-2 mysqld[1846]: something is definitely wrong and this may fail. Sep 6 14:37:59 node-2 mysqld[1846]: Server version: 10.4.7-MariaDB-1:10.4.7+maria~xenial-log Sep 6 14:37:59 node-2 mysqld[1846]: key_buffer_size=134217728 Sep 6 14:37:59 node-2 mysqld[1846]: read_buffer_size=2097152 Sep 6 14:37:59 node-2 mysqld[1846]: max_used_connections=30 Sep 6 14:37:59 node-2 mysqld[1846]: max_threads=4002 Sep 6 14:37:59 node-2 mysqld[1846]: thread_count=45 Sep 6 14:37:59 node-2 mysqld[1846]: It is possible that mysqld could use up to Sep 6 14:37:59 node-2 mysqld[1846]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 24817728 K bytes of memory Sep 6 14:37:59 node-2 mysqld[1846]: Hope that's ok; if not, decrease some variables in the equation. Sep 6 14:37:59 node-2 mysqld[1846]: Thread pointer: 0x7f32052a0348 Sep 6 14:37:59 node-2 mysqld[1846]: Attempting backtrace. You can use the following information to find out Sep 6 14:37:59 node-2 mysqld[1846]: where mysqld died. If you see no messages after this, something went Sep 6 14:37:59 node-2 mysqld[1846]: terribly wrong... Sep 6 14:37:59 node-2 mysqld[1846]: stack_bottom = 0x7f3271446dd8 thread_stack 0x49000 Sep 6 14:37:59 node-2 mysqld[1846]: /usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x5644f71dcf4e] Sep 6 14:37:59 node-2 mysqld[1846]: /usr/sbin/mysqld(handle_fatal_signal+0x307)[0x5644f6c70b07] Sep 6 14:37:59 node-2 mysqld[1846]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f33e141d890] Sep 6 14:37:59 node-2 mysqld[1846]: /usr/sbin/mysqld(handler_index_cond_check+0x8d)[0x5644f6c7b1fd] Sep 6 14:37:59 node-2 mysqld[1846]: /usr/sbin/mysqld(+0x566623)[0x5644f6973623] Sep 6 14:37:59 node-2 mysqld[1846]: /usr/sbin/mysqld(+0xbb4ba8)[0x5644f6fc1ba8] This is getting old and is unlike our usual mariadb experience. Looking at the jira for 10.4.8, it appears to fix many problems in 10.4 and I'm hopeful it solves this. In the meantime, any ideas or suggestions for things to look for? Thanks!

2 3

[Maria-discuss] 'Reverse Replication" Rollback Strategy
by Webert de Souza Lima 04 Sep '19

04 Sep '19

Hello, I'm currently working on migrating a Galera 10.3 cluster (A) to Amazon RDS. (B) In order to minimize impacts and downtime, the plan is to have a standard MySQL Slave on RDS (B) to sync data, then do the switch to it and stop the replication A->B. The main concern is a catastrophic scenario on B where a rollback to A is needed. How to bring back only new data that now sits on B to the old cluster A? One approach I saw is to, before switching applications to the new server, stop the replication A->B and enable replication B->A. This is my question here. Before the switch, the data will be the same on A and B but B will not be part of the cluster A, so things like a binlog position change. Is it possible to enable this opposite replication B->A without having to extract a whole dump of B and restoring it on A ? Thanks Regards, Webert Lima *Berlin, Germany* *IRC NICK - WebertRLZ*

1 0

[Maria-discuss] 10.3.x: unknown variable 'innodb_support_xa=1'
by Reindl Harald 03 Sep '19

03 Sep '19

unknown variable 'innodb_support_xa=1' would you funny guys consider things like deperectaion warnings in previous releases or at least offer an option to change all these fucking "i don't know a option because it was removed or you did not compile something in and hence i refuse to start the server" to warnings?

6 23

[Maria-discuss] mariadb + FIPS
by Captain Wiggum 02 Sep '19

02 Sep '19

Hi All, I have searched the archives and forums and cannot find an answer to this question. Does mariadb support FIPS, and if so, how or where is a document about this. I use mariadb 10.3.17 with OpenSSL 1.0.2 with FIPS enabled, all built from source. In FIPS mode, SHA1 is disallowed by openssl, as required by FIPS. However, when I search the mariadb code, SHA1 is used in many places. How can I update mariadb to use sha256, without a ton of recoding? Any tips appreciated. --Capt

4 5

Re: [Maria-discuss] mariadb + FIPS
by Captain Wiggum 02 Sep '19

02 Sep '19

+ list On Mon, Sep 2, 2019 at 12:27 PM Captain Wiggum <captwiggum(a)gmail.com> wrote: > Thanks Ian for your reply. > The link mentioned how to enable FIPS mode at the system level. > But nothing about how to setup mariadb *server* when the system is in > FIPS mode. > The mariadb server uses SHA1, which openssl has disabled due to FIPS mode. > > * Unfortunately it is looking like mariadb *server* is not compatible > with FIPS. >

2 1

[Maria-discuss] SST issue with Rsync
by battossai 26 Aug '19

26 Aug '19

Hello, Anyone can share some info with my current issue ? I started to configure Galera Cluster with MariaDB 10.2. When second server try to join there is error on SST transfer like below : rsyncd[8453]: rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at io.c(504) [receiver=3.1.2] Is it any help how to solve this problem ? Database size on Donor server arround 10GB. Thank you in advance. Regards, Franky Yu

1 0

[Maria-discuss] updating passwords
by Jeff Dyke 25 Aug '19

25 Aug '19

So i've been on a bit of a quest to nail down the reasons i can't autodeploy (via saltstack) mariadb-grants and mariadb-users. But this has nothing to do with saltstack, as i've boiled it down to direct commands executed on 10.3.17 Using ALTER USER foo@'bar' seems to double encode the password: MariaDB [mysql]> select User, Host, Password from user where User = 'jeff'; +------+----------+-------------------------------------------+ | User | Host | Password | +------+----------+-------------------------------------------+ | jeff | 172.16.% | *D02D4C65F4A93325D91DC9E07D45521A8CD2960B | +------+----------+-------------------------------------------+ 1 row in set (0.000 sec) MariaDB [mysql]> alter user jeff@'172.16.%' identified by '*D02D4C65F4A93325D91DC9E07D45521A8CD2960B'; Query OK, 0 rows affected (0.000 sec) MariaDB [mysql]> select User, Host, Password from user where User = 'jeff'; +------+----------+-------------------------------------------+ | User | Host | Password | +------+----------+-------------------------------------------+ | jeff | 172.16.% | *42EF65913FAC3841BEFC25DBCBBB800364B91853 | +------+----------+-------------------------------------------+ 1 row in set (0.000 sec) MariaDB [mysql]> alter user jeff@'172.16.%' identified with mysql_native_password as '*D02D4C65F4A93325D91DC9E07D45521A8CD2960B'; Query OK, 0 rows affected (0.000 sec) MariaDB [mysql]> select User, Host, Password from user where User = 'jeff'; +------+----------+-------------------------------------------+ | User | Host | Password | +------+----------+-------------------------------------------+ | jeff | 172.16.% | *D02D4C65F4A93325D91DC9E07D45521A8CD2960B | +------+----------+-------------------------------------------+ MariaDB [mysql]> select password('*D02D4C65F4A93325D91DC9E07D45521A8CD2960B'); +-------------------------------------------------------+ | password('*D02D4C65F4A93325D91DC9E07D45521A8CD2960B') | +-------------------------------------------------------+ | *42EF65913FAC3841BEFC25DBCBBB800364B91853 | +-------------------------------------------------------+ I can use SET PASSWORD FOR.... MariaDB [mysql]> set password for jeff@'172.16.%' = '*D02D4C65F4A93325D91DC9E07D45521A8CD2960B'; Query OK, 0 rows affected (0.000 sec) MariaDB [mysql]> select User, Host, Password from user where User = 'jeff'; +------+----------+-------------------------------------------+ | User | Host | Password | +------+----------+-------------------------------------------+ | jeff | 172.16.% | *D02D4C65F4A93325D91DC9E07D45521A8CD2960B | +------+----------+-------------------------------------------+ but as you can see above, i can not use alter user jeff@'172.16.%' identified by 'hash' without using mysql_native_password as 'hashed_password' If this does not have enough info i'm glad to give it. if you can decrypt the hash, bully its not my real password :) Thanks and Best, Jeff

2 2

Re: [Maria-discuss] Subquery conversion off-switch
by pslawek83 17 Aug '19

17 Aug '19

Hi Sergei, that would be great as well and i was actually looking to emulate off switch using threshold so sure, optimizer switch seems to make more sense. I'm just looking for any way of disabling this optimization without recompiling the server if possible. Thanks, Slawomir Dnia 16 sierpnia 2019 17:14 Sergei Golubchik <serg(a)mariadb.org> napisał(a): Hi, Slawomir! On Aug 13, pslawek83 wrote: Hi Guys, is in_predicate_conversion_th going to be re-enabled for release builds in some next mariadb release? If I make pull request, will you take it? Basically for everyone not aware about the issue, this forced IN-predicate to subquery conversion is de-generating some simple queries so badly that they start to take couple of hours instead of seconds, and there is currently no way of fixing these queries nor to turn this conversion off. Thanks, Slawomir. Perhaps instead of in_predicate_conversion_thresh we'd better add an optimizer switch to disable this optimization? I've commented in jira.mariadb.org jira.mariadb.org Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

[Maria-discuss] Subquery conversion off-switch
by pslawek83 16 Aug '19

16 Aug '19

Hi Guys, is in_predicate_conversion_th going to be re-enabled for release builds in some next mariadb release? If I make pull request, will you take it? Basically for everyone not aware about the issue, this forced IN-predicate to subquery conversion is de-generating some simple queries so badly that they start to take couple of hours instead of seconds, and there is currently no way of fixing these queries nor to turn this conversion off. Thanks, Slawomir.

2 1

[Maria-discuss] Disk increase with MAD and MAI extension files in tmp dir
by Kevin DG 07 Aug '19

07 Aug '19

Hello all, MariaDB version -> 10.3.14 Recently, we had a new problem with our MariaDB instance. Indeed, suddenly the size of the tmp directory has increased almost instantaneously, to finish saturating the disk. We have encountered this problem twice and don't understand currently the problem origin. The result of 'ls -l /tmp' during the problem: mysql@16c212e7dbb5:/tmp# ls -l total 126786988 -rw-rw---- 1 mysql mysql 14190428160 Jul 8 15:18 '#sql_1_1.MAD' -rw-rw---- 1 mysql mysql 8192 Jul 8 15:02 '#sql_1_1.MAI' -rw-rw---- 1 mysql mysql 13344178176 Jul 8 15:18 '#sql_1_11.MAD' -rw-rw---- 1 mysql mysql 8192 Jul 8 15:02 '#sql_1_11.MAI' -rw-rw---- 1 mysql mysql 13344546816 Jul 8 15:18 '#sql_1_14.MAD' -rw-rw---- 1 mysql mysql 8192 Jul 8 15:02 '#sql_1_14.MAI' -rw-rw---- 1 mysql mysql 8192 Jul 8 15:18 '#sql_1_2.MAD' -rw-rw---- 1 mysql mysql 8192 Jul 8 15:18 '#sql_1_2.MAI' -rw-rw---- 1 mysql mysql 12613459968 Jul 8 15:20 '#sql_1_25.MAD' -rw-rw---- 1 mysql mysql 8192 Jul 8 15:03 '#sql_1_25.MAI' -rw-rw---- 1 mysql mysql 12221440000 Jul 8 15:20 '#sql_1_26.MAD' -rw-rw---- 1 mysql mysql 8192 Jul 8 15:03 '#sql_1_26.MAI' -rw-rw---- 1 mysql mysql 12220719104 Jul 8 15:20 '#sql_1_29.MAD' -rw-rw---- 1 mysql mysql 8192 Jul 8 15:03 '#sql_1_29.MAI' -rw-rw---- 1 mysql mysql 12220907520 Jul 8 15:20 '#sql_1_36.MAD' -rw-rw---- 1 mysql mysql 8192 Jul 8 15:03 '#sql_1_36.MAI' -rw-rw---- 1 mysql mysql 14190247936 Jul 8 15:18 '#sql_1_4.MAD' -rw-rw---- 1 mysql mysql 8192 Jul 8 15:02 '#sql_1_4.MAI' -rw-rw---- 1 mysql mysql 12220588032 Jul 8 15:18 '#sql_1_47.MAD' -rw-rw---- 1 mysql mysql 8192 Jul 8 15:03 '#sql_1_47.MAI' -rw-rw---- 1 mysql mysql 13350912000 Jul 8 15:18 '#sql_1_6.MAD' -rw-rw---- 1 mysql mysql 8192 Jul 8 15:02 '#sql_1_6.MAI' We failed to identify the origin of this behaviour. Does anyone know what can trigger this behavior ? We also failed to find a configuration paramater to avoid and limit the size of these files, any ideas about that ? Thanks for your help,

4 4