- discuss - lists.mariadb.org

[Maria-discuss] Rolling upgrade to Galera 10.4 not working
by Tiemen Ruiten 01 Jul '19

01 Jul '19

Hello, I'm trying to do a rolling upgrade of a MariaDB 10.3 Galera cluster to to 10.4, following the instructions here <https://mariadb.com/kb/en/library/upgrading-from-mariadb-103-to-mariadb-104…>. (I had to adjust the wsrep_provider variable for Galera 4 to /usr/lib64/galera-4/libgalera_smm.so, not mentioned in the instructions). After I start the mariadb service, one mysqld thread uses 100% of one core for about 45 minutes, then I see the following in the log and mariadb restarts, repeating the same process: Jun 20 16:24:44 rubidium mysqld: 2019-06-20 16:24:44 0 [Note] WSREP: Trying to continue unpaused monitor Jun 20 16:24:47 rubidium mysqld: 2019-06-20 16:24:47 3 [Note] WSREP: REPL Protocols: 9 (4, 2) Jun 20 16:24:47 rubidium mysqld: 2019-06-20 16:24:47 3 [Note] WSREP: ####### My UUID: ddb4f4da-935f-11e9-bcff-8209857266f0 Jun 20 16:24:47 rubidium mysqld: 2019-06-20 16:24:47 3 [Note] WSREP: Server mariadb4 connected to cluster at position 6a1fd0aa-4739-11e5-af88-42756e861245:7403466644 with ID ddb4f4da-935f-11e9-bcff-8209857266f0 Jun 20 16:24:47 rubidium mysqld: 2019-06-20 16:24:47 3 [Note] WSREP: Server status change disconnected -> connected Jun 20 16:24:47 rubidium mysqld: 2019-06-20 16:24:47 3 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. Jun 20 16:24:47 rubidium mysqld: 2019-06-20 16:24:47 3 [Note] WSREP: State transfer required: Jun 20 16:24:47 rubidium mysqld: Group state: 6a1fd0aa-4739-11e5-af88-42756e861245:7403466644 Jun 20 16:24:47 rubidium mysqld: Local state: 6a1fd0aa-4739-11e5-af88-42756e861245:7403368279 Jun 20 16:24:47 rubidium mysqld: 2019-06-20 16:24:47 3 [Note] WSREP: Server status change connected -> joiner Jun 20 16:24:47 rubidium mysqld: 2019-06-20 16:24:47 3 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. Jun 20 16:24:47 rubidium mysqld: 2019-06-20 16:24:47 0 [Note] WSREP: Running: 'wsrep_sst_rsync --role 'joiner' --address '10.100.130.24' --datadir '/var/lib/mysql/' --parent '21283' '' ''' Jun 20 16:24:48 rubidium rsyncd[26235]: rsyncd version 3.1.2 starting, listening on port 4444 Jun 20 16:24:48 rubidium mysqld: 2019-06-20 16:24:48 3 [Note] WSREP: Prepared SST request: rsync|10.100.130.24:4444/rsync_sst Jun 20 16:24:48 rubidium mysqld: 2019-06-20 16:24:48 3 [Note] WSREP: Cert index reset to 6a1fd0aa-4739-11e5-af88-42756e861245:7403466644 (proto: 9), state transfer needed: yes Jun 20 16:24:48 rubidium mysqld: 2019-06-20 16:24:48 0 [Note] WSREP: Service thread queue flushed. Jun 20 16:24:48 rubidium mysqld: 2019-06-20 16:24:48 3 [Note] WSREP: ####### Assign initial position for certification: 6a1fd0aa-4739-11e5-af88-42756e861245:7403466644, protocol version: 4 Jun 20 16:24:48 rubidium mysqld: 2019-06-20 16:24:48 3 [Note] WSREP: ####### IST uuid:6a1fd0aa-4739-11e5-af88-42756e861245 f: 7403368280, l: 7403466644, STRv: 2 Jun 20 16:24:48 rubidium mysqld: 2019-06-20 16:24:48 3 [Note] WSREP: IST receiver addr using tcp://10.100.130.24:4568 Jun 20 16:24:48 rubidium mysqld: 2019-06-20 16:24:48 3 [Note] WSREP: Prepared IST receiver for 7403368280-7403466644, listening at: tcp:// 10.100.130.24:4568 Jun 20 16:24:48 rubidium mysqld: 2019-06-20 16:24:48 0 [Note] WSREP: Member 2.0 (mariadb4) requested state transfer from 'mariadb2'. Selected 1.0 (mariadb2)(SYNCED) as donor. Jun 20 16:24:48 rubidium mysqld: 2019-06-20 16:24:48 0 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 7403946566) Jun 20 16:24:48 rubidium mysqld: 2019-06-20 16:24:48 3 [ERROR] WSREP: Slave queue grew too long while trying to request state transfer 1 time(s). Please make sure that there is at least one fully synced member in the group. Application must be restarted. Jun 20 16:24:48 rubidium mysqld: 2019-06-20 16:24:48 3 [ERROR] WSREP: State transfer request failed unrecoverably: 35 (Resource deadlock avoided). Most likely it is due to inability to communicate with the cluster primary component. Restart required. On the donor, I see: 2019-06-20 16:24:44 0 [Note] WSREP: Trying to continue unpaused monitor 2019-06-20 16:24:48 0 [Note] WSREP: Member 2.0 (mariadb4) requested state transfer from 'mariadb2'. Selected 1.0 (mariadb2)(SYNCED) as donor. 2019-06-20 16:24:48 0 [Note] WSREP: Shifting SYNCED -> DONOR/DESYNCED (TO: 7403946566) 2019-06-20 16:24:48 18 [Note] WSREP: IST request: 6a1fd0aa-4739-11e5-af88-42756e861245:7403368279-7403466644|tcp:// 10.100.130.24:4568 2019-06-20 16:24:48 18 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. 2019-06-20 16:24:48 0 [Note] WSREP: Running: 'wsrep_sst_rsync --role 'donor' --address '10.100.130.24:4444/rsync_sst' --socket '/var/lib/mysql/mysql.sock' --datadir '/var/lib/mysql/' '' --gtid '6a1fd0aa-4739-11e5-af88-42756e861245:7403368279' --gtid-domain-id '0' --bypass' 2019-06-20 16:24:48 18 [Note] WSREP: sst_donor_thread signaled with 0 2019-06-20 16:24:48 0 [Note] WSREP: async IST sender starting to serve tcp://10.100.130.24:4568 sending 7403368280-7403466644 2019-06-20 16:24:48 0 [Note] WSREP: (700b363f, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://10.100.130.24:4567 2019-06-20 16:24:48 0 [Note] WSREP: declaring 116c0b4c at tcp:// 10.100.130.22:4567 stable 2019-06-20 16:24:48 0 [Note] WSREP: forgetting ddb4f4da (tcp:// 10.100.130.24:4567) 2019-06-20 16:24:48 0 [Note] WSREP: (700b363f, 'tcp://0.0.0.0:4567') turning message relay requesting off 2019-06-20 16:24:48 0 [Note] WSREP: Node 116c0b4c state prim 2019-06-20 16:24:48 0 [Note] WSREP: view(view_id(PRIM,116c0b4c,297) memb { 116c0b4c,0 700b363f,0 } joined { } left { } partitioned { ddb4f4da,0 }) 2019-06-20 16:24:48 0 [Note] WSREP: save pc into disk 2019-06-20 16:24:48 0 [Note] WSREP: forgetting ddb4f4da (tcp:// 10.100.130.24:4567) 2019-06-20 16:24:48 0 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 1, memb_num = 2 2019-06-20 16:24:48 0 [Note] WSREP: STATE EXCHANGE: Waiting for state UUID. 2019-06-20 16:24:48 0 [Note] WSREP: STATE EXCHANGE: sent state msg: 286f5ce4-9367-11e9-acee-4e4dec61d7c1 2019-06-20 16:24:48 0 [Note] WSREP: STATE EXCHANGE: got state msg: 286f5ce4-9367-11e9-acee-4e4dec61d7c1 from 0 (mariadb1) 2019-06-20 16:24:48 0 [Note] WSREP: STATE EXCHANGE: got state msg: 286f5ce4-9367-11e9-acee-4e4dec61d7c1 from 1 (mariadb2) 2019-06-20 16:24:48 0 [Note] WSREP: Quorum results: version = 4, component = PRIMARY, conf_id = 269, members = 2/2 (joined/total), act_id = 7403946566, last_appl. = 7403946444, protocols = 0/9/3 (gcs/repl/appl), group UUID = 6a1fd0aa-4739-11e5-af88-42756e861245 2019-06-20 16:24:48 0 [Note] WSREP: Flow-control interval: [23, 23] 2019-06-20 16:24:48 0 [Note] WSREP: Trying to continue unpaused monitor 2019-06-20 16:24:48 14 [Note] WSREP: New cluster view: global state: 6a1fd0aa-4739-11e5-af88-42756e861245:7403946566, view# 270: Primary, number of nodes: 2, my index: 1, protocol version 3 2019-06-20 16:24:48 14 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification. 2019-06-20 16:24:48 14 [Note] WSREP: REPL Protocols: 9 (4, 2) 2019-06-20 16:24:48 14 [Note] WSREP: Assign initial position for certification: 7403946566, protocol version: 4 2019-06-20 16:24:48 0 [Note] WSREP: Service thread queue flushed. 2019-06-20 16:24:48 0 [ERROR] WSREP: async IST sender failed to serve tcp:// 10.100.130.24:4568: ist send failed: asio.system:104', asio error 'read: Connection reset by peer': 104 (Connection reset by peer) at galera/src/ist.cpp:send():790 2019-06-20 16:24:48 0 [Note] WSREP: async IST sender served WSREP_SST: [INFO] Bypassing state dump. (20190620 16:24:48.149) rsync: safe_read failed to read 1 bytes [sender]: Connection reset by peer (104) rsync error: error in rsync protocol data stream (code 12) at io.c(276) [sender=3.1.2] 2019-06-20 16:24:48 0 [ERROR] WSREP: Failed to read from: wsrep_sst_rsync --role 'donor' --address '10.100.130.24:4444/rsync_sst' --socket '/var/lib/mysql/mysql.sock' --datadir '/var/lib/mysql/' '' --gtid '6a1fd0aa-4739-11e5-af88-42756e861245:7403368279' --gtid-domain-id '0' --bypass 2019-06-20 16:24:48 0 [ERROR] WSREP: Process completed with error: wsrep_sst_rsync --role 'donor' --address '10.100.130.24:4444/rsync_sst' --socket '/var/lib/mysql/mysql.sock' --datadir '/var/lib/mysql/' '' --gtid '6a1fd0aa-4739-11e5-af88-42756e861245:7403368279' --gtid-domain-id '0' --bypass: 12 (Cannot allocate memory) 2019-06-20 16:24:48 0 [ERROR] WSREP: Command did not run: wsrep_sst_rsync --role 'donor' --address '10.100.130.24:4444/rsync_sst' --socket '/var/lib/mysql/mysql.sock' --datadir '/var/lib/mysql/' '' --gtid '6a1fd0aa-4739-11e5-af88-42756e861245:7403368279' --gtid-domain-id '0' --bypass 2019-06-20 16:24:48 0 [Warning] WSREP: Could not find peer: ddb4f4da-935f-11e9-bcff-8209857266f0 2019-06-20 16:24:48 0 [Warning] WSREP: 1.0 (mariadb2): State transfer to -1.-1 (left the group) failed: -12 (Cannot allocate memory) What is going on?

2 3

[Maria-discuss] execute failed: Incorrect string value: '\xD6sterl...' with mariadb and perl DBD
by Dave Wreski 25 Jun '19

25 Jun '19

Hi, I'm trying to use perl-DBD to write a buffer of text that contains an email with umlauts and other non-ASCII characters to a joomla database and having a problem. DBD::mysql::st execute failed: Incorrect string value: '\xD6sterl...' for column `lsv5webstage`.`xuxgc_content`.`fulltext` at row 1 at /home/alerts/scripts_linstage/AdvisoryTest.pm line 373. I'm not familiar enough with how encoding works to fully understand what the problem is. This is a fedora29 system with mariadb-10.3.12 and joomla-3.9. Apparently the '\xD6' is an O with an umlaut in "Sebastian �sterlund". I read something about utf8 not being able to handle 4-char, but I don't fully understand. I found the following reference online which talks about changing the encoding type from utf8 to utf8mb4, but the tables all appear to already be using that encoding: > SHOW VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%'; +--------------------------+--------------------+ | Variable_name | Value | +--------------------------+--------------------+ | character_set_client | utf8mb4 | | character_set_connection | utf8mb4 | | character_set_database | utf8mb4 | | character_set_filesystem | binary | | character_set_results | utf8mb4 | | character_set_server | utf8mb4 | | character_set_system | utf8 | | collation_connection | utf8mb4_unicode_ci | | collation_database | utf8mb4_unicode_ci | | collation_server | utf8mb4_unicode_ci | +--------------------------+--------------------+ execute failed: Incorrect string value: '\xD6sterl...' with mariadb and perl DBD a novice perl programmer I'm not sure it's helpful, but this is the insert statement I'm using in my perl code: my $sql = <<EOF; INSERT INTO xuxgc_content (title, alias, introtext, `fulltext`, state, catid, created, created_by, created_by_alias, modified, modified_by, checked_out, checked_out_time, publish_up, publish_down, images, urls, attribs, version, ordering, metakey, metadesc, metadata, access, hits, language) VALUES ($title, "$title_alias", $introText, $fullText, $state, $catid, $created, $created_by, $created_by_alias, $modified, $modified_by, $checked_out, $checked_out_time, $publish_up, $publish_down, $images, $urls, $attribs, $version, $ordering, $metakey, $metadesc, $metadata, $access, $hits, $language); EOF my $sth = $dbh->prepare($sql); $sth->execute(); db_disconnect($dbh); I don't recall having this problem in the past, and this script has been in use for quite a while. What am I doing wrong?

3 4

[Maria-discuss] pam authentication not working after few hours
by Fabrizio Gerardi 25 Jun '19

25 Jun '19

Hi everyone, I have problems with mariadb 10.3.15 in a centos 7 environment. I configured mariadb to authenticate users via pam module while the system is a member of an active directory domain. Everything works fine except that authentication process stops working after few hours. Please note that only users authenticated via pam are facing this issue. Local users keep authenticating... The moment I restart mariadb service everything works fine again. Would you please confirm whether this issue is somewhat related with others I read will be fixed in next release (10.3.16) or not? Thank you, Fabrizio

2 3

[Maria-discuss] clean MDB 10.4.7 install fails `mysql_upgrade` with FATAL ERROR: "Illegal mix of collations (utf8mb4_unicode_ci, COERCIBLE) and (utf8mb4_general_ci, COERCIBLE) for operation 'like'"
by PGNet Dev 21 Jun '19

21 Jun '19

I'm setting up a new MDB instance, mysqld -V mysqld Ver 10.4.7-MariaDB-log for Linux on x86_64 (Source distribution) I've configured my charsets/collations according to: https://mariadb.com/kb/en/library/setting-character-sets-and-collations/#ex… my config includes cat /usr/local/etc/mariadb/my.cnf [client] default-character-set = utf8mb4 ... [mysqld] init-connect = 'SET NAMES utf8mb4' collation-server = utf8mb4_unicode_ci character-set-server = utf8mb4 ... [mysql] default-character-set = utf8mb4 ... MDB was built with ... -DDEFAULT_CHARSET=utf8mb4 -DDEFAULT_COLLATION=utf8mb4_unicode_ci -DWITH_EXTRA_CHARSETS=all ... I initialize data with: /opt/mariadb/scripts/mysql_install_db --user=mysql --datadir=/data/db/mariadb --defaults-file=/usr/local/etc/mariadb/my.cnf No error during initialization, & subsequently MDB starts as expected. But if I next exec `mysql_upgrade`, it FAILS with Phase 1/7: Checking and upgrading mysql database Processing databases mysql mysql.column_stats OK mysql.columns_priv OK mysql.db OK mysql.event OK mysql.func OK mysql.global_priv OK mysql.gtid_slave_pos OK mysql.help_category OK mysql.help_keyword OK mysql.help_relation OK mysql.help_topic OK mysql.index_stats OK mysql.innodb_index_stats OK mysql.innodb_table_stats OK mysql.plugin OK mysql.proc OK mysql.procs_priv OK mysql.proxies_priv OK mysql.roles_mapping OK mysql.servers OK mysql.table_stats OK mysql.tables_priv OK mysql.time_zone OK mysql.time_zone_leap_second OK mysql.time_zone_name OK mysql.time_zone_transition OK mysql.time_zone_transition_type OK mysql.transaction_registry OK Phase 2/7: Installing used storage engines... Skipped Phase 3/7: Fixing views mysql.user OK Phase 4/7: Running 'mysql_fix_privilege_tables' ERROR 1267 (HY000) at line 7: Illegal mix of collations (utf8mb4_unicode_ci,COERCIBLE) and (utf8mb4_general_ci,COERCIBLE) for operation 'like' ERROR 1267 (HY000) at line 59: Illegal mix of collations (utf8mb4_unicode_ci,COERCIBLE) and (utf8mb4_general_ci,COERCIBLE) for operation 'like' ERROR 1267 (HY000) at line 168: Illegal mix of collations (utf8mb4_unicode_ci,COERCIBLE) and (utf8mb4_general_ci,COERCIBLE) for operation 'like' ERROR 1267 (HY000) at line 179: Illegal mix of collations (utf8mb4_unicode_ci,COERCIBLE) and (utf8mb4_general_ci,COERCIBLE) for operation 'like' ERROR 1267 (HY000) at line 195: Illegal mix of collations (utf8mb4_unicode_ci,COERCIBLE) and (utf8mb4_general_ci,COERCIBLE) for operation 'like' ERROR 1267 (HY000) at line 322: Illegal mix of collations (utf8mb4_unicode_ci,COERCIBLE) and (utf8mb4_general_ci,COERCIBLE) for operation 'like' ERROR 1267 (HY000) at line 393: Illegal mix of collations (utf8mb4_unicode_ci,COERCIBLE) and (utf8mb4_general_ci,COERCIBLE) for operation 'like' ERROR 1267 (HY000) at line 400: Illegal mix of collations (utf8mb4_unicode_ci,COERCIBLE) and (utf8mb4_general_ci,COERCIBLE) for operation 'like' ERROR 1267 (HY000) at line 407: Illegal mix of collations (utf8mb4_unicode_ci,COERCIBLE) and (utf8mb4_general_ci,COERCIBLE) for operation 'like' FATAL ERROR: Upgrade failed checking what's installed mysqlshow +--------------------+ | Databases | +--------------------+ | information_schema | | mysql | | performance_schema | | test | +--------------------+ and the charset/collation mysql SHOW CREATE DATABASE information_schema; SHOW CREATE DATABASE mysql; SHOW CREATE DATABASE performance_schema; SHOW CREATE DATABASE test; | information_schema | CREATE DATABASE `information_schema` /*!40100 DEFAULT CHARACTER SET utf8 */ | | mysql | CREATE DATABASE `mysql` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci */ | performance_schema | CREATE DATABASE `performance_schema` /*!40100 DEFAULT CHARACTER SET utf8 */ | | test | CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET latin1 */ | looks to be a mix ... and the source of the errors. What config etc. needs to be changed to avoid the upgrade errors, and get charsets/collations correctly set up at data initialization -- as spec'd in my.cnf?

3 4

[Maria-discuss] mariadb 10.3.15 doesn't work
by mingming1 yu 13 Jun '19

13 Jun '19

Hi Expert, I encounter below issue with mariadb 10.3.15, any suggestions? BTW, it works well with 10.3.13. # mysql -h 127.0.0.1 -u root -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 3 Server version: 10.3.15-MariaDB Source distribution Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | test | +--------------------+ 4 rows in set (0.105 sec) MariaDB [(none)]> use information_schema; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MariaDB [information_schema]> show databases; ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... ERROR 2002 (HY000): Can't connect to MySQL server on '127.0.0.1' (115) ERROR: Can't connect to the server Thanks,

6 9

[Maria-discuss] join_buffer_size > 2 MiB causes query to hang
by Felipe Gasper 16 May '19

16 May '19

Hello, The following query takes 6 minutes to complete … SELECT DISTINCT user FROM mysql.db WHERE BINARY db IN ( SELECT DISTINCT db FROM mysql.db WHERE BINARY user=? ) … when I have a join_buffer_size over 2,048 KiB. The effect is pretty remarkable: if I set the buffer size to 2,048 KiB, the query finishes in about 0.1 seconds, but with the buffer size at 2,049 KiB it takes several minutes. The long query time doesn’t happen in MySQL 5.7, but we see it in MariaDB 10.1 and 10.2. Is this a known issue? Thank you! -Felipe Gasper Mississauga, Ontario

1 0

[Maria-discuss] Maxscale: Can't connect to information_schema database
by Nicolas Bigler 13 May '19

13 May '19

Hey community I'm currently struggling with maxscale when trying to connect to the information_schema database. I'm able to connect to this special database when connecting to the database server directly: mysql -h <my_db_server> information_schema Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 101189 Server version: 10.2.23-MariaDB-1:10.2.23+maria~bionic-log mariadb.org binary distribution Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [information_schema]> However I can't connect to the database when going through maxscale: mysql -h 127.0.0.1 information_schema ERROR 1045 (28000): Access denied for user '<my_user>'@'127.0.0.1' (using password: YES) to database 'information_schema' What does work is to connect to the database first (via maxscale) without specifying a database and then change to the information_schema database: mysql -h 127.0.0.1 Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 25321 Server version: 10.2.23-MariaDB-1:10.2.23+maria~bionic-log mariadb.org binary distribution Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> use information_schema Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed I don't quite understand why it doesn't work directly. I have a PHP application (magento2) that reads stuff from this database. The following PHP script shows the same issue: <?php # Fill our vars and run on cli # $ php -f db-connect-test.php $dbname = 'information_schema'; $dbuser = '<my_db_user>'; $dbpass = '<my_super_secret_pass'; $dbhost = '127.0.0.1'; # pdo_testdb_connect.php - function for connecting to the "test" database $dbh = new PDO('mysql:host=' . $dbhost . ';dbname=' . $dbname, $dbuser, $dbpass); echo $dbh->exec ("SHOW TABLES FROM $dbname"); ?> $ php test.php PHP Fatal error: Uncaught PDOException: SQLSTATE[HY000] [1045] Access denied for user '<my_db_user>'@'127.0.0.1' (using password: YES) to database 'information_schema' in /tmp/test.php:12 Stack trace: #0 /tmp/test.php(12): PDO->__construct('mysql:host=127....', '<my_db_user>', '<my_super_secret_pass>...') #1 {main} thrown in /tmp/test.php on line 12 Is there a way to solve this issue? Any help would be appreciated. Thanks Nicolas

3 3

[Maria-discuss] New backup procedure plan
by Tom Worster 10 May '19

10 May '19

Hi, 3 MariaDB servers are running Galera on three bare-metal machines adjacent to each other in a data center rack. Two of them handle traffic from a web app while the third machine has other duties including backups. A recent upgrade in the web app completely changed its schema. Previously there were many databases (schemas), each with a modest volume of data, and soon all that data will be in one database. The current backup procedure mysqldumps each schema every hour on the third machine. Then a geographically distant host copies those files out and stores them in a rotating series. I'm thinking of changing this because I don't really like how the Galera rx queue on the third machine climbs for two minutes every hour. The idea I want to check with y'all is: Every hour on that third machine 1. Shutdown mysqld and wait for it to exit 2. Snapshot its datadir using BTRFS 3. Restart that mysqld 4. Start an LXC container that - mounts the snapshot read-only and - starts its own mysqld with innodb_read_only 5. Run mysqldump in the LXC container 6. Stop the container, which shuts down its mysqld 7. Then let the geographically distant host do its thing Pros - Keep using the existing system for remote copies and rotating series of mysqld files. - We can add a script on the third machine to maintain a series of the BTRFS snapshots. - Confidence boost from having both physical backups on the cluster and remote logical backups Cons? or other thoughts? Tom

2 1

[Maria-discuss] mariadb CVE
by mingming1 yu 05 May '19

05 May '19

Hi Expert, I have a question how to identify a mariadb CVE issue. For example, per description of http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2481, it only refers the mysql version which are affected, but not mention any info about mariadb. So I continue to find some clue at https://mariadb.com/kb/en/library/security-vulnerabilities-in-oracle-mysql-…, but there is no item about CVE-2019-2481. And then I continue to search some clues at "Full List of CVEs fixed in MariaDB" part of https://mariadb.com/kb/en/library/security/, and at this page there is a line as below: - CVE-2019-2481 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2481>: MariaDB 5.5.37 <https://mariadb.com/kb/en/mariadb-5537-release-notes/>, MariaDB 10.0.11 <https://mariadb.com/kb/en/mariadb-10011-release-notes/> But I still don't know whether it affects Mariadb 10.3.13 or not. Thanks,

2 1

[Maria-discuss] strange "increment" values on primary keys
by Janis Heller 01 May '19

01 May '19

Hey community, I’m running Server version: 10.3.13-MariaDB-1:10.3.13+maria~bionic-log mariadb.org binary distribution of mariaDB (galera cluster). For local development we are not using galera, inside our local dev team we’re using Server version: 5.7.26-0ubuntu0.18.04.1 (Ubuntu). After creating a table, I’ve started to run the database create commands, working fine, but when I run the database seeder, inserting some system config values to be used by the application itself later, I’ve got some strange behavior. See the table below: MariaDB [demo_database]> select * from system_configs WHERE 1=1; +----+------------------------------------+--------------------------------------------------------------------+ | id | key | value | +----+------------------------------------+--------------------------------------------------------------------+ | 4 | admin_address | XXXXXX | | 7 | XXXXXX | XXXXXX | | 10 | XXXXXX | XXXXXX | | 13 | XXXXXX | XXXXXX | | 16 | XXXXXX | XXXXXX | | 19 | XXXXXX | XXXXXX | | 22 | XXXXXX | XXXXXX | | 25 | XXXXXX | XXXXXX | | 28 | XXXXXX | XXXXXX | | 31 | XXXXXX | XXXXXX | | 34 | XXXXXX | XXXXXX | | 37 | XXXXXX | XXXXXX | | 40 | XXXXXX | XXXXXX | | 43 | XXXXXX | XXXXXX | | 46 | XXXXXX | XXXXXX | | 49 | XXXXXX | XXXXXX | | 52 | XXXXXX | XXXXXX | | 55 | XXXXXX | XXXXXX | | 58 | XXXXXX | XXXXXX | | 61 | XXXXXX | XXXXXX | | 64 | XXXXXX | 21600 | | 67 | XXXXXX | XXXXXX | | 70 | XXXXXX | https://some.domain.com | +----+------------------------------------+——————————————————————————————————+ Where XXXXXX stands for the key and XXXXXX for the value. The problem is the id itself. It’s somehow starting at 4 and is incremented by 3. As you may suspect now already, this will break our application, since some primary key ids are hard coded itself. Is there some way to „force“ maria DB to increment the IDs by „1“? I already this documentation entry: https://mariadb.com/kb/en/library/auto_increment/ <https://mariadb.com/kb/en/library/auto_increment/> But it doesn’t help, here’s what I tried: MariaDB [demo_database]> CREATE TABLE animals ( -> id MEDIUMINT NOT NULL AUTO_INCREMENT, -> name CHAR(30) NOT NULL, -> PRIMARY KEY (id) -> ); Query OK, 0 rows affected (0.014 sec) MariaDB [demo_database]> INSERT INTO animals (name) VALUES -> ('dog'),('cat'),('penguin'), -> ('fox'),('whale'),('ostrich'); Query OK, 6 rows affected (0.003 sec) Records: 6 Duplicates: 0 Warnings: 0 MariaDB [demo_database]> MariaDB [demo_database]> SELECT * FROM animals; +----+---------+ | id | name | +----+---------+ | 4 | dog | | 7 | cat | | 10 | penguin | | 13 | fox | | 16 | whale | | 19 | ostrich | +----+---------+ 6 rows in set (0.001 sec) MariaDB [demo_database]> ALTER TABLE animals AUTO_INCREMENT=20; Query OK, 0 rows affected (0.011 sec) Records: 0 Duplicates: 0 Warnings: 0 MariaDB [demo_database]> INSERT INTO animals (name) VALUES ('aardvark'); Query OK, 1 row affected (0.002 sec) MariaDB [demo_database]> INSERT INTO animals (name) VALUES ('aardvark'); Query OK, 1 row affected (0.003 sec) MariaDB [demo_database]> SELECT * FROM animals; +----+----------+ | id | name | +----+----------+ | 4 | dog | | 7 | cat | | 10 | penguin | | 13 | fox | | 16 | whale | | 19 | ostrich | | 25 | aardvark | | 28 | aardvark | +----+----------+ 8 rows in set (0.000 sec) MariaDB [demo_database]> exit Bye I’m unable to find a way to force mariaDB to use increment by 1, starting at 1, as our local mariaDB „development“ version does too. All the best from Germany; Janis

4 6