- discuss - lists.mariadb.org

[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

[Maria-discuss] Bill Owens: Get Andrew Yang on 60 Minutes
by carlosla1987＠gmail.com 30 Apr '19

30 Apr '19

Hola. Acabo de firmar la petición "Bill Owens: Get Andrew Yang on 60 Minutes" y pensé que te podría interesar. Estamos intentando conseguir 7.500 firmas y necesitamos todo el apoyo que podamos conseguir. Puedes leer más y firmar la petición aquí: http://chng.it/fXhkx89bFX ¡Gracias! Carlos

1 0

[Maria-discuss] Migration question - advice sought
by Richard Reina 28 Apr '19

28 Apr '19

I have about five MySQL slaves backing up a MySQL master. The master is rather old and I am planning on migrating to MariaDB. I was hoping I could I create a MariaDB slave that backs up the newest MySQL slave (making it a relay) and then make the Maria slave a master and add Maria slaves until MySQL is phased out. Does this sound like a good plan or would it be better to just create a new Maria Master with dumps and add Maria slaves to it? Thanks

2 1

[Maria-discuss] Understanding access to data through a unique index (r_rows=NULL in ANALYZE)
by Barrendeitor 26 Apr '19

26 Apr '19

Hello, I'm using MariaDB 13.3.14 I have a very simple test table with an email column and I am using |ANALYZE|to see the behavior of the indexes. If I understand correctly the output of |ANALYZE|, '|rows'|indicates the estimate of records accessed in the table, and |'r_rows'|the actual number of accesses. (Am I correct?) If yes, the issue is that, for a query as simple as: | SELECT*FROMuserWHEREemail ='user(a)domain.com'| ||| -- user(a)domain.com exists in email column and it is unique| || If I create a normal index in the |'email'|field, |r_rows=|1. However, if I create a unique index, |r_rows|=|NULL|. If I understand correctly, a NULL value on 'r_rows' means that no access to data has been performed ( https://mariadb.com/kb/en/library/analyze-statement/ ). So my question is, if I have a valid result, how can it be that the table is not accessed? How is the data retrieved when a unique index is used? Here is my output (I remember that the email in the query exists): MariaDB [test2]> create index email on usuario(email); Query OK, 95236 rows affected (0.451 sec) Records: 95236 Duplicates: 0 Warnings: 0 MariaDB [test2]> analyze select * from usuario where email = 'nec.urna.et(a)volutpatornare.com'; +------+-------------+---------+------+---------------+-------+---------+-------+------+--------+----------+------------+-----------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | r_rows | filtered | r_filtered | Extra | +------+-------------+---------+------+---------------+-------+---------+-------+------+--------+----------+------------+-----------------------+ | 1 | SIMPLE | usuario | ref | email | email | 302 | const | 1 | 1.00 | 100.00 | 100.00 | Using index condition | +------+-------------+---------+------+---------------+-------+---------+-------+------+--------+----------+------------+-----------------------+ 1 row in set (0.001 sec) MariaDB [test2]> drop index email on usuario; Query OK, 95236 rows affected (0.237 sec) Records: 95236 Duplicates: 0 Warnings: 0 MariaDB [test2]> create unique index email on usuario(email); Query OK, 95236 rows affected (0.484 sec) Records: 95236 Duplicates: 0 Warnings: 0 MariaDB [test2]> analyze select * from usuario where email = 'nec.urna.et(a)volutpatornare.com'; +------+-------------+---------+-------+---------------+-------+---------+-------+------+--------+----------+------------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | r_rows | filtered | r_filtered | Extra | +------+-------------+---------+-------+---------------+-------+---------+-------+------+--------+----------+------------+-------+ | 1 | SIMPLE | usuario | const | email | email | 302 | const | 1 | NULL | 100.00 | NULL | | +------+-------------+---------+-------+---------------+-------+---------+-------+------+--------+----------+------------+-------+ 1 row in set (0.001 sec) Regards. ||

1 0