[MDEV-15859] MariaDB 10.2.13~14 Impossible to make SST with libmariadbclient18 (from MariaDB) Created: 2018-04-13  Updated: 2021-12-23  Resolved: 2021-12-23

Status: Closed
Project: MariaDB Server
Component/s: Galera SST
Affects Version/s: 10.2.13, 10.2.14
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Aurélien LEQUOY Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Environment:

Debian 9.4 install from MariaDB repository


 Description   

FOUND : the problem come from --defaults-file with : (look it's not loaded in particular order or combined with an other option).

First I tried to upgrade my galera cluster from 10.2.12 to 10.2.13, i stopped one node to upgrade and put back, but the node fail to IST and then fail to SST. (I pushed a bug about this : https://jira.mariadb.org/browse/MDEV-15453?filter=-2)

Then when we tried to deploy a new cluster :
At begining we asked ourself why the upgrade of password failed with SALT (https://docs.saltstack.com/en/latest/ref/states/all/salt.states.mysql_user.html). in fact I think this trouble and the sst is exactly the same the cannot connect to mysql (particular sign, you can see : ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
(or whatever you put in /root/.my.cnf)
It's mean that all stuff witch use salt are falling also. I don't know where it is in the code but i know it's linked with : "libmariadbclient18" and special options of client to connect to MySQL/MariaDB

Work :

ii  libmariadbclient18:amd64          10.1.26-0+deb9u1               amd64        MariaDB database client library

(i don't know why Debian installed this version for mariadb 10.2.13)

Not Work :
(with apt-get upgrade)

ii  libmariadbclient18                10.2.13+maria~stretch          amd64        Virtual package to satisfy external depends

Full listing :
Work :

 dpkg -l | grep -E "mysql|maria" 
ii  libdbd-mysql-perl                 4.041-2                        amd64        Perl5 database interface to the MariaDB/MySQL database
 
ii  libmariadbclient18:amd64          10.1.26-0+deb9u1               amd64        MariaDB database client library
 
ii  mariadb-backup-10.2               10.2.13+maria~stretch          amd64        Backup tool for MariaDB server
 
ii  mariadb-client-10.2               10.2.13+maria~stretch          amd64        MariaDB database client binaries
 
ii  mariadb-client-core-10.2          10.2.13+maria~stretch          amd64        MariaDB database core client binaries
 
ii  mariadb-common                    10.2.13+maria~stretch          all          MariaDB database common files (e.g. /etc/mysql/conf.d/mariadb.cnf)
 
ii  mariadb-server-10.2               10.2.13+maria~stretch          amd64        MariaDB database server binaries
 
ii  mariadb-server-core-10.2          10.2.13+maria~stretch          amd64        MariaDB database core server files
 
ii  mysql-common                      10.2.13+maria~stretch          all          MariaDB database common files (e.g. /etc/mysql/my.cnf)
 
ii  python-mysqldb                    1.3.7-1.1                      amd64        Python interface to MySQL

not work :

ii  libdbd-mysql-perl                 4.041-2                        amd64        Perl5 database interface to the MariaDB/MySQL database
 
ii  libmariadb3                       10.2.13+maria~stretch          amd64        MariaDB database client library
 
ii  libmariadbclient18                10.2.13+maria~stretch          amd64        Virtual package to satisfy external depends
 
ii  mariadb-backup-10.2               10.2.13+maria~stretch          amd64        Backup tool for MariaDB server
 
ii  mariadb-client-10.2               10.2.13+maria~stretch          amd64        MariaDB database client binaries
 
ii  mariadb-client-core-10.2          10.2.13+maria~stretch          amd64        MariaDB database core client binaries
 
ii  mariadb-common                    10.2.13+maria~stretch          all          MariaDB database common files (e.g. /etc/mysql/conf.d/mariadb.cnf)
 
ii  mariadb-server-10.2               10.2.13+maria~stretch          amd64        MariaDB database server binaries
 
ii  mariadb-server-core-10.2          10.2.13+maria~stretch          amd64        MariaDB database core server files
 
ii  mysql-common                      10.2.13+maria~stretch          all          MariaDB database common files (e.g. /etc/mysql/my.cnf)
 
ii  python-mysqldb                    1.3.7-1.1                      amd64        Python interface to MySQL



 Comments   
Comment by Aurélien LEQUOY [ 2018-04-13 ]

I can see you pushed MariaDB 10.2.14 with broken SST ..., as all time I thought the problem come from xtrabackup, but not in this case.

Why nobody answered yet to all work I made with SST on other bug from with MariaDB 10.2.13 + SST ?

https://jira.mariadb.org/browse/MDEV-15383?focusedCommentId=108624&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-108624

i tested this morning with 10.2.14 and the problem is still there.

Work around :

remove 

ii  libmariadbclient18                10.2.13+maria~stretch          amd64        Virtual package to satisfy external depends

add 

ii  libmariadbclient18:amd64          10.1.26-0+deb9u1               amd64        MariaDB database client library

Comment by Sergei Golubchik [ 2018-04-18 ]

Aurelien_LEQUOY could you please clarify the issue? multiple .cnf files are loaded in the incorrect order?

Comment by Aurélien LEQUOY [ 2018-04-30 ]

when we used with salt, it's look like --default-file= not load correctly. more loading SST with saltcrashed, but sworking manually.

and the only one difference it's the origin of the packet. there is one regression on the package provided in MariaDB 10.2 (libmariadbclient18)

Comment by Jan Lindström (Inactive) [ 2018-05-14 ]

Hi, can you explain step by step what you were trying to do? Secondly, what you mean by salt? Where you use it? Can you provide configuration from all nodes and error log from all nodes.

Comment by Aurélien LEQUOY [ 2018-08-16 ]

i will make a new test, next week

Generated at Thu Feb 08 08:24:34 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.