Bug#929707: [debian-mysql] Bug#929707: mariadb-client-10.1: import of "mysqldump --all-databases" fails with "ERROR 1062 (23000): Duplicate entry"
On Sun, Oct 04, 2020 at 12:40:48PM +0300, Otto Kekäläinen wrote: > la 3. lokak. 2020 klo 18.17 Matija Nalis (mnalis-debian...@voyager.hr) > > Yes, I can write a shell test scripts which looks like > > https://salsa.debian.org/mariadb-team/mariadb-10.5/-/blob/master/debian/tests/smoke > > Yes, that seems like a sensible approach. You don't need much > resources as you can use the resources of Salsa (Gitlab-CI) to run it > for you. See https://wiki.debian.org/Teams/MySQL/patches "Using > Salsa-CI". Thanks for the pointers, Otto - they look interesting! Unfortunately, I'm now failing even at this simple task of cleanly reproducing the bug manually. I've tried but I am unable to recreate the problems when I install mariadb from scratch in Stretch. (our original machines had mysql/mariadb databases upgraded from previous Debian versions, so something there might have done something to databases to trigger that behavior). As original machines which were exhibiting problem were in the meantime updated to Buster (where the problem seems to be gone now), and myself not being able to reproduce it in clean install of Scratch mariadb-10.1 (even after importing few databases on which it was failing on original machines) and myself lacking time to try some deeper forensics, I propose this bug be closed unless someone else chimes in that they can reproduce it. -- Opinions above are GNU-copylefted.
Bug#929707: [debian-mysql] Bug#929707: mariadb-client-10.1: import of "mysqldump --all-databases" fails with "ERROR 1062 (23000): Duplicate entry"
la 3. lokak. 2020 klo 18.17 Matija Nalis (mnalis-debian...@voyager.hr) kirjoitti: > > Yes, I can write a shell test scripts which looks like > https://salsa.debian.org/mariadb-team/mariadb-10.5/-/blob/master/debian/tests/smoke > > and verify that (when run from shell) it fails with non-zero > errorlevel in Stretch mariadb, and passes with 0 on Buster mariadb. > > If that is enough? (I don't really have resources ATM to setup build > environment and do full-build checks etc) Yes, that seems like a sensible approach. You don't need much resources as you can use the resources of Salsa (Gitlab-CI) to run it for you. See https://wiki.debian.org/Teams/MySQL/patches "Using Salsa-CI".
Bug#929707: [debian-mysql] Bug#929707: mariadb-client-10.1: import of "mysqldump --all-databases" fails with "ERROR 1062 (23000): Duplicate entry"
Yes, I can write a shell test scripts which looks like https://salsa.debian.org/mariadb-team/mariadb-10.5/-/blob/master/debian/tests/smoke and verify that (when run from shell) it fails with non-zero errorlevel in Stretch mariadb, and passes with 0 on Buster mariadb. If that is enough? (I don't really have resources ATM to setup build environment and do full-build checks etc) On Tue, Sep 29, 2020 at 11:44:12PM +0300, Otto Kekäläinen wrote: > Thanks! > > Would you like to test with mariadb-10.5 in unstable as well? > > Or perhaps contribute by writing a small autopkgtest extension (the > debian/tests files in the packaging repository at > https://salsa.debian.org/mariadb-team/mariadb-10.5) that runs this > dump and thus ensure forever that this feature will not regress? -- Opinions above are GNU-copylefted.
Bug#929707: [debian-mysql] Bug#929707: mariadb-client-10.1: import of "mysqldump --all-databases" fails with "ERROR 1062 (23000): Duplicate entry"
Thanks! Would you like to test with mariadb-10.5 in unstable as well? Or perhaps contribute by writing a small autopkgtest extension (the debian/tests files in the packaging repository at https://salsa.debian.org/mariadb-team/mariadb-10.5) that runs this dump and thus ensure forever that this feature will not regress?
Bug#929707: [debian-mysql] Bug#929707: mariadb-client-10.1: import of "mysqldump --all-databases" fails with "ERROR 1062 (23000): Duplicate entry"
I've retested now quickly on different machine, and it *seems* to be working OK in Buster. # mysqldump -uroot --max_allowed_packet=2147483648 --hex-blob --lock-all-tables --master-data --flush-privileges --databases video1 mysql > backup.sql # mysql < backup.sql # lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 10 (buster) Release:10 Codename: buster # dpkg -l | grep mariadb ii libmariadb3:amd641:10.3.23-0+deb10u1 amd64MariaDB database client library ii mariadb-client 1:10.3.23-0+deb10u1 all MariaDB database client (metapackage depending on the latest version) ii mariadb-client-10.3 1:10.3.23-0+deb10u1 amd64MariaDB database client binaries ii mariadb-client-core-10.3 1:10.3.23-0+deb10u1 amd64MariaDB database core client binaries ii mariadb-common 1:10.3.23-0+deb10u1 all MariaDB common metapackage ii mariadb-server 1:10.3.23-0+deb10u1 all MariaDB database server (metapackage depending on the latest version) ii mariadb-server-10.3 1:10.3.23-0+deb10u1 amd64MariaDB database server binaries ii mariadb-server-core-10.3 1:10.3.23-0+deb10u1 amd64MariaDB database core server files
Bug#929707: [debian-mysql] Bug#929707: mariadb-client-10.1: import of "mysqldump --all-databases" fails with "ERROR 1062 (23000): Duplicate entry"
Hello! Have you tested if this still happens on recent MariaDB versions?
Bug#929707: mariadb-client-10.1: import of "mysqldump --all-databases" fails with "ERROR 1062 (23000): Duplicate entry"
Package: mariadb-client-10.1 Version: 10.1.38-0+deb9u1 Severity: normal Dear Maintainer, Doing "mysqldump --all-databases" on one mariadb 10.1 instance, and trying to import it on another mariadb 10.1 instance fails with: I would expect it to suceed without errors (like it did all the time in mysql in Jessie) I traced it down and it happens if dump contains one db with tables with indexes, and mysql db. machine1# mysqldump -uroot --max_allowed_packet=2147483648 --hex-blob --lock-all-tables --master-data --flush-privileges --databases video1 mysql > backup.sql machine2# mysql < backup.sql ERROR 1062 (23000) at line 796: Duplicate entry 'video1-test2-PRIMARY-n_diff_pfx01' for key 'PRIMARY' Digging deeper it seems that bug happens when mysql tryies to restore mysql.innodb_index_stats table I've found two workarounds: 1) modify order of databases, so mysql table is backed up (and restored) first, and all other later; eg "mysqldump ... --databases mysql video1" 2) before starting mysql for import, do "SET global innodb_stats_persistent=0" (and restore it afterwards) Perhaps one of those (or some other) workaround should be implemented automatically (at least when using "mysqldump --flush-privileges" and/or "--all-databases" which implies backup/import of mysql DB)? I would assume backup up and restoring whole mariadb server is one of relatively common operations which should not involve such debugging. -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/24 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages mariadb-client-10.1 depends on: ii debianutils 4.8.1.1 ii libaio1 0.3.110-3 ii libc6 2.24-11+deb9u4 ii libconfig-inifiles-perl 2.94-1 ii libjemalloc1 3.6.0-9.1 ii libstdc++66.3.0-18+deb9u1 ii libsystemd0 232-25+deb9u11 ii mariadb-client-core-10.1 10.1.38-0+deb9u1 ii perl 5.24.1-3+deb9u5 ii zlib1g1:1.2.8.dfsg-5 Versions of packages mariadb-client-10.1 recommends: ii libdbd-mysql-perl 4.041-2 ii libdbi-perl 1.636-1+b1 ii libterm-readkey-perl 2.37-1 mariadb-client-10.1 suggests no packages. -- no debconf information