- discuss - lists.mariadb.org

[Maria-discuss] dpkg: mariadb-client-10.x: dependency problems, but removing anyway as you requested
by William Edwards 25 May '22

25 May '22

Hi, Using the official MariaDB repos, since MariaDB 10.4, mariadb-client-10.x is removed, then installed on 'apt upgrade': ``` Unpacking libmariadb3:amd64 (1:10.7.4+maria~buster) over (1:10.7.3+maria~buster) ... dpkg: mariadb-client-10.7: dependency problems, but removing anyway as you requested: mariadb-server-10.7 depends on mariadb-client-10.7 (>= 1:10.7.3+maria~buster). mariadb-client depends on mariadb-client-10.7 (>= 1:10.7.4+maria~buster). (Reading database ... 87804 files and directories currently installed.) Removing mariadb-client-10.7 (1:10.7.3+maria~buster) ... Setting up mysql-common (1:10.7.4+maria~buster) ... Setting up mariadb-common (1:10.7.4+maria~buster) ... (Reading database ... 87703 files and directories currently installed.) Preparing to unpack .../00-mariadb-server-10.7_1%3a10.7.4+maria~buster_amd64.deb ... /var/lib/mysql: found previous version 10.7 Unpacking mariadb-server-10.7 (1:10.7.4+maria~buster) over (1:10.7.3+maria~buster) ... Preparing to unpack .../01-mariadb-server-core-10.7_1%3a10.7.4+maria~buster_amd64.deb ... Unpacking mariadb-server-core-10.7 (1:10.7.4+maria~buster) over (1:10.7.3+maria~buster) ... Preparing to unpack .../02-mariadb-client-core-10.7_1%3a10.7.4+maria~buster_amd64.deb ... Unpacking mariadb-client-core-10.7 (1:10.7.4+maria~buster) over (1:10.7.3+maria~buster) ... Selecting previously unselected package mariadb-client-10.7. Preparing to unpack .../03-mariadb-client-10.7_1%3a10.7.4+maria~buster_amd64.deb ... Unpacking mariadb-client-10.7 (1:10.7.4+maria~buster) ... ``` This does not seem to be a problem, but I'd like to understand what changed between 10.3 and 10.4 that causes this. Policy output and full 'apt upgrade' transaction log: ``` root@http-msh01:~# apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: filebeat libavcodec58 libavfilter7 libavformat58 libavutil56 libldap-2.4-2 libldap-common libmariadb-dev libmariadb-dev-compat libmariadb3 libpostproc55 libpq5 libssl-dev libssl1.1 libswresample3 libswscale5 libxml2 mariadb-client mariadb-client-10.7 mariadb-client-core-10.7 mariadb-common mariadb-server mariadb-server-10.7 mariadb-server-core-10.7 mysql-common nodejs openjdk-11-jre openjdk-11-jre-headless openssl php8.1 php8.1-bcmath php8.1-cli php8.1-common php8.1-curl php8.1-dev php8.1-fpm php8.1-gd php8.1-imap php8.1-intl php8.1-mbstring php8.1-mysql php8.1-opcache php8.1-readline php8.1-soap php8.1-sqlite3 php8.1-xml php8.1-zip sensu-go-agent 55 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 142 MB of archives. After this operation, 10.3 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://security.debian.org/debian-security buster/updates/main amd64 libssl-dev amd64 1.1.1n-0+deb10u2 [1,807 kB] Get:9 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 mysql-common all 1:10.7.4+maria~buster [2,880 B] Get:10 http://security.debian.org/debian-security buster/updates/main amd64 libssl1.1 amd64 1.1.1n-0+deb10u2 [1,551 kB] Get:11 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 mariadb-common all 1:10.7.4+maria~buster [4,052 B] Get:12 http://security.debian.org/debian-security buster/updates/main amd64 libldap-common all 2.4.47+dfsg-3+deb10u7 [90.1 kB] Get:13 http://security.debian.org/debian-security buster/updates/main amd64 libldap-2.4-2 amd64 2.4.47+dfsg-3+deb10u7 [224 kB] Get:14 https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 filebeat amd64 7.17.4 [37.8 MB] Get:15 http://security.debian.org/debian-security buster/updates/main amd64 libavfilter7 amd64 7:4.1.9-0+deb10u1 [1,053 kB] Get:16 https://packages.sury.org/php buster/main amd64 libxml2 amd64 2.9.14+dfsg-0+0~20220524.12+debian10~1.gbpc5dc45 [701 kB] Get:17 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 mariadb-server all 1:10.7.4+maria~buster [2,832 B] Get:18 http://security.debian.org/debian-security buster/updates/main amd64 libswscale5 amd64 7:4.1.9-0+deb10u1 [209 kB] Get:19 http://security.debian.org/debian-security buster/updates/main amd64 libavformat58 amd64 7:4.1.9-0+deb10u1 [1,019 kB] Get:20 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 mariadb-client all 1:10.7.4+maria~buster [2,704 B] Get:21 http://security.debian.org/debian-security buster/updates/main amd64 libavcodec58 amd64 7:4.1.9-0+deb10u1 [4,810 kB] Get:22 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 libmariadb-dev amd64 1:10.7.4+maria~buster [158 kB] Get:23 https://packages.sury.org/php buster/main amd64 php8.1-bcmath amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [15.4 kB] Get:24 https://packages.sury.org/php buster/main amd64 php8.1-zip amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [24.2 kB] Get:25 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 libmariadb-dev-compat amd64 1:10.7.4+maria~buster [3,084 B] Get:26 https://packages.sury.org/php buster/main amd64 php8.1-xml amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [107 kB] Get:27 https://packages.sury.org/php buster/main amd64 php8.1-sqlite3 amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [29.3 kB] Get:28 https://packages.sury.org/php buster/main amd64 php8.1-soap amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [120 kB] Get:29 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 libmariadb3 amd64 1:10.7.4+maria~buster [148 kB] Get:30 https://packages.sury.org/php buster/main amd64 php8.1-readline amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [12.6 kB] Get:31 https://packages.sury.org/php buster/main amd64 php8.1-opcache amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [332 kB] Get:32 https://packages.sury.org/php buster/main amd64 php8.1-mysql amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [116 kB] Get:33 https://packages.sury.org/php buster/main amd64 php8.1-mbstring amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [396 kB] Get:34 https://packages.sury.org/php buster/main amd64 php8.1-intl amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [127 kB] Get:35 https://packages.sury.org/php buster/main amd64 php8.1-imap amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [32.6 kB] Get:36 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 mariadb-client-core-10.7 amd64 1:10.7.4+maria~buster [832 kB] Get:37 https://packages.sury.org/php buster/main amd64 php8.1-gd amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [28.5 kB] Get:38 https://packages.sury.org/php buster/main amd64 php8.1-dev amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [488 kB] Get:39 https://packages.sury.org/php buster/main amd64 php8.1-curl amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [34.4 kB] Get:40 https://packages.sury.org/php buster/main amd64 php8.1-fpm amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [1,672 kB] Get:41 http://security.debian.org/debian-security buster/updates/main amd64 libswresample3 amd64 7:4.1.9-0+deb10u1 [112 kB] Get:42 http://security.debian.org/debian-security buster/updates/main amd64 libpostproc55 amd64 7:4.1.9-0+deb10u1 [108 kB] Get:43 http://security.debian.org/debian-security buster/updates/main amd64 libavutil56 amd64 7:4.1.9-0+deb10u1 [244 kB] Get:44 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 mariadb-server-10.7 amd64 1:10.7.4+maria~buster [3,461 kB] Get:45 https://packages.sury.org/php buster/main amd64 php8.1-cli amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [1,662 kB] Get:46 http://security.debian.org/debian-security buster/updates/main amd64 libpq5 amd64 11.16-0+deb10u1 [172 kB] Get:47 https://packages.sury.org/php buster/main amd64 php8.1-common amd64 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [660 kB] Get:48 http://security.debian.org/debian-security buster/updates/main amd64 openjdk-11-jre amd64 11.0.15+10-1~deb10u1 [174 kB] Get:49 https://packages.sury.org/php buster/main amd64 php8.1 all 8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1 [24.7 kB] Get:50 http://security.debian.org/debian-security buster/updates/main amd64 openjdk-11-jre-headless amd64 11.0.15+10-1~deb10u1 [37.2 MB] Get:51 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 mariadb-client-10.7 amd64 1:10.7.4+maria~buster [2,411 kB] Get:52 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 mariadb-server-core-10.7 amd64 1:10.7.4+maria~buster [7,153 kB] Get:53 https://packagecloud.io/sensu/stable/debian buster/main amd64 sensu-go-agent amd64 6.7.2-6283 [6,975 kB] Get:54 http://security.debian.org/debian-security buster/updates/main amd64 openssl amd64 1.1.1n-0+deb10u2 [855 kB] Get:55 https://deb.nodesource.com/node_16.x buster/main amd64 nodejs amd64 16.15.0-deb-1nodesource1 [26.4 MB] Fetched 142 MB in 6s (24.2 MB/s) Reading changelogs... Done Extracting templates from packages: 100% Preconfiguring packages ... (Reading database ... 87804 files and directories currently installed.) Preparing to unpack .../0-mysql-common_1%3a10.7.4+maria~buster_all.deb ... Unpacking mysql-common (1:10.7.4+maria~buster) over (1:10.7.3+maria~buster) ... Preparing to unpack .../1-mariadb-common_1%3a10.7.4+maria~buster_all.deb ... Unpacking mariadb-common (1:10.7.4+maria~buster) over (1:10.7.3+maria~buster) ... Preparing to unpack .../2-mariadb-server_1%3a10.7.4+maria~buster_all.deb ... Unpacking mariadb-server (1:10.7.4+maria~buster) over (1:10.7.3+maria~buster) ... Preparing to unpack .../3-mariadb-client_1%3a10.7.4+maria~buster_all.deb ... Unpacking mariadb-client (1:10.7.4+maria~buster) over (1:10.7.3+maria~buster) ... Preparing to unpack .../4-libmariadb-dev_1%3a10.7.4+maria~buster_amd64.deb ... Unpacking libmariadb-dev (1:10.7.4+maria~buster) over (1:10.7.3+maria~buster) ... Preparing to unpack .../5-libmariadb-dev-compat_1%3a10.7.4+maria~buster_amd64.deb ... Unpacking libmariadb-dev-compat:amd64 (1:10.7.4+maria~buster) over (1:10.7.3+maria~buster) ... Preparing to unpack .../6-libssl-dev_1.1.1n-0+deb10u2_amd64.deb ... Unpacking libssl-dev:amd64 (1.1.1n-0+deb10u2) over (1.1.1n-0+deb10u1) ... Preparing to unpack .../7-libssl1.1_1.1.1n-0+deb10u2_amd64.deb ... Unpacking libssl1.1:amd64 (1.1.1n-0+deb10u2) over (1.1.1n-0+deb10u1) ... Preparing to unpack .../8-libmariadb3_1%3a10.7.4+maria~buster_amd64.deb ... Unpacking libmariadb3:amd64 (1:10.7.4+maria~buster) over (1:10.7.3+maria~buster) ... dpkg: mariadb-client-10.7: dependency problems, but removing anyway as you requested: mariadb-server-10.7 depends on mariadb-client-10.7 (>= 1:10.7.3+maria~buster). mariadb-client depends on mariadb-client-10.7 (>= 1:10.7.4+maria~buster). (Reading database ... 87804 files and directories currently installed.) Removing mariadb-client-10.7 (1:10.7.3+maria~buster) ... Setting up mysql-common (1:10.7.4+maria~buster) ... Setting up mariadb-common (1:10.7.4+maria~buster) ... (Reading database ... 87703 files and directories currently installed.) Preparing to unpack .../00-mariadb-server-10.7_1%3a10.7.4+maria~buster_amd64.deb ... /var/lib/mysql: found previous version 10.7 Unpacking mariadb-server-10.7 (1:10.7.4+maria~buster) over (1:10.7.3+maria~buster) ... Preparing to unpack .../01-mariadb-server-core-10.7_1%3a10.7.4+maria~buster_amd64.deb ... Unpacking mariadb-server-core-10.7 (1:10.7.4+maria~buster) over (1:10.7.3+maria~buster) ... Preparing to unpack .../02-mariadb-client-core-10.7_1%3a10.7.4+maria~buster_amd64.deb ... Unpacking mariadb-client-core-10.7 (1:10.7.4+maria~buster) over (1:10.7.3+maria~buster) ... Selecting previously unselected package mariadb-client-10.7. Preparing to unpack .../03-mariadb-client-10.7_1%3a10.7.4+maria~buster_amd64.deb ... Unpacking mariadb-client-10.7 (1:10.7.4+maria~buster) ... Preparing to unpack .../04-libldap-common_2.4.47+dfsg-3+deb10u7_all.deb ... Unpacking libldap-common (2.4.47+dfsg-3+deb10u7) over (2.4.47+dfsg-3+deb10u6) ... Preparing to unpack .../05-libldap-2.4-2_2.4.47+dfsg-3+deb10u7_amd64.deb ... Unpacking libldap-2.4-2:amd64 (2.4.47+dfsg-3+deb10u7) over (2.4.47+dfsg-3+deb10u6) ... Preparing to unpack .../06-libavfilter7_7%3a4.1.9-0+deb10u1_amd64.deb ... Unpacking libavfilter7:amd64 (7:4.1.9-0+deb10u1) over (7:4.1.8-0+deb10u1) ... Preparing to unpack .../07-libswscale5_7%3a4.1.9-0+deb10u1_amd64.deb ... Unpacking libswscale5:amd64 (7:4.1.9-0+deb10u1) over (7:4.1.8-0+deb10u1) ... Preparing to unpack .../08-libavformat58_7%3a4.1.9-0+deb10u1_amd64.deb ... Unpacking libavformat58:amd64 (7:4.1.9-0+deb10u1) over (7:4.1.8-0+deb10u1) ... Preparing to unpack .../09-libavcodec58_7%3a4.1.9-0+deb10u1_amd64.deb ... Unpacking libavcodec58:amd64 (7:4.1.9-0+deb10u1) over (7:4.1.8-0+deb10u1) ... Preparing to unpack .../10-libswresample3_7%3a4.1.9-0+deb10u1_amd64.deb ... Unpacking libswresample3:amd64 (7:4.1.9-0+deb10u1) over (7:4.1.8-0+deb10u1) ... Preparing to unpack .../11-libpostproc55_7%3a4.1.9-0+deb10u1_amd64.deb ... Unpacking libpostproc55:amd64 (7:4.1.9-0+deb10u1) over (7:4.1.8-0+deb10u1) ... Preparing to unpack .../12-libavutil56_7%3a4.1.9-0+deb10u1_amd64.deb ... Unpacking libavutil56:amd64 (7:4.1.9-0+deb10u1) over (7:4.1.8-0+deb10u1) ... Preparing to unpack .../13-libxml2_2.9.14+dfsg-0+0~20220524.12+debian10~1.gbpc5dc45_amd64.deb ... Unpacking libxml2:amd64 (2.9.14+dfsg-0+0~20220524.12+debian10~1.gbpc5dc45) over (2.9.13+dfsg-0+0~20220410.11+debian10~1.gbp692312) ... Preparing to unpack .../14-libpq5_11.16-0+deb10u1_amd64.deb ... Unpacking libpq5:amd64 (11.16-0+deb10u1) over (11.14-0+deb10u1) ... Preparing to unpack .../15-nodejs_16.15.0-deb-1nodesource1_amd64.deb ... Unpacking nodejs (16.15.0-deb-1nodesource1) over (16.14.2-deb-1nodesource1) ... Preparing to unpack .../16-openjdk-11-jre_11.0.15+10-1~deb10u1_amd64.deb ... Unpacking openjdk-11-jre:amd64 (11.0.15+10-1~deb10u1) over (11.0.14+9-1~deb10u1) ... Preparing to unpack .../17-openjdk-11-jre-headless_11.0.15+10-1~deb10u1_amd64.deb ... Unpacking openjdk-11-jre-headless:amd64 (11.0.15+10-1~deb10u1) over (11.0.14+9-1~deb10u1) ... Preparing to unpack .../18-openssl_1.1.1n-0+deb10u2_amd64.deb ... Unpacking openssl (1.1.1n-0+deb10u2) over (1.1.1n-0+deb10u1) ... Preparing to unpack .../19-php8.1-bcmath_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-bcmath (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../20-php8.1-zip_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-zip (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../21-php8.1-xml_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-xml (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../22-php8.1-sqlite3_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-sqlite3 (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../23-php8.1-soap_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-soap (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../24-php8.1-readline_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-readline (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../25-php8.1-opcache_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-opcache (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../26-php8.1-mysql_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-mysql (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../27-php8.1-mbstring_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-mbstring (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../28-php8.1-intl_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-intl (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../29-php8.1-imap_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-imap (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../30-php8.1-gd_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-gd (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../31-php8.1-dev_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-dev (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../32-php8.1-curl_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-curl (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../33-php8.1-fpm_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-fpm (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../34-php8.1-cli_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-cli (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../35-php8.1-common_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_amd64.deb ... Unpacking php8.1-common (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../36-php8.1_8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1_all.deb ... Unpacking php8.1 (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) over (8.1.5-1+0~20220422.16+debian10~1.gbpfcaf04) ... Preparing to unpack .../44-sensu-go-agent_6.7.2-6283_amd64.deb ... Unpacking sensu-go-agent (6.7.2-6283) over (6.7.0-6196) ... Preparing to unpack .../45-filebeat_7.17.4_amd64.deb ... Unpacking filebeat (7.17.4) over (7.17.3) ... Setting up libssl1.1:amd64 (1.1.1n-0+deb10u2) ... Setting up openjdk-11-jre-headless:amd64 (11.0.15+10-1~deb10u1) ... Setting up openjdk-11-jre:amd64 (11.0.15+10-1~deb10u1) ... Setting up nodejs (16.15.0-deb-1nodesource1) ... Setting up libldap-common (2.4.47+dfsg-3+deb10u7) ... Setting up libavutil56:amd64 (7:4.1.9-0+deb10u1) ... Setting up libssl-dev:amd64 (1.1.1n-0+deb10u2) ... Setting up libpostproc55:amd64 (7:4.1.9-0+deb10u1) ... Setting up libmariadb3:amd64 (1:10.7.4+maria~buster) ... Setting up libmariadb-dev (1:10.7.4+maria~buster) ... Setting up sensu-go-agent (6.7.2-6283) ... Setting up libswscale5:amd64 (7:4.1.9-0+deb10u1) ... Setting up mariadb-server-core-10.7 (1:10.7.4+maria~buster) ... Setting up filebeat (7.17.4) ... Installing new version of config file /etc/filebeat/filebeat.reference.yml ... Configuration file '/etc/filebeat/filebeat.yml' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** filebeat.yml (Y/I/N/O/D/Z) [default=N] ? Installing new version of config file /etc/filebeat/modules.d/azure.yml.disabled ... Setting up openssl (1.1.1n-0+deb10u2) ... Setting up libxml2:amd64 (2.9.14+dfsg-0+0~20220524.12+debian10~1.gbpc5dc45) ... Setting up libmariadb-dev-compat:amd64 (1:10.7.4+maria~buster) ... Installing all pip dependencies Requirement already satisfied: pika==1.2.0 in /usr/local/lib/python3.7/dist-packages (1.2.0) Setting up php8.1-common (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up php8.1-imap (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up php8.1-gd (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up libldap-2.4-2:amd64 (2.4.47+dfsg-3+deb10u7) ... Setting up libswresample3:amd64 (7:4.1.9-0+deb10u1) ... Setting up php8.1-curl (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up php8.1-sqlite3 (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up php8.1-xml (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up php8.1-soap (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up mariadb-client-core-10.7 (1:10.7.4+maria~buster) ... Setting up php8.1-mysql (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up php8.1-zip (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up libavcodec58:amd64 (7:4.1.9-0+deb10u1) ... Setting up php8.1-readline (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up mariadb-client-10.7 (1:10.7.4+maria~buster) ... Setting up php8.1-opcache (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up php8.1-intl (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up php8.1-bcmath (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up mariadb-client (1:10.7.4+maria~buster) ... Setting up php8.1-mbstring (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up libavformat58:amd64 (7:4.1.9-0+deb10u1) ... Setting up libpq5:amd64 (11.16-0+deb10u1) ... Setting up mariadb-server-10.7 (1:10.7.4+maria~buster) ... Installing new version of config file /etc/mysql/debian-start ... mariadb-extra.socket is a disabled or a static unit not running, not starting it. mariadb-extra.socket is a disabled or a static unit, not starting it. Setting up php8.1-cli (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up php8.1-dev (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up libavfilter7:amd64 (7:4.1.9-0+deb10u1) ... Setting up mariadb-server (1:10.7.4+maria~buster) ... Setting up php8.1-fpm (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Setting up php8.1 (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Processing triggers for hicolor-icon-theme (0.17-2) ... Processing triggers for libc-bin (2.28-10+deb10u1) ... Processing triggers for systemd (241-7~deb10u8) ... Processing triggers for man-db (2.8.5-2) ... Processing triggers for mime-support (3.62) ... Processing triggers for php8.1-cli (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... Processing triggers for php8.1-fpm (8.1.6-1+0~20220517.17+debian10~1.gbp6b3bd1) ... root@http-msh02:~# apt-cache policy libmariadb-dev libmariadb-dev-compat libmariadb3 mariadb-client mariadb-client-10.7 mariadb-client-core-10.7 mariadb-common mariadb-server mariadb-server-10.7 mariadb-server-core-10.7 mysql-common libmariadb-dev: Installed: 1:10.7.3+maria~buster Candidate: 1:10.7.4+maria~buster Version table: 1:10.7.4+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages *** 1:10.7.3+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 100 /var/lib/dpkg/status 1:10.7.1+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1:10.3.34-0+deb10u1 500 500 http://debmirror.tuxis.nl/debian buster/main amd64 Packages 1:10.3.25-0+deb10u1 500 500 http://security.debian.org/debian-security buster/updates/main amd64 Packages libmariadb-dev-compat: Installed: 1:10.7.3+maria~buster Candidate: 1:10.7.4+maria~buster Version table: 1:10.7.4+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages *** 1:10.7.3+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 100 /var/lib/dpkg/status 1:10.7.1+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1:10.3.34-0+deb10u1 500 500 http://debmirror.tuxis.nl/debian buster/main amd64 Packages 1:10.3.25-0+deb10u1 500 500 http://security.debian.org/debian-security buster/updates/main amd64 Packages libmariadb3: Installed: 1:10.7.3+maria~buster Candidate: 1:10.7.4+maria~buster Version table: 1:10.7.4+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages *** 1:10.7.3+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 100 /var/lib/dpkg/status 1:10.7.1+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1:10.3.34-0+deb10u1 500 500 http://debmirror.tuxis.nl/debian buster/main amd64 Packages 1:10.3.25-0+deb10u1 500 500 http://security.debian.org/debian-security buster/updates/main amd64 Packages mariadb-client: Installed: 1:10.7.3+maria~buster Candidate: 1:10.7.4+maria~buster Version table: 1:10.7.4+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main ppc64el Packages *** 1:10.7.3+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main ppc64el Packages 100 /var/lib/dpkg/status 1:10.7.1+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main ppc64el Packages 1:10.3.34-0+deb10u1 500 500 http://debmirror.tuxis.nl/debian buster/main amd64 Packages 1:10.3.25-0+deb10u1 500 500 http://security.debian.org/debian-security buster/updates/main amd64 Packages mariadb-client-10.7: Installed: 1:10.7.3+maria~buster Candidate: 1:10.7.4+maria~buster Version table: 1:10.7.4+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages *** 1:10.7.3+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 100 /var/lib/dpkg/status 1:10.7.1+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages mariadb-client-core-10.7: Installed: 1:10.7.3+maria~buster Candidate: 1:10.7.4+maria~buster Version table: 1:10.7.4+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages *** 1:10.7.3+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 100 /var/lib/dpkg/status 1:10.7.1+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages mariadb-common: Installed: 1:10.7.3+maria~buster Candidate: 1:10.7.4+maria~buster Version table: 1:10.7.4+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main ppc64el Packages *** 1:10.7.3+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main ppc64el Packages 100 /var/lib/dpkg/status 1:10.7.1+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main ppc64el Packages 1:10.3.34-0+deb10u1 500 500 http://debmirror.tuxis.nl/debian buster/main amd64 Packages 1:10.3.25-0+deb10u1 500 500 http://security.debian.org/debian-security buster/updates/main amd64 Packages mariadb-server: Installed: 1:10.7.3+maria~buster Candidate: 1:10.7.4+maria~buster Version table: 1:10.7.4+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main ppc64el Packages *** 1:10.7.3+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main ppc64el Packages 100 /var/lib/dpkg/status 1:10.7.1+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main ppc64el Packages 1:10.3.34-0+deb10u1 500 500 http://debmirror.tuxis.nl/debian buster/main amd64 Packages 1:10.3.25-0+deb10u1 500 500 http://security.debian.org/debian-security buster/updates/main amd64 Packages mariadb-server-10.7: Installed: 1:10.7.3+maria~buster Candidate: 1:10.7.4+maria~buster Version table: 1:10.7.4+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages *** 1:10.7.3+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 100 /var/lib/dpkg/status 1:10.7.1+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages mariadb-server-core-10.7: Installed: 1:10.7.3+maria~buster Candidate: 1:10.7.4+maria~buster Version table: 1:10.7.4+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages *** 1:10.7.3+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 100 /var/lib/dpkg/status 1:10.7.1+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages mysql-common: Installed: 1:10.7.3+maria~buster Candidate: 1:10.7.4+maria~buster Version table: 1:10.7.4+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main ppc64el Packages *** 1:10.7.3+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main ppc64el Packages 100 /var/lib/dpkg/status 1:10.7.1+maria~buster 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main ppc64el Packages 5.8+1.0.5 500 500 http://debmirror.tuxis.nl/debian buster/main amd64 Packages root@http-msh02:~# apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 500 https://packages.sury.org/php buster/main amd64 Packages release o=deb.sury.org,a=buster,n=buster,c=main,b=amd64 origin packages.sury.org 500 https://packagecloud.io/sensu/stable/debian buster/main amd64 Packages release v=1,o=packagecloud.io/sensu/stable,a=buster,n=buster,l=stable,c=main,b=amd64 origin packagecloud.io 500 http://nginx.org/packages/mainline/debian buster/nginx amd64 Packages release v=10.0,o=nginx,a=stable,n=buster,l=nginx,c=nginx,b=amd64 origin nginx.org 100 http://debmirror.tuxis.nl/debian buster-backports/main amd64 Packages release o=Debian Backports,a=buster-backports,n=buster-backports,l=Debian Backports,c=main,b=amd64 origin debmirror.tuxis.nl 500 https://deb.nodesource.com/node_16.x buster/main amd64 Packages release o=Node Source,n=buster,l=Node Source,c=main,b=amd64 origin deb.nodesource.com 500 https://artifacts.elastic.co/packages/7.x/apt stable/main amd64 Packages release o=elastic,a=stable,n=stable,l=. stable,c=main,b=amd64 origin artifacts.elastic.co 500 https://apt.tuxis.nl/tuxis monitoring/main amd64 Packages release o=tuxis monitoring,a=monitoring,n=monitoring,l=tuxis monitoring,c=main,b=amd64 origin apt.tuxis.nl 500 https://apt.tuxis.nl/tuxis tuxis-cron/main amd64 Packages release o=tuxis tuxis-cron,a=tuxis-cron,n=tuxis-cron,l=tuxis tuxis-cron,c=main,b=amd64 origin apt.tuxis.nl 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main ppc64el Packages release o=MariaDB,n=buster,l=MariaDB,c=main,b=ppc64el origin ams2.mirrors.digitalocean.com 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main arm64 Packages release o=MariaDB,n=buster,l=MariaDB,c=main,b=arm64 origin ams2.mirrors.digitalocean.com 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.7/debian buster/main amd64 Packages release o=MariaDB,n=buster,l=MariaDB,c=main,b=amd64 origin ams2.mirrors.digitalocean.com 500 http://debmirror.tuxis.nl/debian buster-updates/main amd64 Packages release o=Debian,a=oldstable-updates,n=buster-updates,l=Debian,c=main,b=amd64 origin debmirror.tuxis.nl 500 http://security.debian.org/debian-security buster/updates/main amd64 Packages release v=10,o=Debian,a=oldstable,n=buster,l=Debian-Security,c=main,b=amd64 origin security.debian.org 500 http://debmirror.tuxis.nl/debian buster/main amd64 Packages release v=10.12,o=Debian,a=oldstable,n=buster,l=Debian,c=main,b=amd64 origin debmirror.tuxis.nl Pinned packages: ``` -- With kind regards, William Edwards

1 0

[Maria-discuss] In memory DB, how to in MariaDB?
by Eliezer Croitoru 23 May '22

23 May '22

I have seen the next blog post which had a video at 2014: https://blogs.oracle.com/pcoe/post/the-future-of-the-database-begins The demo video was removed from YouTube for some reason but I had a copy of it at: https://cloud1.ngtech.co.il/static/oracle/Oracle%20Database%20In-Memory%20Po wering%20the%20Real-Time%20Enterprise%20.mp4 I am not a MariaDB or MySQL or DB in general expert and was wondering if there is something these days in MariaDB that can be used in comparison to what Oracle DB demo shows? I have used LevelDB as a backend in a customized DB and it worked very very fast and it is great. With batches it works even faster but in general it works faster then standard MariaDB setups I have implemented. So what are the options? I have millions of values and I would like to be able to insert and select as fast as possible on a single DB Server. Currently I am using a Caching tier with a specific TTL to lower the stress off the DB, but, is I possible to make the DB Faster like maybe with some writeback (leaving aside fault tolerance for speed). Thanks, Eliezer ---- Eliezer Croitoru NgTech, Tech Support Mobile: +972-5-28704261 Email: <mailto:ngtech1ltd@gmail.com> ngtech1ltd(a)gmail.com

3 4

[Maria-discuss] Debian revision should not contain codename
by William Edwards 19 May '22

19 May '22

Hi, I'm attempting to upgrade a machine with MariaDB 10.6 from Buster to Bullseye using the official MariaDB repo. I was surprised to see that apt wanted to downgrade a few packages: ``` $ apt upgrade --without-new-pkgs The following packages will be DOWNGRADED: libmariadb-dev libmariadb-dev-compat libmariadb3 mysql-common ``` I was confused at first, as the priority of the candidate is higher, and the epoch is unchanged, and the upstream version is unchanged: ``` $ apt policy mysql-common mysql-common: Installed: 1:10.6.7+maria~buster Candidate: 1:10.6.7+maria~bullseye Version table: *** 1:10.6.7+maria~buster 100 100 /var/lib/dpkg/status 1:10.6.7+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main ppc64el Packages 1:10.6.5+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main ppc64el Packages 1:10.6.4+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main ppc64el Packages 5.8+1.0.7 500 500 http://debmirror.tuxis.nl/debian bullseye/main amd64 Packages $ apt policy libmariadb3 libmariadb3: Installed: 1:10.6.7+maria~buster Candidate: 1:10.6.7+maria~bullseye Version table: *** 1:10.6.7+maria~buster 100 100 /var/lib/dpkg/status 1:10.6.7+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.6.5+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.6.4+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.5.15-0+deb11u1 500 500 http://debmirror.tuxis.nl/debian bullseye/main amd64 Packages $ apt policy libmariadb-dev-compat libmariadb-dev-compat: Installed: 1:10.6.7+maria~buster Candidate: 1:10.6.7+maria~bullseye Version table: *** 1:10.6.7+maria~buster 100 100 /var/lib/dpkg/status 1:10.6.7+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.6.5+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.6.4+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.5.15-0+deb11u1 500 500 http://debmirror.tuxis.nl/debian bullseye/main amd64 Packages $ apt policy libmariadb-dev libmariadb-dev: Installed: 1:10.6.7+maria~buster Candidate: 1:10.6.7+maria~bullseye Version table: *** 1:10.6.7+maria~buster 100 100 /var/lib/dpkg/status 1:10.6.7+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.6.5+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.6.4+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.5.15-0+deb11u1 500 500 http://debmirror.tuxis.nl/debian bullseye/main amd64 Packages ``` A simulation also reported that apt would 'downgrade' to the same versions: ``` $ apt upgrade --without-new-pkgs -s Inst libmariadb-dev [1:10.6.7+maria~buster] (1:10.6.7+maria~bullseye MariaDB:ams2.mirrors.digitalocean.com [amd64]) [] Inst libmariadb-dev-compat [1:10.6.7+maria~buster] (1:10.6.7+maria~bullseye MariaDB:ams2.mirrors.digitalocean.com [amd64]) [] Inst libmariadb3 [1:10.6.7+maria~buster] (1:10.6.7+maria~bullseye MariaDB:ams2.mirrors.digitalocean.com [amd64]) Inst mysql-common [1:10.6.7+maria~buster] (1:10.6.7+maria~bullseye MariaDB:ams2.mirrors.digitalocean.com [all]) ``` Some folks on IRC pointed me to the fact that the Debian revision has been updated from `maria~buster` to `maria~bullseye`. The following documentation at https://www.debian.org/doc/debian-policy/ch-controlfields.html#special-vers… says: > The lexical comparison is a comparison of ASCII values modified so that > all the letters sort earlier than all the non-letters and so that a > tilde sorts before anything, even the end of a part. 'bul' comes before 'bus', so the package for Bullseye is perceived as older, despite it being the same effective upstream version... According to https://www.debian.org/doc/debian-policy/ch-controlfields.html#special-vers…, the Debian revision should NOT contain the Debian release codename. This problem will re-appear with Bookworm. Could the package maintainer(s) attend to this? -- With kind regards, William Edwards

2 2

Re: [Maria-discuss] MariaDB latest source tarballs missing
by Sergei Golubchik 19 May '22

19 May '22

Hi, Shreenidhi, On May 19, Shreenidhi Shedi wrote: > > I am from VMware Photon OS engineering team. > > We are trying to fix few CVEs that are being reported in 10.2.x & > 10.3.x versions of MariaDB. > > There is release note for v10.2.44 but I cannot find the source > tarball in downloads page or in github tags of maria db server. You cannot find it, because it wasn't released yet. > https://mariadb.com/kb/en/mariadb-10244-release-notes/ This page says, on the very top, in a red box: Note: This page describes features in the source repository for MariaDB 10.2. There are currently no official packages or binaries available for download which contain the features. If you want to try out any of the new features described here you will need to get and compile the code yourself. > Can you guys please help me out here? Where can I get the latest > released source tarballs? https://mariadb.org/download/ > Also, when can we expect a fix for this? If at all this is not > released, when can we expect next release of MariaDB server versions? Any day now. Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

[Maria-discuss] Galera: jump through major versions at once
by William Edwards 19 May '22

19 May '22

Hi, Does Galera support rolling upgrades between multiple major versions? I will be upgrading my Galera cluster from MariaDB 10.3.34 to 10.6.x. It'd save a lot of time to jump straight from 10.3 to 10.6 instead of upgrading 10.3 -> 10.4 -> 10.5 -> 10.6. The documentation at https://mariadb.com/kb/en/upgrading-from-mariadb-103-to-mariadb-104-with-ga… implies that the MariaDB version is irrelevant, and only the Galera version matters. > Next, make sure that the Galera version numbers are compatible. > > If you are upgrading from the most recent MariaDB 10.3 release to > MariaDB 10.4, then the versions will > be compatible. MariaDB 10.3 uses Galera 3 (i.e. Galera wsrep provider > versions 25.3.x), and MariaDB > 10.4 uses Galera 4 (i.e. Galera wsrep provider versions 26.4.x). This > means that upgrading to MariaDB > 10.4 also upgrades the system to Galera 4. However, Galera 3 and Galera > 4 should be compatible for the > purposes of a rolling upgrade, as long as you are using Galera 26.4.2 > or later. -- With kind regards, William Edwards

2 3

[Maria-discuss] FLUSH TABLES ... FOR EXPORT SLOW
by mariadb＠Biblestuph.com 18 May '22

18 May '22

I've recently updated from 10.3.14 => 10.6.7, and am running into an issue where FLUSH TABLES ... FOR EXPORT is sometimes very slow on large tables. One particular table that it seems to happen on often is over 20G. It doesn't hang, per se; it will complete eventually, but can take an hour or more. 2022-05-17 0:14:06 105636 [Note] InnoDB: Sync to disk of `MyDB`.`t1` started. 2022-05-17 0:14:06 105636 [Note] InnoDB: Writing table metadata to './MyDB/t1.cfg' 2022-05-17 0:14:06 105636 [Note] InnoDB: Table `MyDB`.`t1` flushed to disk 2022-05-17 0:14:06 105636 [Note] InnoDB: Sync to disk of `MyDB`.`t2` started. 2022-05-17 1:49:53 105636 [Note] InnoDB: Writing table metadata to './MyDB/t2.cfg' 2022-05-17 1:49:53 105636 [Note] InnoDB: Table `MyDB`.`t2` flushed to disk in the above the obfuscated table name t2 took about 1.5 hours to complete. In the previous version (10.3.14), these were always nearly instantaneous, even for the largest tables. At the time I'm executing the FLUSH TABLES the slave is stopped on the DB and there are no other users logged in to the DB (other than myself). I know from the docs that FLUSH TABLES has seen changes since my previous version, but I'm not clear as to what the process is waiting for (or how to avoid it). Shutting down the server first (I have innodb_fast_shutdown = 0) seems to prevent it; and the shutdown generally only takes 5-10 minutes or so. But I'd rather not shutdown if I don't have to (and I'm not 100% convinced that I won't someday see the issue in that scenario, as well). I've also tried this sequence thinking it might help: ---> STOP SLAVE Wed May 18 10:30:13 2022 ---> SLAVE STOPPED Wed May 18 10:30:13 2022 ---> FLUSH LOCAL TABLES WITH READ LOCK Wed May 18 10:30:14 2022 ---> UNLOCK TABLES Wed May 18 10:30:15 2022 ---> SET GLOBAL innodb_purge_rseg_truncate_frequency = 1 Wed May 18 10:30:15 2022 ---> SET GLOBAL innodb_max_purge_lag_wait = 0 Wed May 18 10:30:15 2022 ---> FLUSH TABLES ... FOR EXPORT Wed May 18 10:30:15 2022 but the FLUSH TABLES FOR EXPORT still waits on that large table. Is there a way to make this happen quicker without requiring the DB to be shutdown first? Or am I missing something else in the process? Thanks, Dan

1 0

[Maria-discuss] A federation bug was identified.
by 최혁규 11 May '22

11 May '22

A federation bug was identified. I have confirmed that the select where query does not work in the multi index field of some federated tables. A field in the table is used as a multi index. My server version : 10.8.2-MariaDB However, there is no problem with the server used in the previous version. The previous version is Server version: 10.5.10-MariaDB. The tested method was compared by creating a federated table on two servers with different versions. 1. 10.5.10 - MariaDB -> All queries are normally searched. 2. 10.8.2 - MariaDB -> Symptoms were confirmed in some multi index types. --> The table field datatype is (int, datetime) This is the table I created and the select query. Table Created CREATE TABLE `fd_partner_detail` ( `partner_id` varchar(100) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '파트너ID', `business_name` varchar(45) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '사업자상호명', `business_no` varchar(45) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '사업자번호', `online_marketing_business_no` varchar(45) NOT NULL DEFAULT '' COMMENT '통신판매업 신고번호', `representative` varchar(45) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '대표자명', `business_category` char(50) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '종목', `business_status` char(50) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '업종형태', `contact` varchar(45) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '연락처', `courier_code` varchar(45) NOT NULL DEFAULT '0' COMMENT '택배사코드', `postal_code` varchar(45) DEFAULT NULL COMMENT '우편번호', `address` varchar(45) DEFAULT NULL COMMENT '주소(도로명)', `address_detail` varchar(45) DEFAULT NULL COMMENT '상세주소', `officer` varchar(45) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '대표담당자명', `officer_contact` varchar(45) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '대표담당자연락처', `officer_email` varchar(45) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '대표담당자이메일', `order_officer` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '발주담당자명', `order_officer_contact` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '발주담당자연락처', `order_officer_email` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '발주담당자이메일', `calculate_order_officer` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '정산담당자명', `calculate_officer_contact` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '정산담당자연락처', `calculate_officer_email` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '정산담당자이메일', `cs_order_officer` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT 'CS담당자명', `cs_officer_contact` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT 'CS담당자연락처', `cs_officer_email` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT 'CS담당자이메일', `product_name` varchar(100) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '대표상품명', `product_url` varchar(255) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '대표상품URL', `product_type` int(1) NOT NULL DEFAULT 0 COMMENT '대표상품제조구분 (1: 제조, 2:벤더)', `add_product_name_1` varchar(100) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '선택상품명1', `add_product_url_1` varchar(255) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '선택상품URL1', `add_product_type_1` int(1) DEFAULT 0 COMMENT '선택상품제조구분1', `add_product_name_2` varchar(100) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '선택상품명2', `add_product_url_2` varchar(255) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '선택상품URL2', `add_product_type_2` int(1) DEFAULT 0 COMMENT '선택상품제조구분2', `calculate_bank_code` varchar(45) NOT NULL DEFAULT '' COMMENT '정산은행코드', `calculate_bank_no` varchar(45) NOT NULL DEFAULT '' COMMENT '정산계좌번호', `calculate_bank_name` varchar(45) NOT NULL DEFAULT '' COMMENT '정산예금주명', `file_bankbook` varchar(255) DEFAULT '' COMMENT '통장사본', `original_bankbook` varchar(255) DEFAULT '' COMMENT '통장사본원본명', `file_business_license` varchar(255) DEFAULT '' COMMENT '사업자등록증', `original_business_license` varchar(255) DEFAULT '' COMMENT '사업자등록증원본명', `file_document` varchar(255) DEFAULT '' COMMENT '기타서류', `original_document` varchar(255) DEFAULT '' COMMENT '기타서류원본명', `is_terms_service` int(1) NOT NULL DEFAULT 0 COMMENT '쇼핑몰이용약관동의여부', `is_privacy_consent` int(1) NOT NULL DEFAULT 0 COMMENT '개인정보처리방침동의여부', `join_status` int(1) NOT NULL DEFAULT 1 COMMENT '가입승인상태(1: 입점대기, 2: 입점반려, 3:입점승인, 4:입점불가)', `return_cause` text CHARACTER SET utf8mb3 DEFAULT NULL COMMENT '가입반려사유', `calculate_type` int(1) NOT NULL DEFAULT 1 COMMENT '정산주기유형(1:15일, 2:30일)', `dormant_change_date` datetime DEFAULT NULL COMMENT '휴면전환일', `dormant_cancel_date` datetime DEFAULT NULL COMMENT '휴면해제일', `join_date` datetime DEFAULT NULL COMMENT '가입승인일', `is_withdraw` int(1) NOT NULL DEFAULT 0 COMMENT '탈퇴회원여부', `introduce` text DEFAULT NULL COMMENT '회사소개', `memo` varchar(255) DEFAULT '' COMMENT '관리자 메모', `corporation_code` varchar(45) CHARACTER SET utf8mb3 NOT NULL COMMENT '회사코드', `marketplace_code` varchar(45) CHARACTER SET utf8mb3 NOT NULL COMMENT '쇼핑몰코드', `is_abolished` int(1) NOT NULL DEFAULT 0 COMMENT '삭제여부', `is_popup` int(1) DEFAULT 0 COMMENT '입점 승인', `application_code` varchar(45) CHARACTER SET utf8mb3 DEFAULT NULL COMMENT '어플리케이션코드', `created_by` varchar(45) CHARACTER SET utf8mb3 DEFAULT NULL COMMENT '생성자', `created_date` datetime DEFAULT NULL COMMENT '생성일', `modified_by` varchar(45) CHARACTER SET utf8mb3 DEFAULT NULL COMMENT '수정자', `modified_date` datetime DEFAULT NULL COMMENT '수정일', `abolished_by` varchar(45) CHARACTER SET utf8mb3 DEFAULT NULL COMMENT '삭제자', `abolished_date` datetime DEFAULT NULL COMMENT '삭제일', PRIMARY KEY (`partner_id`), KEY `IDX_R_1` (`is_abolished`), KEY `IDX_R_2` (`created_date`), KEY `IDX_U_1` (`courier_code`), KEY `IDX_U_2` (`postal_code`), KEY `IDX_U_3` (`calculate_bank_code`) ) ENGINE=FEDERATED DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC COMMENT='파트너상세정보' CONNECTION='fdc_partner_bh/fo_partner_detail' Table Select Query SELECT business_no, representative, business_name, contact, partner_id ,is_abolished FROM fd_partner_detail WHERE created_date = '1'; Select Query Result business_no representative business_name contact partner_id is_abolished ----------- -------------- ------------- ------- ---------- -------------- I want to know if what I checked is a bug.

2 1

[Maria-discuss] mariabackup is slow (log scanned up to)
by John Pace 29 Apr '22

29 Apr '22

Hi, I am using mariabackup to backup a database. On day 1 a full backup with mariabackup --backup --user=Backup --password=my-password --target-dir=path-to-full and on day 2-7 a incremental backup with mariabackup --backup --user=Backup --password=my-password --target-dir=path-to-inc --incremental-basedir=path-to-full Then follows again a new backup for day 1 and so on. The database can be used while the backup is running. A web application for Apache Tomcat uses the database. This worked very well for a couple of weeks, the backup was finished within 20 minutes. But recently I noticed that the incremental backup took much longer than before. I checked the output of mariabackup and it was spammed several hours with lines like these [00] 2022-04-20 00:48:00 >> log scanned up to (1747989580536) [00] 2022-04-20 00:48:01 >> log scanned up to (1747989580536) [00] 2022-04-20 00:48:02 >> log scanned up to (1747989580536) 2022-04-20 0:48:03 0 [Note] InnoDB: Read redo log up to LSN=1747989580800 [00] 2022-04-20 00:48:03 >> log scanned up to (1747989580536) [00] 2022-04-20 00:48:04 >> log scanned up to (1747989580536) [00] 2022-04-20 00:48:05 >> log scanned up to (1747989580536) [00] 2022-04-20 00:48:06 >> log scanned up to (1747989580536) Yesterday the incremental backup took 7 hours so I wonder if there is something wrong. MariaDB shows no error in the log: 2022-03-15 8:35:48 0 [Note] InnoDB: Using Linux native AIO 2022-03-15 8:35:48 0 [Note] InnoDB: Uses event mutexes 2022-03-15 8:35:48 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2022-03-15 8:35:48 0 [Note] InnoDB: Number of pools: 1 2022-03-15 8:35:48 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions 2022-03-15 8:35:48 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728 2022-03-15 8:35:48 0 [Note] InnoDB: Completed initialization of buffer pool 2022-03-15 8:35:48 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2022-03-15 8:35:49 0 [Note] InnoDB: 128 rollback segments are active. 2022-03-15 8:35:49 0 [Note] InnoDB: Creating shared tablespace for temporary tables 2022-03-15 8:35:49 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2022-03-15 8:35:49 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. 2022-03-15 8:35:49 0 [Note] InnoDB: 10.5.8 started; log sequence number 1741176510061; transaction id 38228169 2022-03-15 8:35:49 0 [Note] Plugin 'FEEDBACK' is disabled. 2022-03-15 8:35:49 0 [Note] InnoDB: Loading buffer pool(s) from /path-to-database/ib_buffer_pool 2022-03-15 8:35:49 0 [Note] Server socket created on IP: '::'. 2022-03-15 8:35:50 0 [Note] InnoDB: Buffer pool(s) load completed at 220315 8:35:50 2022-03-15 8:35:50 0 [Note] /path-to-mariadb/bin/mariadbd: ready for connections. Version: '10.5.8-MariaDB' socket: '/tmp/mysql.sock' port: 3306 MariaDB Server PS: Sorry for my test-post. ------------------------------------------------------------------------------------------------- FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT

1 0

[Maria-discuss] test
by John Pace 29 Apr '22

29 Apr '22

------------------------------------------------------------------------------------------------- FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT

1 0

[Maria-discuss] Understanding SQL queries
by João Paulo Almeida 14 Apr '22

14 Apr '22

Dear MariaDB Users, We are currently carrying out some research on the understanding and usability of different relational schemas (as part of a Ph.D. student's thesis work). We would like to invite you to contribute to this research by answering a small number of questions on SQL query interpretation. Participation is via an anonymous form and there are only 7 questions, so it should not take more than 10 minutes of your time: https://forms.gle/EA2jYGf4CTmLfEiaA We thank you in advance and would appreciate it if you could also share this research with colleagues who also have a background on SQL. thank you, João Paulo A. Almeida Federal University of Espírito Santo

2 1

[Maria-discuss] mysql 5.5 client vs mariadb 10 server
by Oliver 22 Mar '22

22 Mar '22

Hi, I'm sorry for the question if it is clear that it isn't possible. I'm trying connect from a mysql 5.5.56 client against a mariadb 10 server and I'm having the next error: ERROR 2003 (HY000): Can't connect to MySQL server on 'server' (10061) Subnet source is allowed in mariadb server and grant is given for 'root'@'source_server', it is allowed both IP and hostname. So not sure if it is config problem or compatibility problem. Someone knows please? Thanks beforehand. P.D.: I can connect using dbeaver from my computer client using mysql binaries (but not sure what mysql client version uses dbeaver). Cheers...

4 5

[Maria-discuss] History Length: Purge-able vs. Not Purge-able metrics
by mariadb＠Biblestuph.com 10 Mar '22

10 Mar '22

Greetings, I know I can get the current undo log history length via: > show status like '%history%'; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | Innodb_history_list_length | 854 | +----------------------------+-------+ but my understanding is that at any given point in time that number represents both the records that can be purged because they are no longer needed by any current transactions (and the purge threads for whatever reason haven't gotten to them yet), as well as those that cannot be purged yet because there are current transactions running that may still need them. So the question is, is there any way to know the difference between those two? I.E., how many are waiting to be purged and how many cannot yet be purged? And a related question. Will the undo log size (the physical size of the file) grow even when there are many entries in the history that can be purged first? Or are those unneeded records purged first and that space reused before the undo log is made larger? Or perhaps I'm mis-understanding the process? TIA, Dan

1 0

[Maria-discuss] Unable to find specific format for mariaDB 10.6.*
by ragul rangarajan 25 Feb '22

25 Feb '22

Hi Team, I try to get MariaDB 10.6.* *bintar-linux-x86_64 tar* from http://archive.mariadb.org/ But I couldn't find any other formats except *bintar-linux-systemd-x86_64 *as in the older version. Can someone please share where to get* bintar-linux-x86-64 *for 10.6.* MariaDB version as like below for 10.5.* https://archive.mariadb.org/mariadb-10.5.15/bintar-linux-x86_64/mariadb-10.… Thanks and regards, Ragul

3 4

[Maria-discuss] demo: running MariaDB with rootless Podman and socket activation
by Erik Sjölund 17 Feb '22

17 Feb '22

Hi, Support for socket activation was added to MariaDB in release 10.6 (released April 2021). Podman also supports socket activation so I thought it would be interesting to combine both of them into a systemd user service. I wrote a small demo: https://github.com/eriksjolund/mariadb-podman-socket-activation (tweet: https://twitter.com/eriksjolundcomp/status/1491162016429768704) and got it to work. Do you have any suggestions on how to improve this? Thanks, Erik Sjölund

2 3

[Maria-discuss] Fwd: [MariaDB Announce] MariaDB 10.8.1 RC and MariaDB 10.7.2, 10.6.6, 10.5.14, 10.4.23, 10.3.33 and 10.2.42 now available
by Reindl Harald 10 Feb '22

10 Feb '22

https://downloads.mariadb.org/mariadb/10.3.33/ points to a form with 10.6 preselected because a redirect to https://mariadb.org/download/?t=mariadb&p=mariadb&r=10.6.5&os=Linux&cpu=x86… and in that useless form 10.3.32 is the newest you can select when trying to download sources is there a reason why such nonsense on download pages is developed other than "some people need to be busy"? when you change to 10.3 and have selcted "source" before the form goes back to Linux with systemd as selection head - table - match -------- Weitergeleitete Nachricht -------- Betreff: [MariaDB Announce] MariaDB 10.8.1 RC and MariaDB 10.7.2, 10.6.6, 10.5.14, 10.4.23, 10.3.33 and 10.2.42 now available MariaDB 10.3.33 - Release Notes: https://mariadb.com/kb/en/mdb-10333-rn/ - Changelog: https://mariadb.com/kb/en/mdb-10333-cl/ - Downloads: https://downloads.mariadb.org/mariadb/10.3.33/

2 1

[Maria-discuss] Weird behavior in Fedora 34 server
by Miguel Lavalle 05 Jan '22

05 Jan '22

Hi, I am installing MariaDB in Fedora 34 server with the following sequence of commands: sudo dnf upgrade -y sudo dnf install -y mariadb-server mariadb-devel sudo dnf -y install git vim With this sequence of commands, I get the following installed: $ mysql --version mysql Ver 15.1 Distrib 10.5.13-MariaDB, for Linux (x86_64) using EditLine wrapper and I can successfully perform the initial setup of the root password: sudo mysqladmin -u root password password and continue with the rest of my installation. However, if I change the sequence of commands to: sudo dnf upgrade -y sudo dnf -y install git vim sudo dnf install -y mariadb-server mariadb-devel What I get installed instead is: $ mysql --version mysql Ver 8.0.27 for Linux on x86_64 (Source distribution) and the 'sudo mysqladmin -u root password password' command fails with: mysqladmin: unable to change password; error: 'You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '() IDENTIFIED BY 'secretdatabase'' at line 1' Could anyone shed some light on this? Thanks!

3 8

[Maria-discuss] Incremental backup with mariabackup and run-mariabackup
by Dave Wreski 02 Jan '22

02 Jan '22

Hi, I'm using mariadb-10.5.13 on fedora34 with run-mariabackup from https://github.com/omegazeng/run-mariabackup. Has anyone used this backup script or have any recommendations for ones that help to automate the process of using mariabackup for backups? This script appears to create an infinite amount of incremental backups once the original full backup is created. I believe this makes it necessary to restore each of the incrementals on top of the base. If the backups are stored off-site, this creates magnitudes more data that's needed to restore, and increases the time to restore it. It also only appears possible to backup the entire system, not just individual databases. Do you have any recommendations for other scripts that ease the process of making and restoring backups? Thanks, Dave

1 0

[Maria-discuss] sys schema backup
by William Edwards 04 Dec '21

04 Dec '21

Hi, The 'sys' schema is documented to be "A collection of views, functions and procedures to help MySQL administrators get insight in to MySQL Database usage." Is there anything in this schema that should be backed up, or can I skip it when creating backups? -- With kind regards, William Edwards

3 2

[Maria-discuss] [Warning] WSREP: certification interval for trx source [...] exceeds the limit of 16384
by Giovanni Agozzino 01 Dec '21

01 Dec '21

Hi people, I'm relatively new to Mariadb+Galera and I'm trying to understand how to manage when a node goes down the best way. I don’t know if this is the right place to ask. If not, I’d appreciate suggestions for where to ask. I am using 1:10.6.5+maria~hirsute galera-4 26.4.9-hirsute I would understand what is the meaning of the warning: [Warning] WSREP: certification interval for trx source [...] exceeds the limit of 16384 and what are the ways to avoid it. I'll explain when I encounter it: I shut down one of my three mariadb nodes during peak hours and I wait to restart it until a SST is triggered. The SST is succesfully done (both the donor and the joiner go without errors). But when applying the IST post SST to keep up with the latest transactions, I see these warning in both donor (before switching from donor/desynced to synced state) and joiner (after completing SST). What is the implication of this warning? I suppose is not the certification failing or I would have errors, but I don't know if is serious business or not. And there is a parameter to tune in the way to avoid this warning? Thank you very much. Best regards, Giovanni

1 0

[Maria-discuss] Question about MariaDB Xpand
by huan zhang 30 Nov '21

30 Nov '21

Hi all, I have some questions about MariaDB Xpand. Not sure whether here is the right place to ask questions or not. If not, appreciate for the suggestions of where to ask. I firstly put my questions here, let's assume the performance topology: 1. Every node of Xpand can read and write as described in white paper, but my question is does MariaDB Xpand support Multi-Master to finish the Global Transactions? There is only one global transaction manager(GTM) or there exists multiple GTM workers at the same time? 2. What's the usage of Paxos in Xpand? If there is only one GTM at a time, it's easy to understand: Paxos is used to determine which is the leader (GTM). 3. MPP feature of Xpand is misleading and the document is too simple to understand the internals of MPP implementation. Queries are splitted into sub query fragments and it seems that each fragment can only do every single work. So can it support Hash Join? e.g. a join fragment builds a hash table for a small table firstly and then probes the big table from the remote node? Thanks in advance. Hubert Zhang

1 0

[Maria-discuss] Issue with MariaDB backup using LVM snapshot
by Riccardo Brunetti > 29 Nov '21

29 Nov '21

Hello. We are using a backup procedure based on a combination of LVM snapshots and rsync. In particular, the procedure is the following: > ... > mysql -h -u -p -e "FLUSH TABLES WITH READ LOCK; \! lvcreate -L -s -n " > > mount > > ... > > rsync ....... At the end, we change the working directory, unmount and lvremove . Sometimes, randomly, the umount command works but the lvremove fails and we are left with the lvm snapshot unmounted but we are unable to remove it. We tried to force a removal without success with the following error: > Logical volume contains a filesystem in use We didn't find any process using that device using lsof and we can't find any handler keeping the device busy. Even a mariadb restart doesn't fix it and the only solution is to reboot the server. The only thing we noticed is a message upon the snapshot creation: > File descriptor 4 (socket:[201844800]) leaked on lvcreate invocation. Parent PID 1564033: mysql We know that this is the mysql unix socket. Have you ever had such an issue? Thanks a lot. Kind regards. Riccardo

1 0

[Maria-discuss] MyISAM: single table GROUP BY plan changes based on LIMIT. BUG?
by Vassilis Virvilis 26 Nov '21

26 Nov '21

2 4

[Maria-discuss] mariadb 10.4.13-lp152.1.1 to 10.5.12-3.9.1 upgrade failure
by Marc Chamberlin 25 Nov '21

25 Nov '21

Hello - I have ran into a problem that maybe someone else has hit and knows a solution for it. I recently upgraded my OpenSuSE 15.2 x64 version to OpenSuSE 15.3 x64 and installed all additional updates and patches that were suggested for 15.3. Most of the upgrade succeeded, all except Mariadb. Google has not been helpful either. My understanding of Mariadb is that after a new install of a new version it is suppose to automagically update and fix the databases from the older version, when the server is restarted, but I think this is failing. I found the upgrade log file for Mariadb and it appears to be reporting some kind of corruption has occurred. This is preventing the mariadb (mysql) server from even starting, so it is not possible to use queries to find and repair the database. - > bigbang:/var/tmp/mysql-protected.lBP2YQ # more log_upgrade_run.err > 2021-10-31 12:11:36 0 [Note] InnoDB: !!! innodb_force_recovery is set > to 1 !!! > 2021-10-31 12:11:36 0 [Note] InnoDB: Uses event mutexes > 2021-10-31 12:11:36 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 > 2021-10-31 12:11:36 0 [Note] InnoDB: Number of pools: 1 > 2021-10-31 12:11:36 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions > 2021-10-31 12:11:36 0 [Note] mysqld: O_TMPFILE is not supported on > /tmp (disabling future attempts) > 2021-10-31 12:11:36 0 [Note] InnoDB: Using Linux native AIO > 2021-10-31 12:11:36 0 [Note] InnoDB: Initializing buffer pool, total > size = 134217728, chunk size = 134217728 > 2021-10-31 12:11:36 0 [Note] InnoDB: Completed initialization of > buffer pool > 2021-10-31 12:11:36 0 [ERROR] InnoDB: corrupted TRX_NO 5f737461748dea16 > 2021-10-31 12:11:36 0 [Note] InnoDB: Retry with innodb_force_recovery=5 > 2021-10-31 12:11:36 0 [ERROR] InnoDB: Plugin initialization aborted > with error Data structure corruption > 2021-10-31 12:11:36 0 [Note] InnoDB: Starting shutdown... > 2021-10-31 12:11:36 0 [ERROR] Plugin 'InnoDB' init function returned > error. > 2021-10-31 12:11:36 0 [ERROR] Plugin 'InnoDB' registration as a > STORAGE ENGINE failed. > 2021-10-31 12:11:36 0 [Note] Plugin 'FEEDBACK' is disabled. > 2021-10-31 12:11:36 0 [ERROR] Unknown/unsupported storage engine: InnoDB > 2021-10-31 12:11:36 0 [ERROR] Aborting On a hunch, I decided to install the OpenSuSE OSS repository for 15.2 and this allowed me to drop back and install version 10.4.13-lp152.1.1 of the mariadb server, client, errormessages, and tools packages. (OpenSuSE 15.3 wants to install version 10.5.12-3.9.1 of these mariadb packages.) And lo and behold the previous 10.4.13-lp152.1.1 package works fine! So what gives? Any idea why the upgraded version of mariadb packages are failing to upgrade and support my databases? As I said I have tried Googling for an answer but no joy finding one. A lot of the proposed solutions, Google found, assume the mariadb server is up and running (hump!) so the example solutions given, use mysql queries and commands to fix corrupt databases and tables. I should also point out that AFAIK most, if not all of my database structures are using InnoDB and not the older MYISAM structures (although the mysql database itself appears to have both). I did make a mariadb backup of all the databases but without the ability to start the mariadb server I don't know how to make use of this backup file to reconstruct all the databases and their tables etc. Thanks in advance for any and all advice on how to upgrade my mariadb server. Marc Chamberlin -- *"The Truth is out there" - Spooky* -- *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/This email is digitally signed. My public key for sending encrypted email to me can be found at - https://keys.openpgp.org/search?q=marc@domesweetdome.us.com or just ask me for it and I will send it to you as an attachment. If you don't understand, no worries, just ignore it and/or ask me to explain it further./)

5 12

[Maria-discuss] Failed DDL on Galera
by William Edwards 23 Nov '21

23 Nov '21

Hi, A customer ran an 'ALTER TABLE' query, which failed. This caused Galera slaves to shut themselves down: 2021-11-23 9:35:25 1 [ERROR] Slave SQL: Column 2 of table 'inserve_fpfvxiqm.invoices' cannot be converted from type 'date' to type 'int(10) unsigned', Internal MariaDB error code: 1677 2021-11-23 9:35:25 1 [Warning] WSREP: RBR event 17 Update_rows_v1 apply warning: 3, 28891485 2021-11-23 9:35:25 1 [Warning] WSREP: Failed to apply app buffer: seqno: 28891485, status: 1 at /home/buildbot/buildbot/build/galera/src/trx_handle.cpp:apply():353 [ 3 more times ] 2021-11-23 9:35:25 1 [Warning] WSREP: RBR event 17 Update_rows_v1 apply warning: 3, 28891485 2021-11-23 9:35:26 1 [ERROR] WSREP: Failed to apply trx: source: 41c479ab-0527-11ec-9fcc-9f02b1141194 version: 4 local: 0 state: APPLYING flags: 1 conn_id: 13475392 trx_id: 63620823 seqnos (l: 312653, g: 28891485, s: 28891454, d: 28891449, ts: 10603037948851154) 2021-11-23 9:35:26 1 [ERROR] WSREP: Failed to apply trx 28891485 4 times 2021-11-23 9:35:26 1 [ERROR] WSREP: Node consistency compromised, aborting... The node on which the query was executed, crashed ("mysqld got signal 11"). At first sight, this seems to be the result of "WSREP: Send action {(nil), 528, TORDERED} returned -107 (Transport endpoint is not connected)" - as all the slaves were down at this point. As 'ALTER' is a DDL statement that does not support rollback, I understand that the only option for Galera may be to abort. But is there a way to handle something like this more gracefully? -- With kind regards, William Edwards

1 0

[Maria-discuss] How can I separate one test from mysql_test
by Lukas Javorsky 19 Nov '21

19 Nov '21

Hi guys, I've found few particular tests from the test suite that is failing due to the OpenSSL-3 version and I want to separate them and give them to the OpenSSL team in Red Hat. The idea behind this is to give them a set of commands/config options (reproducer) for each test and they will try to find out what's the exact problem there and help us develop the patch. The tests that I'm interested in are (there are more of them, I just need to see how to reproduce few of them and I'll do the same for the other ones as well): encryption.corrupted_during_recovery encryption.innodb-checksum-algorithm encryption.innodb-discard-import-change encryption.innodb_page_encryption_key_change binlog_encryption.rpl_loaddata_local binlog_encryption.rpl_parallel_free_deferred_event IMPORTANT: These tests are failing only with the 'cbc' cipher in use, the 'ctr' is passing. Could you please help me with how to make a reproducer for each test, so I can create them and give them to the OpenSSL team? Thank you for any help you can provide Lukas -- S pozdravom/ Best regards Lukáš Javorský Associate Software Engineer, Core service - Databases Red Hat <https://www.redhat.com> Purkyňova 115 (TPB-C) 612 00 Brno - Královo Pole ljavorsk(a)redhat.com <https://www.redhat.com>

3 14

[Maria-discuss] Mariadb 10.2 - 10.6 mysqld_multi problem
by Tom Dangler 18 Nov '21

18 Nov '21

We're working on upgrading a mariadb-10.1 server to mariadb-10.6. We run multiple instances of Mariadb on this server, and some run different versions of Mariadb for different reasons. When we attempted to upgrade to mariadb-10.2, we noticed that we can no longer specify mysqld=/path/to/mysqld without generating an error and not starting the instance. We get [ERROR] /opt/mariadb10_2/bin/mysqld: unknown variable 'mysqld=/opt/mariadb10_2/bin/mysqld'. We tested this with 10.2 and 10.6 binaries. When using 10.1 binaries for the [mysqld_multi] group, it accepts the mysqld= argument just fine, and starts each instance with the version defined in mysql= in each option group. The documentation still shows that mysqld= is still a valid configuration, but it does not seem to work from 10.2 to current. Is there a different configuration for this now? We would like to continue using mysqld_multi with different versions of Mariadb. Using 10.1 binaries for mysqld_multi it works [mysqld_multi] mysqld = /opt/mariadb10_1/bin/mysqld_safe mysqladmin = /opt/mariadb10_1/bin/mysqladmin user = multi_admin password = ourpassword Using 10.2 - 10.6 binaries for mysqld_multi we get errors about unknown variable mysqld [mysqld_multi] mysqld = /opt/mariadb10_6/bin/mysqld_safe mysqladmin = /opt/mariadb10_6/bin/mysqladmin user = multi_admin password = ourpassword [mysqld1] mysqld = /opt/mariadb10_1/bin/mysqld datadir = /opt/mysql_data/mariadb10_1 port = 3306 socket = /var/run/mysqld/mariadb_10_1.sock pid-file = /var/run/mysqld/mariadb_10_1.pid user = mysql [mysqld2] mysqld = /opt/mariadb10_2/bin/mysqld datadir = /opt/mysql_data/mariadb10_2 port = 3307 socket = /var/run/mysqld/mariadb_10_2.sock pid-file = /var/run/mysqld/mariadb_10_2.pid user = mysql [mysqld6] mysqld = /opt/mariadb10_6/bin/mysqld datadir = /opt/mysql_data/mariadb10_6 port = 3308 socket = /var/run/mysqld/mariadb_10_6.sock pid-file = /var/run/mysqld/mariadb_10_6.pid user = mysql -- Tom Dangler IT Architect and Systems Manager T 214.778.3158 | M 214.493.0386 | F 888.811.1566 tom.dangler(a)oakwoodsoftware.com Oakwood Software Insurance Solutions 6201 W Plano Parkway | Suite 225 | Plano, TX 75093 Facebook <https://www.facebook.com/OakwoodSoftware> | LinkedIn <https://www.linkedin.com/company/oakwoodsoftware> | Twitter <https://twitter.com/TheRealOakwood> | oakwoodsoftware.com <http://www.oakwoodsoftware.com/> An Amwins Company

1 0

[Maria-discuss] JOB | Permanent DBA in Quebec
by James Tobin 15 Nov '21

15 Nov '21

Contact me using "jamesbtobin (at) gmail (dot) com" to learn more

1 0

[Maria-discuss] Timestamp column not inserting UTC
by William Edwards 13 Nov '21

13 Nov '21

Hi, I have a `timestamp` column, because I would like to insert timestamps in UTC. The documentation says that the inserted value should be converted from my session's time zone to UTC, but I can't reproduce that behaviour. I'm on MariaDB 10.5.9. I have a column of type `timestamp`: `created_at` timestamp NULL DEFAULT NULL The documentation at https://mariadb.com/kb/en/timestamp/ says: "If a column uses the TIMESTAMP data type, then any inserted values are converted from the session's time zone to Coordinated Universal Time (UTC) when stored, and converted back to the session's time zone when retrieved." However, I cannot reproduce this intended behaviour. I set my time zone as follows. (The value was 'SYSTEM', which should also be '+01:00', but I'm setting it explicitly just in case.) -- MariaDB [db]> set time_zone = '+01:00'; Query OK, 0 rows affected (0.006 sec) MariaDB [db]> select now(); +---------------------+ | now() | +---------------------+ | 2021-11-13 14:56:09 | +---------------------+ 1 row in set (0.001 sec) MariaDB [db]> SELECT @@global.time_zone, @@session.time_zone; +--------------------+---------------------+ | @@global.time_zone | @@session.time_zone | +--------------------+---------------------+ | SYSTEM | +01:00 | +--------------------+---------------------+ 1 row in set (0.000 sec) -- Then, I update the values in the `timestamp` column to the timestamp of my session's time zone: -- MariaDB [db]> update objs set created_at=now(); Query OK, 2 rows affected (0.001 sec) Rows matched: 2 Changed: 2 Warnings: 0 -- ... I would expect the inserted value to be converted from my session's time zone ('+01:00') to UTC. However, the inserted value is actually a timestamp of my session's time zone: -- MariaDB [db]> select created_at from objs; +---------------------+ | created_at | +---------------------+ | 2021-11-13 14:56:42 | | 2021-11-13 14:56:42 | +---------------------+ 2 rows in set (0.000 sec) -- I would not be surprised if I'm looking over something very obvious, but I haven't figured it out yet. Hopefully someone sees what I'm missing. TIA! -- With kind regards, William Edwards

1 1

[Maria-discuss] Clarification on Memory utilization of Mariadb
by ragul rangarajan 10 Nov '21

10 Nov '21

Hi Team, Need clarification on Memory utilization of Mariadb. I have a java application with MariaDB that runs on the same Rhel 7 server with physical memory(RAM) allocated as 12GB where I would see the normal utilization at the start as below. *sys> free -h* * total used free shared buff/cache available* *Mem: 11G 7.8G 1.6G 9.0M 2.2G 3.5G* *Swap: 0B 0B 0B* Over a period of time say >6month, I could see the RAM utilization is almost full, and available space is very less but still, the application continues to work fine without any issues. *sys> free -h* * total used free shared buff/cache available* *Mem: 11G 11G 134M 17M 411M 240M* *Swap: 0B 0B 0B* I don't see any OOM issue or high usage of RSS at the java application level but I could see MariaDB occupies huge memory.... apart from that overall application runs fine. To ensure this we observed memory utilization at the large-scale application servers where we deployed MariaDB and Java applications into different servers with 128GB each and could observe that the system with MariaDB uses full RAM size whereas the Java application consumption looks stable. *Server with Java application* sys> free total used free shared buff/cache available Mem: 128755 125171 606 118 2977 2694 Swap: 65535 9746 55789 *Server with MariaDB* sys> free total used free shared buff/cache available Mem: 128755 125171 606 118 2977 2694 Swap: 65535 9746 55789 *MariaDb conf:* innodb_buffer_pool_size=102G innodb_buffer_pool_instances=8 innodb_io_capacity=3000 innodb_log_buffer_size=8M innodb_log_file_size=2047MB innodb_log_files_in_group=2 Is this expected that MariaDB consumes overall memory and manages within RAM size.... regardless of buffer size configured? Do we need to optimize any configuration to control the MariaDB consumption apart from buffer pool size? Thanks and Regards, Ragul

3 3

[Maria-discuss] Troubleshooting Statement That Crashes MariaDB (mysqld got signal 11)
by Michael Caplan 04 Nov '21

04 Nov '21

Hello, I have a nothing fancy SQL statement that crashes MariaDB 10.3.31. The error log reports "mysqld got signal 11" with the below included mini core dump. The statement caused no issues with my prior install of 10.2.xx. With 10.3, the statement runs the majority of the time. The vast majority of the time. I have never dealt with such an issue with MariaDB, and am unsure where to start with troubleshooting this. Any tips? FYI, there is a corresponding bug recorded here: https://jira.mariadb.org/browse/MDEV-26835 Thanks, Mike 211014 16:13:53 [ERROR] mysqld got signal 11 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. To report this bug, see https://mariadb.com/kb/en/reporting-bugs We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. Server version: 10.3.31-MariaDB-1:10.3.31+maria~focal-log key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=587 max_threads=752 thread_count=81 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1784362 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x7f13e83b3768 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x7f1644e96dd8 thread_stack 0x49000 /usr/sbin/mysqld(my_print_stacktrace+0x32)[0x55d5a2f6f3a2] /usr/sbin/mysqld(handle_fatal_signal+0x55d)[0x55d5a2a46e8d] /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f27569fc3c0] /usr/sbin/mysqld(+0x978f4f)[0x55d5a2bdbf4f] /usr/sbin/mysqld(_ZN7handler10ha_rnd_posEPhS0_+0x50)[0x55d5a2a4c6d0] /usr/sbin/mysqld(_Z16rr_from_pointersP11READ_RECORD+0x3e)[0x55d5a2b7cb2e] /usr/sbin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x18e)[0x55d5a28869be] /usr/sbin/mysqld(_ZN4JOIN10exec_innerEv+0xbee)[0x55d5a28b0dce] /usr/sbin/mysqld(_ZN4JOIN4execEv+0x37)[0x55d5a28b1137] /usr/sbin/mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0xf2)[0x55d5a28b1282] /usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x14b)[0x55d5a28b1bcb] /usr/sbin/mysqld(+0x5de9f1)[0x55d5a28419f1] /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x5414)[0x55d5a284f6e4] /usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x1f3)[0x55d5a2852253] /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x105d)[0x55d5a285462d] /usr/sbin/mysqld(_Z10do_commandP3THD+0x12d)[0x55d5a28565dd] /usr/sbin/mysqld(_Z24do_handle_one_connectionP7CONNECT+0x246)[0x55d5a293f186] /usr/sbin/mysqld(handle_one_connection+0x3f)[0x55d5a293f35f] /lib/x86_64-linux-gnu/libpthread.so.0(+0x9609)[0x7f27569f0609] /lib/x86_64-linux-gnu/libc.so.6(clone+0x43)[0x7f2756915293] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7f13e84a8b70): SELECT * FROM (( # # get postings from last statement and postings not on statements # SELECT a.*, COALESCE(ci.id, i.id) as invoice_id FROM ddx_lab_801317.postings a LEFT JOIN ddx_lab_801317.cases_invoices ci ON a.ref_type = 'CASE_INVOICE' AND a.ref_id = ci.id LEFT JOIN ddx_lab_801317.invoices i ON a.ref_type = 'INVOICE' AND a.ref_id = i.id WHERE ( a.statement_date IS NULL OR a.statement_date = '2021-09-27' ) AND a.practice_id='19686' ORDER BY post_date ) UNION ( # # get postings that have remaining balances # SELECT DISTINCT a.*, COALESCE(ci.id, i.id) as invoice_id FROM ddx_lab_801317.postings a LEFT JOIN ddx_lab_801317.cases_invoices ci ON a.ref_type = 'CASE_INVOICE' AND a.ref_id = ci.id LEFT JOIN ddx_lab_801317.invoices i ON a.ref_type = 'INVOICE' AND a.ref_id = i.id LEFT JOIN ddx_lab_801317.postings b ON a.ref_type = b.ref_type AND a.ref_id = b.ref_id AND a.id != b.id WHERE NOT (a.type = 'CREDIT' OR a.type = 'PAYMENT') AND ((SELECT SUM(b.amount)) IS NULL OR (SELECT SUM(a.amount)) + (SELECT SUM(b.amount)) > 0) AND a.practice_id='19686' GROUP BY a.id ORDER BY post_date ) UNION ( # # get partial payments and credits from older statements # SELECT a.*, COALESCE(ci.id, i.id) as invoice_id FROM ddx_lab_801317.postings a LEFT JOIN ddx_lab_801317.cases_invoices ci ON a.ref_type = 'CASE_INVOICE' AND a.ref_id = ci.id LEFT JOIN ddx_lab_801317.invoices i ON a.ref_type = 'INVOICE' AND a.ref_id = i.id WHERE ( a.statement_date < '2021-09-27' ) AND (a.type='PAYMENT' OR a.type='CREDIT') AND a.practice_id='19686' )) AS t1 ORDER BY post_date ASC, invoice_id ASC Connection ID (thread ID): 21014956 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains information that should help you find out what is causing the crash. Writing a core file... Working directory at /var/lib/mysql Resource Limits: Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size 0 unlimited bytes Max resident set unlimited unlimited bytes Max processes unlimited unlimited processes Max open files 1048576 1048576 files Max locked memory unlimited unlimited bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 514974 514974 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us Core pattern: core

2 2

[Maria-discuss] Incorrectly formatted XML files in mariadb-server sources
by Zuzana Miklankova 26 Oct '21

26 Oct '21

Hi, Fedora's rpminspect tool reports [1] some incorrectly formatted XMLs (most of them used for testsuite) within mariadb source files, namely they are: mysql-test/plugin/sphinx/sphinx/testdata.xml - undefined namespace mysql-test/std_data/loadxml.dat - different parser errors, seems to me like it is ill formed on purpose of the test mysql-test/plugin/connect/connect/std_data/nocs.xml - not proper utf-8 encoding mysql-test/std_data/loaddata/mdev9874.xml - not proper utf-8 encoding sql/share/mariadb/charsets/Index.xml - redefined attribute mysql-test/std_data/ldml/Index.xml - redefined attribute It does not seem (to me) that the ill-formatting breaks anything, and that in some cases it is desired. Specifically the loadxml.dat XML, where the test case counts with the form as it is, and Index.xml files, where modification to the XML format could change the meaning of the file. In other cases, it seems (to me) that the correction of the XMLs to a valid format could be possible. These are specifically the XMLs with encoding issues, where it should be sufficient to specify a used charset (ISO-8859-1 in both cases). This is also the case with the undefined namespace in testdata.xml, whose definition should be also possible. Would the correct approach to this issue be to suppress the rpminspect warnings, or should the specified XML files be modified to a valid XML form? Thanks for your opinions in advance. [1] https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pi… Zuzana Miklánková Associate Software Engineer Red Hat <https://www.redhat.com> <https://www.redhat.com>

2 2

[Maria-discuss] MariaDB 10.4 shows a 2e308 cost on a optimization plan correctly preferred by 10.0
by David Strauss 25 Oct '21

25 Oct '21

I'm seeing a regression in query optimization after testing a database+query that was running well on MariaDB 10.0. The issue occurs on an installation of 10.4.18. Version 10.4 considers the plan that 10.0 used but dismisses it as having a cost of 2e308 [1]. The plan 10.4 chooses is highly non-optimal. Based on reviewing some source code, it looks like this sort of "max" cost should only result if summing/multiplying other costs would exceed that maximum. The usual steps of rebuilding tables and index statistics don't help, especially because the JSON output for the optimization plan already shows reasonable index use costs. (The 2e308 cost only starts appearing in a later section.) Because 10.0 lacks the same optimization tracing as 10.4, here is the EXPLAIN output for comparison [2]. Hopefully, there's just something simple amiss and posting here helps anyone else who encounters a 2e308 cost on query optimization plans. I tried to see if this may be fixed in 10.5+, but I haven't found much discussion online of this phenomenon. [1] https://gist.github.com/davidstrauss/becb03fa75ecac046cafe6f05da9f869#file-… [2] https://gist.github.com/davidstrauss/becb03fa75ecac046cafe6f05da9f869#file-…

1 0

[Maria-discuss] State of "alternative" engines and mariadb
by pslawek83 19 Oct '21

19 Oct '21

Hi Guys, what's the state of "alternative" engines (aria and rocks). AFAIR there were some plans to make aria much more advanced than myisam, transactional (transaction safe?) and more optimized for todays hardware. What's the status of RocksBD, basically on the mariadb website i can't find recent updates and most of sources on the internet are outdated. Is it 100% compatible with mariadb nowdays, is there a possibility to have "one-file-per-table" (one set of files) or at least per-database? If everything resides in shared space is there a possibility that one write error (eg. resulting from power loss) can make all rocks tables unreadable? Is it possible to efficiently drop eg. 100GB table partition if the table is using rocks? Last time i checked there were some issues with compaction for Rocks (some limit on DB size, which was rather small can't recall this currently). Is that resolved, and how much additional space is required to compact eg. 1tb database? How's the adoption and developement of both engines going? Are people using it instead of myisam/toku/inno? Is there a lot of effor put into making aria/rocks better? As i'll have to update many servers in the future what's generally the preferred way to go? Drop everything and just use innodb like Oracle did or move towards rocks/aria for everything which doesn't play with innodb well? Another interesting topic is that myisam is having performance issues because of spectre/meltdown mitigations and it seems to hit this engine the most (at least in 10.3, 10.4 as far as I recall). Are there some plans to optimize it for new CPUs (maybe it was already done) or all the effors are going into different storage engines and i should abandon myisam long term? Thanks

2 1

[Maria-discuss] Loading a backup created from 10.6.4 into newly installed 10.6.4 causes mysql.proc to appear corrupt
by Jeff Dyke 01 Oct '21

01 Oct '21

Failing process: Install mariadb from ppa using apt (happens through salt, fwiw) Download last night's backup from a 10.6.4 server, which is a replica from a galera cluster. run the script attached restore_mariabackup.sh Once this is done the database itself works, for our application, but any client trying to access anything that requires mysql.proc gets an error similar to: *Sep 30 19:29:07 devmaria /etc/mysql/debian-start[24656]: error : CorruptSep 30 19:29:07 devmaria /etc/mysql/debian-start[24656]: sys.x$schema_table_statistics* *Sep 30 19:29:07 devmaria /etc/mysql/debian-start[24656]: Error : Cannot load from mysql.proc. The table is probably corrupted * I just built two new servers, one that builds mariadb and then overwrites the data from a backup and one that just installs mariadb. The two different files base_install.proc.sql and backupedup.proc.sql. The error output from sudo mysql_upgrade on the server that received the backup is in mysql_upgrade.out There are more differences in the proc table if i dump the data as well, but i think much of it is driven by the utf8_mb4 rather than 3. Tried to keep this sucient and use attachments. This process has worked for me for until i upgraded to 10.6.4. Please ask anything you need. I think i've been using this similar process to build dev machines since about 10.4 Thanks Jeff

1 2

[Maria-discuss] A general question about performance of update command
by Lehrbass, Robert 27 Sep '21

27 Sep '21

Hi there, I'm new to MariaDB and I'm running tests on the update command. Server version 10.5.11. I'm finding that updates to a table with engine=columnstore are far slower than to a table with default engine=innodb. Obviously, there is no primary key in a table with engine=columnstore, whereas the innodb table does have a primary key. In my tests, for engine=columnstore, 10000 rows took 1995 seconds to be updated, but for engine=innodb, 10000 rows took only 7 seconds to transfer. The difference suggests columnstore takes about 285X longer than innodb. Is this to be expected? I don't need a lengthy answer, btw, just general guidance. Thanks very much, Rob

1 0

[Maria-discuss] DBSeeder Version 3.0.3
by Walter Weinmann 13 Sep '21

13 Sep '21

We are pleased to release version 3.0.3 of DBSeeder ( https://github.com/KonnexionsGmbH/db_seeder) DBSeeder also supports the latest version of MariaDB Server available on Docker Hub (DBMS 10.6.4-focal) and Maven Repository (JDBC 2.7.4). [image: Perf_Snap_3.0.3_win10.png]

2 2

[Maria-discuss] AWS Key management plugin key rotation in replication
by Reinis Rozitis 30 Aug '21

30 Aug '21

Hello, I wanted to clarify - does the key rotation (with AWS KMS backend) work in replication scenario? As in do the slaves (somehow) get also notified and perform the re-encryption if the key is rotated (on master) in background or you have to use different key for each slave for rotation to work? In https://mariadb.com/kb/en/encryption-key-management/#key-rotation it wasn't mentioned. wbr rr

2 3

[Maria-discuss] Issues with Upgrading from MariaDB 10.2.22 to 10.5.12
by Michael Caplan 26 Aug '21

26 Aug '21

Hi there. I'm going through an upgrade process I have done before with earlier versions of mariaDB and Mysql, but running into an issue. My goal is to create a new slave including upgrade process from MariaDB 10.2.22 (serverOld) to 10.5.12 on a new server (serverNew) (as inspired by the brighter mind at https://www.stephenrlang.com/2016/08/setting-up-mysql-master-slave-replicat… ) 1. rsync /var/lib/mysql from serverOld to serverNew 2. On serverOld: FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS; 3. rerun rsync from serverOld to serverNew 4. Release read lock from serverOld 5. Start mariadb on serverNew 6. run mysql_upgrade on serverNew 7. Celebrate and have a nap In actual practice step #5 failed numerous times before what I think is now an okay serverNew # Innodb settings between serverOld and serverNew #serverOld innodb-flush-method = O_DIRECT innodb-log-files-in-group = 2 innodb-log-file-size = 48M innodb-flush-log-at-trx-commit = 2 innodb-file-per-table = 1 innodb-buffer-pool-size = 128M #serverNew innodb-flush-method = O_DIRECT innodb-log-file-size = 48M innodb-flush-log-at-trx-commit = 2 innodb-file-per-table = 1 innodb-buffer-pool-size = 128M The only difference is innodb-log-files-in-group setting is removed in serverNew, as it has been depricated and removed in 10.5 # Upgrade after crash? When attempting to start serverNew, it would fail with the following error: [ERROR] InnoDB: Upgrade after a crash is not supported. The redo log was created with MariaDB 10.2.22. [ERROR] InnoDB: Plugin initialization aborted with error Generic error the log file on serverOld showed no evidence of crashing. None the less, I restarted serverOld, and reran the process above. Still the same issue step #5. # Remove ib_logfile* files I then tried forcing the recreation of the redo logs by removing them and then starting up serverNew. This resulted in the following scary errors: [ERROR] InnoDB: Page [page id: space=0, page number=1984] log sequence number 285722576186 is in the future! Current system log sequence number 259573448177. [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery. # innodb_fast_shutdown = 0 The next attempt started with serverOld being restarted and innodb_fast_shutdown = 0 being set beforehand. I reran the above steps and still got stuck on step #5 with the following error: [ERROR] InnoDB: Upgrade after a crash is not supported. The redo log was created with MariaDB 10.2.22. [ERROR] InnoDB: Plugin initialization aborted with error Generic error This time, however, when I removed the ib_logfile* files, we seemed to have an okay startup: [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728 [Note] InnoDB: Completed initialization of buffer pool [Note] InnoDB: Setting log file ./ib_logfile101 size to 50331648 bytes [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0 [Note] InnoDB: New log file created, LSN=288830457728 [Note] InnoDB: 128 rollback segments are active. [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1" [Note] InnoDB: Creating shared tablespace for temporary tables [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... [Note] InnoDB: File './ibtmp1' size is now 12 MB. [Note] InnoDB: 10.5.12 started; log sequence number 0; transaction id 3037161218 [Note] Plugin 'FEEDBACK' is disabled. [Note] Recovering after a crash using /var/lib/mysql/mysql-bin [Note] Starting crash recovery... [Note] Crash recovery finished. [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool [Note] Server socket created on IP: '::'. [ERROR] Incorrect definition of table mysql.event: expected column 'sql_mode' at position 14 to have type set('REAL_AS_FLOAT','PIPES_AS_CONCAT','ANSI_QUOTES','IGNORE_SPACE','IGNORE_BAD_TABLE_OPTIONS','ONLY_FULL_GROUP_BY','NO_UNSIGNED_SUBTRACTION','NO_DIR_IN_CREATE','POSTGRESQL','ORACLE','MSSQL','DB2','MAXDB','NO_KEY_OPTIONS','NO_TABLE_OPTIONS','NO_FIELD_OPTIONS','MYSQL323','MYSQL40','ANSI','NO_AUTO_VALUE_ON_ZERO','NO_BACKSLASH_ESCAPES','STRICT_TRANS_TABLES','STRICT_ALL_TABLES','NO_ZERO_IN_DATE','NO_ZERO_DATE','INVALID_DATES','ERROR_FOR_DIVISION_BY_ZERO','TRADITIONAL','NO_AUTO_CREATE_USER','HIGH_NOT_PRECEDENCE','NO_ENGINE_SUBSTITUTION','PAD_CHAR_TO_FULL_LENGTH','EMPTY_STRING_IS_NULL','SIMULTANEOUS_ASSIGNMENT'), found type set('REAL_AS_FLOAT','PIPES_AS_CONCAT','ANSI_QUOTES','IGNORE_SPACE','IGNORE_BAD_TABLE_OPTIONS','ONLY_FULL_GROUP_BY','NO_UNSIGNED_SUBTRACTION','NO_DIR_IN_CREATE','POSTGRESQL','ORACLE','MSSQL','DB2','MAXDB','NO_KEY_OPTIONS','NO_TABLE_OPTIONS','NO_FIELD_OPTIONS','MYSQL323','MYSQL40','ANSI','NO_AUTO_VALU [ERROR] mariadbd: Event Scheduler: An error occurred when initializing system tables. Disabling the Event Scheduler. [Note] Reading of all Master_info entries succeeded [Note] Added new Master_info '' to hash table [Note] /usr/sbin/mariadbd: ready for connections. Version: '10.5.12-MariaDB-1:10.5.12+maria~focal-log' socket: '/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution Running mysql_upgrade completed without issue. I'm not feeling confident that this upgrade is actually okay. removing the ib_logfile* seems questionable as a requirement to get the upgrade done. Anyone have similar troubles? Recommendations on what my process should be? Thanks, Mike

3 3

[Maria-discuss] Adding MySQL database backup to rsnapshot for Linux Servers
by Turritopsis Dohrnii Teo En Ming 22 Aug '21

22 Aug '21

Subject: Adding MySQL database backup to rsnapshot for Linux Servers Author: Mr. Turritopsis Dohrnii Teo En Ming (TARGETED INDIVIDUAL) Country: Singapore Date: 22 August 2021 Sunday Singapore Time Type of Pulication: Plain Text Document Version: 20210822.01 DETAILED INSTRUCTIONS ===================== Looking for mysqldump ===================== # which mysqldump /usr/bin/mysqldump Testing if mysqldump works ========================== # /usr/bin/mysqldump --all-databases > mysqldump_all_databases.sql Check the filesize of MySQL dump ================================ # du -h mysqldump_all_databases.sql 23M mysqldump_all_databases.sql Backup rsnapshot configuration file first ========================================= # cd /etc/ # cp rsnapshot.conf rsnapshot.conf.backup20082021 Deploying MySQL backup script ============================= # cp /usr/share/doc/rsnapshot-1.4.3/utils/backup_mysql.sh /usr/local/bin/ # chown root.root /usr/local/bin/backup_mysql.sh # chmod o-w /usr/local/bin/backup_mysql.sh # chmod +x /usr/local/bin/backup_mysql.sh # cat /usr/local/bin/backup_mysql.sh ===BEGIN of backup_mysql.sh=== #!/bin/sh ############################################################################## # backup_mysql.sh # # by Nathan Rosenquist <nathan(a)rsnapshot.org> # http://www.rsnapshot.org/ # # This is a simple shell script to backup a MySQL database with rsnapshot. # # The assumption is that this will be invoked from rsnapshot. Also, since it # will run unattended, the user that runs rsnapshot (probably root) should have # a .my.cnf file in their home directory that contains the password for the # MySQL root user. For example: # # /root/.my.cnf (chmod 0600) # [client] # user = root # password = thepassword # host = localhost # # This script simply needs to dump a file into the current working directory. # rsnapshot handles everything else. ############################################################################## # $Id: backup_mysql.sh,v 1.6 2007/03/22 02:50:21 drhyde Exp $ umask 0077 # backup the database /usr/bin/mysqldump --all-databases > mysqldump_all_databases.sql # make the backup readable only by root /bin/chmod 600 mysqldump_all_databases.sql ===END of backup_mysql.sh=== Edit rsnapshot configuration file ================================== # nano /etc/rsnapshot.conf Under BACKUP POINTS / SCRIPTS add the following line ==================================================== backup_script /usr/local/bin/backup_mysql.sh secret.teo-en-ming-corp.com/mysqldump/ Test the rsnapshot configuration file for syntax errors ======================================================= # rsnapshot configtest require Lchown Lchown module loaded successfully Syntax OK Mr. Turritopsis Dohrnii Teo En Ming, 43 years old as of 22 August 2021, is a TARGETED INDIVIDUAL living in Singapore. He is an IT Consultant with a System Integrator (SI)/computer firm in Singapore. He is an IT enthusiast. -----BEGIN EMAIL SIGNATURE----- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html ******************************************************************************************** Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -----END EMAIL SIGNATURE-----

1 0

[Maria-discuss] MariaDB Server Fest CfP
by Ian Gilfillan 19 Aug '21

19 Aug '21

The Call for Papers for the MariaDB Server Fest is open until 16 August. If you have an idea to share, anything MariaDB-related, new, fun, interesting, scary or exciting, you are welcome to submit at https://mariadb.org/fest2021-cfp-submission/ The MariaDB Server Fest will be held on Tuesday and Wednesday 21-22 September - full details at https://mariadb.org/fest2021/

2 1

[Maria-discuss] ALTER vs MODIFY to set default on a column
by Shane Bishop 14 Aug '21

14 Aug '21

Hi folks, Long story short, I have a table with a TIMESTAMP column where I want to make the default CURRENT_TIMESTAMP (default currently is 1971-01-01 00:00:00). This is part of a WordPress plugin, and so I need to make this as performant as possible. I originally used a query like this: ALTER TABLE wp_ewwwio_images ALTER updated SET DEFAULT CURRENT_TIMESTAMP; This was speedy, and worked a treat, but now I'm finding it doesn't work on all MySQL servers. Notably, we've run into trouble with sites running MariaDB 10.1 and MySQL 5.7, where it says something like this: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near CURRENT_TIMESTAMP Per https://dev.mysql.com/doc/refman/5.7/en/alter-table.html the syntax looks fine. At least, the syntax in the manual is identical to that for MySQL 8: https://dev.mysql.com/doc/refman/8.0/en/alter-table.html And ditto for MariaDB of course: https://mariadb.com/kb/en/alter-table/ The alternative is to use this: ALTER TABLE wp_ewwwio_images MODIFY updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP; This works fine for the affected server versions, but is much slower; ALTER is near instant, MODIFY takes 3-4 seconds on a table with 260k records on SSDs. Who knows what it looks like if some poor sap is on spinning disks still... So I know how to work around said "issue", but what I really want to know is, what IS the actual problem here? Why don't older MySQL (and MariaDB) versions accept the ALTER syntax when the docs are identical? Notably, 10.5 works fine, and I think 10.4 was okay also, don't have any sites to test older versions myself. Thanks! Shane Bishop

3 5

[Maria-discuss] MariaDB master-slave chained replication and parallelism
by Jan Křístek 06 Aug '21

06 Aug '21

Hi, We have a MariaDB 10.3 replication setup with one master and a few chained slaves (each has log_slave_updates switched on). Master uses mainly MyISAM tables, slaves have about 10 or 40 threads for parallel replication. Interesting is, that the first slave in the chain counts replicated statements into Non-Transactional Groups and the following ones count them into Transactional Groups. Also, when checking process lists it seems that just one statement is being processed at the time (of the many threads) on the first slave, while there are multiple slave replication statements being executed on the 2nd and following slaves. Please, does anyone know the reason why the replicated statements are counted into different groups? Or, more importantly, how to increase the parallelism on the first slave in the chain? Thank you for any help. Jan

3 3

[Maria-discuss] sssd with authentication plugin pam
by Michael Barkdoll 05 Aug '21

05 Aug '21

Hi, I'm having issues getting the pam plugin to work with Rocky Linux 8 (RHEL 8) with AppStream MariaDB 10.5. I've installed mariadb appstream for 10.5 and mariadb-pam packages. Added the following to /etc/my.cnf.d: [mariadb] plugin_load_add = auth_pam My sssd is joined to Active Directory. I've created /etc/pam.d/mariadb trying both local pam_unix and pam_sss configurations: # /etc/pam.d/mariadb for local accounts auth required pam_unix.so audit account required pam_unix.so audit # /etc/pam.d/mariadb for sssd active directory accounts auth required pam_sss.so account required pam_sss.so Tried creating local accounts with: #CREATE USER 'user'@'%' IDENTIFIED VIA pam USING 'mariadb'; #GRANT SELECT ON db.* TO 'user'@'%' IDENTIFIED VIA pam; #CREATE USER 'user2'@'%' IDENTIFIED VIA pam; #GRANT SELECT ON db.* TO 'user2'@'%' IDENTIFIED VIA pam; I've also tried creating AD accounts: #CREATE USER 'aduser'@'%' IDENTIFIED VIA pam USING 'mariadb'; #GRANT SELECT ON db.* TO 'aduser'@'%' IDENTIFIED VIA pam; #CREATE USER 'aduser(a)college.edu'@'%' IDENTIFIED VIA pam USING 'mariadb'; #GRANT SELECT ON db.* TO 'aduser(a)college.edu'@'%' IDENTIFIED VIA pam; I see Redhat has issues with MariaDB 10.3 working with pam plugin but it sounded like 10.5 should work? https://bugzilla.redhat.com/show_bug.cgi?id=1942330 I feel like I'm missing something in my /etc/sssd/sssd.conf file or some pam configuration steps. I'm using authselect with sssd: authselect select custom/user-profile with-mkhomedir with-sudo with-pamaccess All attempts to `mysql -u user -p` fail. MariaDB [(none)]> show plugins; | pam | ACTIVE | AUTHENTICATION | auth_pam.so | GPL | I tried adding a [pam] section to sssd. [pam] pam_public_domains = all pam_verbosity = 3 Didn't seem to help. I used realmd to join AD. Any help is much appreciated. mysql -u user -p Enter password: ERROR 1045 (28000): Access denied for user 'user'@'localhost' (using password: NO)

4 13

Re: [Maria-discuss] MariaDB master-slave chained replication and parallelism
by Jan Křístek 05 Aug '21

05 Aug '21

Hi Kristian, Thank you for your answer. On Thu, 5 Aug 2021 at 09:44, Kristian Nielsen <knielsen(a)knielsen-hq.org> wrote: > > Interesting. Where do you see these counts? My guess is that these are > counting the "transactional" status flag on each GTID event in the binlog. > I see these counts almost at the end of 'mysql -e "show slave status\G"' You can see these yourself in a mysqlbinlog output from a binlog on the > master respectively the slaves. > I will check that when I get the setup running again. Thank you for the tip. If these show non-transactional on the master but transactional on the first > slave, it sounds like you are replicating from MyISAM tables on the master > to InnoDB tables on the slave. Try SHOW CREATE TABLE t on a relevant table > on the master and the slave and see which storage engine they are using. > I am sure that at least the big tables use MyISAM on master and all the slaves. Could be that one or two small tables use InnoDB. But when the replication is running, just one counter is always increasing, the other is staying zero (or in case of switching the master while being run) staying fixed. Thus, the first slave sees MyISAM changes, and does not do parallel > operation, but writes InnoDB transactions. These InnoDB transactions are > then seen by following slaves which enables the parallel replication > algorithms. > This could be the reason, even though I am sure that all slaves use MyISAM for almost all tables. I suppose that (could be) the default engine might be switched to InnoDB. > The obvious answer is to change the tables to be InnoDB on the master. > Which > may or may not be possible in your setup. > Oh, this is not so easy. The size of a few MyISAM tables is reaching almost TBs. And thank you for the idea with the BlackHole engine :) Jan

2 4

[Maria-discuss] DBSeeder Version 3.0.1
by Walter Weinmann 03 Aug '21

03 Aug '21

We are pleased to release version 3.0.1 of DBSeeder ( https://github.com/KonnexionsGmbH/db_seeder) The most important enhancement is the possibility to deactivate the constraints of the type FOREIGN, PRIMARY and UNIQUE KEY before the DML statements and to activate them again afterwards. The JDBC DatabaseMetaData class is used for this purpose. DBSeeder also supports the latest version of MariaDB Server available on Docker Hub (DBMS 10.6.3) and Maven Repository (JDBC 2.7.3).

1 0

[Maria-discuss] MySQL crash after 'partial' version upgrade
by William Edwards 26 Jul '21

26 Jul '21

Hello, The weather probably has an effect on me, because I'm not seeing the cause for the issue below right away. Hopefully someone can use the cluebat. Also, I apologize if we're not supposed to paste snippets of this size in email, but I couldn't find a mailing list policy on this. I was using this repo: `deb [arch=amd64,i386,ppc64el] http://mariadb.mirror.pcextreme.nl/repo/10.3/debian stretch main` This repo was no longer being updated, so I replaced it with this repo: `deb [arch=amd64,arm64,ppc64el] http://ams2.mirrors.digitalocean.com/mariadb/repo/10.3/debian buster main` That made these updates available: ``` galera-3/unknown 25.3.33-buster amd64 [upgradable from: 25.3.32-stretch] libmariadb-dev-compat/unknown 1:10.3.30+maria~buster amd64 [upgradable from: 1:10.3.28+maria~stretch] libmariadb-dev/unknown 1:10.3.30+maria~buster amd64 [upgradable from: 1:10.3.28+maria~stretch] libmariadb3/unknown 1:10.3.30+maria~buster amd64 [upgradable from: 1:10.3.28+maria~stretch] mariadb-client-10.3/unknown 1:10.3.30+maria~buster amd64 [upgradable from: 1:10.3.28+maria~stretch] mariadb-client-core-10.3/unknown 1:10.3.30+maria~buster amd64 [upgradable from: 1:10.3.28+maria~stretch] mariadb-common/unknown,unknown,unknown 1:10.3.30+maria~buster all [upgradable from: 1:10.3.28+maria~stretch] mariadb-server-10.3/unknown 1:10.3.30+maria~buster amd64 [upgradable from: 1:10.3.28+maria~stretch] mariadb-server-core-10.3/unknown 1:10.3.30+maria~buster amd64 [upgradable from: 1:10.3.28+maria~stretch] mysql-common/unknown,unknown,unknown 1:10.3.30+maria~buster all [upgradable from: 1:10.3.28+maria~stretch] ``` Ansible then wrongly attempted installing the meta package 'mariadb-server', which was not installed yet ('mariadb-server-10.3' was installed directly). This meta package depends on 'mariadb-server-10.3 (>= 1:10.3.30+maria~buster)' (we were running 10.3.28, and an update was now available), so apt did this: ``` Building dependency tree... Reading state information... The following packages were automatically installed and are no longer required: gir1.2-packagekitglib-1.0 libappstream4 libglib2.0-bin libgstreamer1.0-0 libpackagekit-glib2-18 libstemmer0d packagekit packagekit-tools python3-distro-info python3-software-properties Use 'apt autoremove' to remove them. The following additional packages will be installed: mariadb-client-10.3 mariadb-client-core-10.3 mariadb-common mariadb-server-10.3 mariadb-server-core-10.3 Suggested packages: mailx mariadb-test netcat-openbsd tinyca The following NEW packages will be installed: mariadb-server The following packages will be upgraded: mariadb-client-10.3 mariadb-client-core-10.3 mariadb-common mariadb-server-10.3 mariadb-server-core-10.3 5 upgraded, 1 newly installed, 0 to remove and 32 not upgraded. Need to get 12.0 MB of archives. [...] dpkg: error processing package mariadb-server-10.3 (--configure): installed mariadb-server-10.3 package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of mariadb-server: mariadb-server depends on mariadb-server-10.3 (>= 1:10.3.30+maria~buster); however: Package mariadb-server-10.3 is not configured yet. dpkg: error processing package mariadb-server (--configure): dependency problems - leaving unconfigured Processing triggers for man-db (2.8.5-2) ... Processing triggers for systemd (241-7~deb10u8) ... Errors were encountered while processing: mariadb-server-10.3 mariadb-server ``` From 16:06:44 (apt upgrade fail time), SST kept failing due to https://jira.mariadb.org/browse/MDEV-26172 (most likely not related to this issue), till 16:09:32, which is when I stopped MariaDB. After stopping and starting MariaDB (probably loading new libraries), I started seeing this: ``` 210723 16:09:33 [ERROR] mysqld got signal 11 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. To report this bug, see https://mariadb.com/kb/en/reporting-bugs We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. Server version: 10.3.30-MariaDB-1:10.3.30+maria~buster-log key_buffer_size=134217728 read_buffer_size=131072 max_used_connections=0 max_threads=102 thread_count=4 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 355304 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x7f0d8c000c08 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x7f0d9effcce8 thread_stack 0x49000 /usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x561a7200ddee] /usr/sbin/mysqld(handle_fatal_signal+0x54d)[0x561a71b2087d] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f0df182b730] /usr/sbin/mysqld(+0x9a6f22)[0x561a71d10f22] /usr/sbin/mysqld(+0xa80632)[0x561a71dea632] /usr/sbin/mysqld(+0xa03852)[0x561a71d6d852] /usr/sbin/mysqld(+0xa039f5)[0x561a71d6d9f5] /usr/sbin/mysqld(+0x9fe0f1)[0x561a71d680f1] /usr/sbin/mysqld(+0x9fe1e2)[0x561a71d681e2] /usr/sbin/mysqld(+0xa00aba)[0x561a71d6aaba] /usr/sbin/mysqld(+0xa01129)[0x561a71d6b129] /usr/sbin/mysqld(+0x9c2d88)[0x561a71d2cd88] /usr/sbin/mysqld(+0xa2777c)[0x561a71d9177c] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3)[0x7f0df1820fa3] /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f0df174f4cf] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x0): (null) Connection ID (thread ID): 3 Status: NOT_KILLED Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains information that should help you find out what is causing the crash. We think the query pointer is invalid, but we will try to print it anyway. Query: Writing a core file... Working directory at /var/lib/mysql Resource Limits: Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size 0 unlimited bytes Max resident set unlimited unlimited bytes Max processes 15657 15657 processes Max open files 32133 32133 files Max locked memory 67108864 67108864 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 15657 15657 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us Core pattern: core ``` Thanks to systemd, this went on for 2 minutes, until this, which is when I gave up trying to fix this and replaced the node in the Galera cluster: ``` 2021-07-23 16:11:07 0 [Note] Starting crash recovery... 2021-07-23 16:11:07 0 [Note] Crash recovery finished. 2021-07-23 16:11:07 6 [ERROR] mysqld: Table './mysql/user' is marked as crashed and should be repaired 2021-07-23 16:11:07 6 [Warning] Checking table: './mysql/user' 2021-07-23 16:11:07 6 [ERROR] mysql.user: 1 client is using or hasn't closed the table properly /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3)[0x7f0f17430fa3] 2021-07-23 16:11:08 0 [ERROR] InnoDB: Page [page id: space=11326, page number=3] log sequence number 30633696699 is in the future! Current system log sequence number 30424127374. 2021-07-23 16:11:08 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery. 2021-07-23 16:11:08 0 [ERROR] InnoDB: Page [page id: space=11330, page number=3] log sequence number 30634051832 is in the future! Current system log sequence number 30424127374. 2021-07-23 16:11:08 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery. 2021-07-23 16:11:08 0 [ERROR] InnoDB: Page [page id: space=11332, page number=3] log sequence number 30634054073 is in the future! Current system log sequence number 30424127374. 2021-07-23 16:11:08 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery. 2021-07-23 16:11:08 0 [ERROR] InnoDB: Page [page id: space=11333, page number=3] log sequence number 30633696016 is in the future! Current system log sequence number 30424127374. 2021-07-23 16:11:08 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery. /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f0f1735f4cf] ``` These are the packages that apt installed/upgraded: ``` The following additional packages will be installed: mariadb-client-10.3 mariadb-client-core-10.3 mariadb-common mariadb-server-10.3 mariadb-server-core-10.3 Suggested packages: mailx mariadb-test netcat-openbsd tinyca The following NEW packages will be installed: mariadb-server The following packages will be upgraded: mariadb-client-10.3 mariadb-client-core-10.3 mariadb-common mariadb-server-10.3 mariadb-server-core-10.3 ``` That means that these packages, that were available for upgrade, were not upgraded: - mysql-common - libmariadb3 - libmariadb-dev - libmariadb-dev-compat - galera-3 However, none of the upgraded packages depend on newer versions of the packages above, so I would have expected this - even though installing the meta package was a mistake - to just work (assuming the problem was an e.g. outdated library). I have two other machines in the same situation, where I simply did 'apt upgrade' after replacing the repo, and all seems well. In conclusion: replacing a repo that provides an update from 10.3.28 to 10.3.30, then installing the 'mariadb-server' meta package that does not install all available updates (like 'libmariadb3'), caused MySQL to crash (badly)... While installing all available updates at the same time ('apt upgrade') does not cause this issue on another machine. I don't necessarily want to understand how to avoid this specific situation, because I should've done a full upgrade in any case, but I am wondering what I am missing that caused this issue. -- With kind regards, William Edwards

3 3

[Maria-discuss] MariaDB daily backups on EC2/EBS via EBS snapshots?
by Joachim Dorn 12 Jul '21

12 Jul '21

Hi, for the scenario of a daily backup on a MariaDB with InnoDB engine running on a EC2 with EBS - would a EBS snapshot be enough to have consistent backups that MariaDB could restore from? I know that I might lose in-flight transactions without any "flushing", but for a daily backup, I accept the backup being a few (milli) seconds bit behind, as long as I have a consistent persistent state. To my understanding Amazon EBS snapshots are consistent point-in-time snapshots (e.g via copy-on-write) of the volume, and MariaDB with a transactional storage engine guarantees transactional consistent writes to disk under all conditions. Thanks for any clarification! Joachim

1 0

[Maria-discuss] dist-upgrade for minor version upgrade
by William Edwards 10 Jul '21

10 Jul '21

Hi, https://mariadb.com/kb/en/upgrading-from-mariadb-104-to-mariadb-105/ (and all other minor upgrade guides) contain these steps: 2. Stop MariaDB. 3. Uninstall the old version of MariaDB: On Debian, Ubuntu, and other similar Linux distributions, execute the following: sudo apt-get remove mariadb-server 4. Install the new version of MariaDB. I'm thinking to myself: doesn't it make more sense to instruct readers to 'dist-upgrade' on Ubuntu and Debian (which works because of the 'Replaces' in newer packages)? That would merge steps 3 and 4 (and maybe step 2 as well, because of stop_server() in preinst) into one command that could be easier to use for novice users. Sorry if I missed a detail that dist-upgrade does not take care of. -- With kind regards, William Edwards

2 1

[Maria-discuss] Differences between MariaDB packages
by William Edwards 27 Jun '21

27 Jun '21

Hello, I recently discovered a bug in my MariaDB deployment process. I have two Ansible tasks that respectively add the downloads.mariadb.org Debian repo, and install mariadb-server-10.*. I forgot to add 'update_cache: yes' to the repo add task, so incidentally mariadb-server-10.* was actually installed from the Debian repo. I have seen the following differences between the mariadb-server-10.* packages: - Packages from Debian repo only come with the 'root@localhost' user. Packages from MariaDB repo come with the users 'root@localhost', 'root@::1' and 'root(a)127.0.0.1'. - Packages from Debian repo don't come with 'debian-sys-maint@localhost' user. Instead, the 'root' user is used in /etc/mysql/debian.cnf - Packages from Debian repo use DebianAlternatives for my.cnf. Packages from MariaDB repo also come with a more advanced my.cnf, e.g. 'bind-address = 127.0.0.1' is set - not being able to remotely connect is how I discovered this bug on my side. - Packages from MariaDB repo come with package configuration (specifically: setting root password). Q: I'm wondering if anyone has a more complete list of differences between these packages (the above is just what I've observed from fixing issues due to this bug). I don't know if the Debian maintainers for this package branch off a package by MariaDB, so I posted this here, but please let me know if I would be better off posting this on a Debian mailing list. TIA. With kind regards, William Edwards

3 2

[Maria-discuss] OpenSSL 3.0 support
by Lukas Javorsky 17 Jun '21

17 Jun '21

Hi, We've created two Jira tickets for the OpenSSL 3.0 support, however, we didn't really get a response or any detailed information from you about it. Connector-c: https://jira.mariadb.org/browse/CONC-503 Server: https://jira.mariadb.org/browse/MDEV-25785 It's our big concern to support this ASAP because we are aiming to support OpenSSL version 3.0 in the RHEL-9 which is coming soon. Our mission in RHEL-9 is to aim for the newest software version because we are going to support this OS for more than 10 years, and the major changes should be done in the beginning. We would like to know your opinion about this so we can maybe try to help you in some way. Please let us know what you think about it. Thank you and have a nice day -- S pozdravom/ Best regards Lukáš Javorský Associate Software Engineer, Core service - Databases Red Hat <https://www.redhat.com> Purkyňova 115 (TPB-C) 612 00 Brno - Královo Pole ljavorsk(a)redhat.com <https://www.redhat.com>

2 1

[Maria-discuss] Problem with mariabackup
by Riccardo Brunetti 17 Jun '21

17 Jun '21

Hello. We are using the mariabackup tool to stream to a remote server the backup of our databases. We are having some issue because in the middle of the operation the db server stops responding for many minutes until we ultimately kill the mariabackup process. During the lock, we can see the following: > MariaDB [(none)]> show processlist; > > +--------+----------------------------+-----------------+--------------------------+---------+------+------------------------------+------------------------------------------------------------------------------------------------------+----------+ > > | Id | User | Host | db | Command | Time | State | Info | Progress | > > +--------+----------------------------+-----------------+--------------------------+---------+------+------------------------------+------------------------------------------------------------------------------------------------------+----------+ > > | 3 | system user | | NULL | Daemon | NULL | InnoDB purge worker | NULL | 0.000 | > > | 4 | system user | | NULL | Daemon | NULL | InnoDB purge worker | NULL | 0.000 | > > | 1 | system user | | NULL | Daemon | NULL | InnoDB purge coordinator | NULL | 0.000 | > > | 2 | system user | | NULL | Daemon | NULL | InnoDB purge worker | NULL | 0.000 | > > | 5 | system user | | NULL | Daemon | NULL | InnoDB shutdown handler | NULL | 0.000 | > > | 274355 | root | localhost:42512 | NULL | Sleep | 407 | | NULL | 0.000 | > > | 297631 | udaww4uw_gsut | localhost:39784 | udaww4uw_gsprod | Query | 17 | Waiting for global read lock | UPDATE `wp_litespeed_crawler` SET reason = CONCAT( SUBSTRING_INDEX( reason, ',', 0 ), '200', SUBSTRI | 0.000 | > > | 302083 | ud4k9xsm_pres633 | localhost | ud4k9xsm_pres633 | Query | 47 | Waiting for global read lock | DELETE FROM `ps4d_marketplace_product_action` > > WHERE `id_product` = 7356 AND `id_lan | 0.000 | > > | 302391 | udaww4uw_gsut | localhost:50748 | udaww4uw_gsprod | Query | 46 | Waiting for global read lock | INSERT INTO wp_post_views (id, type, period, count) > > VALUES (62075, 3, '2021', 1) > > ON DUPLIC | 0.000 | > > | 302395 | uqlugtoj_enedina.it | localhost | uqlugtoj_enedina | Query | 44 | Waiting for global read lock | UPDATE `wp_options` SET `option_value` = '1623829414' WHERE `option_name` = '_transient_timeout_wc_r | 0.000 | > > | 302404 | udlah5r1_remigio | localhost:50782 | udlah5r1_vtiger71 | Query | 44 | Waiting for global read lock | insert into vtiger_pbxmanager(pbxmanagerid,direction,callstatus,starttime,endtime,totalduration,bill | 0.000 | > > | 302431 | utlmb6ko_6M0oD0 | localhost | utlmb6ko_6M0oD0 | Query | 38 | Waiting for global read lock | UPDATE `wp_options` SET `option_value` = '1623743080' WHERE `option_name` = 'action_scheduler_lock_a | 0.000 | > > | 302432 | uml1gkxr_58IJ3 | localhost:50836 | uml1gkxr_prod | Query | 38 | Waiting for global read lock | UPDATE `wp_options` SET `option_value` = 'a:13835:{i:1226;s:32:\"ab7050de2954be1e369e358a15a17c48\"; | 0.000 | > > | 302433 | uml1gkxr_58IJ3 | localhost:50838 | uml1gkxr_prod | Query | 38 | Waiting for global read lock | UPDATE `wp_options` SET `option_value` = 'a:13835:{i:1226;s:32:\"ab7050de2954be1e369e358a15a17c48\"; | 0.000 | > > | 302440 | uqtx0c94_giorgio | localhost:50848 | uqtx0c94_due | Query | 38 | Waiting for global read lock | UPDATE `wp_options` SET `option_value` = '[]' WHERE `option_name` = '_transient_adsforwp_transient_a | 0.000 | > > | 302473 | uw6vnwff_helpdesk | localhost:50932 | uw6vnwff_helpassist | Query | 30 | Waiting for global read lock | INSERT INTO ost_syslog SET created=NOW(), updated=NOW() ,title='DB Error #1205',log_type='Error',log | 0.000 | At the same time, we see messages like these in the system log: > Executing FLUSH NO_WRITE_TO_BINLOG TABLES... > > Executing FLUSH TABLES WITH READ LOCK... This is the command we launch to backup data: > mariabackup --backup --stream=xbstream --user=root --extra-lsndir=${BCKDBDIR} -u${MYSQLUSER} -p${MYSQLPW} -H ${MYSQLHOST}" Is it somehow an expected behavior (some of the db are quite heavily used)? How can we avoid those locks? Thanks Riccardo

3 7

[Maria-discuss] Disable Some Operators in Fulltext Boolean mode
by Samuel Lorch 12 Jun '21

12 Jun '21

Hello, I am using MariaDB in a Project and to Allow users to Search the Data we use Fulltext Indexes, as you cannot make a Fulltext Index across multiple tables we have multiple match against statements and are Combining them with OR. The Problem is that the Natural Language Mode only Matches Full Words and not Partial ones. The Solution is Boolean Mode where you can append a * to a word to allow 0 or more characters. But Boolean Mode also Brings Other Operators. These other Operator can Behave Unexpectedly for The User when Combining Multiple Match Against Statements With OR. Using the "ft_boolean_syntax" variable one can change the characters used for these operators but this is limited to ASCII characters below 127. I suggest That we add a special character that disables a operator. What do you think about this? Or do you See a different Solution? Regards, Samuel

1 0

[Maria-discuss] DBSeeder Version 2.9.0
by Walter Weinmann 08 Jun '21

08 Jun '21

We are happy to announce that version 2.9.0 of DBSeeder ( https://github.com/KonnexionsGmbH/db_seeder) is now available for general use. DBSeeder also supports the latest version of MariaDB Server available on DockerHub (10.6.1).

2 2

[Maria-discuss] Can't build mariadb 10.5 without gssapi?
by Chris Ross (cross2) 27 May '21

27 May '21

G’day there. So, I was trying to turn off the auth_gssapi plugin which we aren’t using in our build of mariadb 10.5.8. However, adding -DPLUGIN_AUTH_GSSAPI=NO, which is how I've turned off multiple other plugins, seems to have no effect. It still searches for gssapi, and then later builds auth_gssapi_client. Is there an issue/defect open yet that this plugin can't be disabled, or have I done something incorrectly to turn it off? - Chris

2 1

[Maria-discuss] Performance of MariaDB ODBC connector
by Dušan Pavlica 05 May '21

05 May '21

Hi, I'm new with MariaDB. We try to switch from MySQL 5.0.96 to MariaDB 10.5.9. Move data to MariaDB was easy but now we have problems with speed of ODBC connector. I tried MariaDB ODBC connector 3.1.12 with default settings without SSL and our applications (mostly written in Embarcadero RAD Studio) showed very poor performance. When I tried MySQL ODBC connector 8.0.24 everything ran smoothly. Queries through MariaDB's connector was 3-5 times slower. In general query log I found that MariaDB's connector generates a lot of queries to information_scheme.columns table and all over again it reads variable TX_ISOLATION. Short extract - MariaDB connector: 3 Query SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.SESSION_VARIABLES WHERE VARIABLE_NAME='TX_ISOLATION' 3 Prepare select * from stanice 3 Execute select * from stanice 3 Prepare SELECT TABLE_SCHEMA AS TABLE_CAT, NULL AS TABLE_SCHEM, TABLE_NAME, COLUMN_NAME, ORDINAL_POSITION KEY_SEQ, 'PRIMARY' PK_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_KEY = 'pri' AND TABLE_SCHEMA LIKE 'unicentrum' AND TABLE_NAME LIKE 'stanice' ORDER BY TABLE_SCHEMA, TABLE_NAME, ORDINAL_POSITION 3 Execute SELECT TABLE_SCHEMA AS TABLE_CAT, NULL AS TABLE_SCHEM, TABLE_NAME, COLUMN_NAME, ORDINAL_POSITION KEY_SEQ, 'PRIMARY' PK_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_KEY = 'pri' AND TABLE_SCHEMA LIKE 'unicentrum' AND TABLE_NAME LIKE 'stanice' ORDER BY TABLE_SCHEMA, TABLE_NAME, ORDINAL_POSITION 3 Close stmt 3 Reset stmt 3 Query SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.SESSION_VARIABLES WHERE VARIABLE_NAME='TX_ISOLATION' 3 Prepare SELECT * FROM stanice WHERE Sit_ID = ? ORDER BY Sit_ID, Podsit_ID, ID 3 Execute SELECT * FROM stanice WHERE Sit_ID = 1 ORDER BY Sit_ID, Podsit_ID, ID 3 Prepare SELECT TABLE_SCHEMA AS TABLE_CAT, NULL AS TABLE_SCHEM, TABLE_NAME, COLUMN_NAME, ORDINAL_POSITION KEY_SEQ, 'PRIMARY' PK_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_KEY = 'pri' AND TABLE_SCHEMA LIKE 'unicentrum' AND TABLE_NAME LIKE 'stanice' ORDER BY TABLE_SCHEMA, TABLE_NAME, ORDINAL_POSITION 3 Execute SELECT TABLE_SCHEMA AS TABLE_CAT, NULL AS TABLE_SCHEM, TABLE_NAME, COLUMN_NAME, ORDINAL_POSITION KEY_SEQ, 'PRIMARY' PK_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_KEY = 'pri' AND TABLE_SCHEMA LIKE 'unicentrum' AND TABLE_NAME LIKE 'stanice' ORDER BY TABLE_SCHEMA, TABLE_NAME, ORDINAL_POSITION 3 Close stmt 3 Reset stmt MySQL connector: 3 Query SELECT @@tx_isolation ... 3 Query select * from stanice 3 Prepare SELECT * FROM stanice WHERE Sit_ID = ? ORDER BY Sit_ID, Podsit_ID, ID 3 Execute SELECT * FROM stanice WHERE Sit_ID = '1' ORDER BY Sit_ID, Podsit_ID, ID 3 Close stmt I think those "unnecessary" queries are making difference in performance of those connectors. Does anybody have any ideas what could I do to speed up MariaDB's connector? We prefer not using MySQL connectors anymore. Thanks in advance Dušan Pavlica

2 1

[Maria-discuss] How to Host Multiple Mail Domains (Email Hosting) in iRedMail Full Featured Linux Mail Server
by Turritopsis Dohrnii Teo En Ming 04 May '21

04 May '21

Subject: How to Host Multiple Mail Domains (Email Hosting) in iRedMail Full Featured Linux Mail Server Author: Mr. Turritopsis Dohrnii Teo En Ming (TARGETED INDIVIDUAL) Country: Singapore Date: 3rd May 2021 Monday Type of Publication: PDF Manual Document Version: 20210503.01 ***IMPORTANT NOTICE*** Please note that Turritopsis Dohrnii Teo En Ming’s guide is based on Xiao Guoan’s guide at linuxbabe.com. Reference Guide Used by Teo En Ming: How to Host Multiple Mail Domains in iRedMail with Nginx Link: https://www.linuxbabe.com/mail-server/set-up-iredmail-multiple-domains-nginx Original Author: Xiao Guoan The following is a list of open-source software that will be automatically installed and configured by iRedMail. • Postfix SMTP server • Dovecot IMAP server • Nginx web server to serve the admin panel and webmail • OpenLDAP, MySQL/MariaDB, or PostgreSQL for storing user information • Amavised-new for DKIM signing and verification • SpamAssassin for anti-spam • ClamAV for anti-virus • Roundcube webmail • SOGo groupware, providing webmail, calendar (CalDAV), contacts (CardDAV), tasks and ActiveSync services. • Fail2ban for protecting SSH • mlmmj mailing list manager • Netdata server monitoring • iRedAPD Postfix policy server for greylisting In addition, you need to add MX, A and TXT records to your ISC BIND DNS domain name server. Redundant download links for Turritopsis Dohrnii Teo En Ming's PDF manual: [1] https://www.mediafire.com/file/q6txmx0rc1cwfzw/Additional+Mail+Domains+1st+… [2] https://www.docdroid.net/Q9TRL5D/additional-mail-domains-1st-release-pdf [3] https://www.scribd.com/document/506193434/Additional-Mail-Domains-1st-Relea… [4] https://drive.google.com/file/d/10AYGt4-omBeC3vXJfzswQq0M7E09gXpG/view?usp=… [5] https://drive.google.com/file/d/113dy0AKmBYGugBueK1vS_dJwI35J6XmJ/view?usp=… [6] https://drive.google.com/file/d/1dhpYIZp31ug5hoiVNbjh6uh99s_PEx8q/view?usp=… Mr. Turritopsis Dohrnii Teo En Ming, 43 years old as of 4th May 2021, is a TARGETED INDIVIDUAL living in Singapore. He is an IT Consultant with a System Integrator (SI)/computer firm in Singapore. He is an IT enthusiast. -----BEGIN EMAIL SIGNATURE----- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html ******************************************************************************************** Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -----END EMAIL SIGNATURE-----

2 1

[Maria-discuss] Help for USE is missing
by Krzysztof Żelechowski 27 Apr '21

27 Apr '21

Mel: \h USE mysql: Nothing found Expected: <URL: https://mariadb.com/kb/en/use/ > Please fix, Chris

1 0

[Maria-discuss] How to Easily Set Up a Full-Featured Linux Mail Server on Ubuntu 18.04.5 LTS with iRedMail 1.4.0
by Turritopsis Dohrnii Teo En Ming 26 Apr '21

26 Apr '21

Subject: How to Easily Set Up a Full-Featured Linux Mail Server on Ubuntu 18.04.5 LTS with iRedMail 1.4.0 Good day from Singapore, I followed linuxbabe.com's Xiao Guoan's guide and successfully setup a full featured Linux mail server on Ubuntu 18.04.5 LTS with IRedMail 1.4.0. Author: Mr. Turritopsis Dohrnii Teo En Ming (TARGETED INDIVIDUAL) Country: Singapore Date: 25 April 2021 Sunday Type of Publication: PDF Manual Document Version: 20210425.01 (1st release) ***IMPORTANT NOTICE*** Please note that Turritopsis Dohrnii Teo En Ming’s guide is based on Xiao Guoan’s guide at linuxbabe.com. Reference Guide Used by Teo En Ming: How to Easily Set Up a Full-Featured Mail Server on Ubuntu 18.04 with iRedMail Link: https://www.linuxbabe.com/mail-server/ubuntu-18-04-iredmail-email-server Original Author: Xiao Guoan The following is a list of open-source software that will be automatically installed and configured by iRedMail. • Postfix SMTP server • Dovecot IMAP server • Nginx web server to serve the admin panel and webmail • OpenLDAP, MySQL/MariaDB, or PostgreSQL for storing user information • Amavised-new for DKIM signing and verification • SpamAssassin for anti-spam • ClamAV for anti-virus • Roundcube webmail • SOGo groupware, providing webmail, calendar (CalDAV), contacts (CardDAV), tasks and ActiveSync services. • Fail2ban for protecting SSH • mlmmj mailing list manager • Netdata server monitoring • iRedAPD Postfix policy server for greylisting Redundant Download Links for Teo En Ming's PDF Manual: [1] https://drive.google.com/file/d/1un8sLLmNSMIt7V6blWCvJEgwGvxMbd4B/view?usp=… [2] https://drive.google.com/file/d/1i0vY7kfYkobu563qoI3_qCZg7G7BFoYR/view?usp=… [3] https://drive.google.com/file/d/1U9MFN1EklLbA8TMweLV5ntiSJuBBVkpQ/view?usp=… [4] https://www.docdroid.net/dW70KtS/iredmail-setup-1st-release-pdf [5] https://www.mediafire.com/file/evar7j28knqyoj6/IRedMail+Setup+1st+Release.p… [6] https://www.scribd.com/document/504932780/IRedMail-Setup-1st-Release Mr. Turritopsis Dohrnii Teo En Ming, 43 years old as of 26 April 2021, is a TARGETED INDIVIDUAL living in Singapore. He is an IT Consultant with a System Integrator (SI)/computer firm in Singapore. He is an IT enthusiast. -----BEGIN EMAIL SIGNATURE----- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html ******************************************************************************************** Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -----END EMAIL SIGNATURE-----

1 0

[Maria-discuss] pt-online-schema-change vs alter with alter_algorithm='NOCOPY'
by Jeff Dyke 24 Apr '21

24 Apr '21

Hi. In previous jobs, i have used pt-online-schema-change quite a bit, normally testing the change the night before it went live. I have a very good understanding about how pt-online-schema-change works and i would like to understand the inner workings of alter_algorithm='NOCOPY'. If i can trust that as much as the percona script, i'm going to be happy happy person. Thanks. This is my reddit post. https://www.reddit.com/r/mariadb/comments/mx4e60/ptonlineschemachange_vs_al… . I know we have a lot of great responders here, and if the answer comes here or on reddit, i will copy and paste for everyone's knowledge. Thanks all!

1 0

[Maria-discuss] Galera cluster will not bootstrap with SST set to use TLS
by lejeczek 23 Apr '21

23 Apr '21

Hi Guys. I wonder if anybody sees the same or similar issues which I do experience with SST, or maybe could try to reproduce it simply by: [sst] tkey = /etc/my.cnf.d/certs/sst/sst.key tcert = /etc/my.cnf.d/certs/sst/sst.crt Yes, by having SST to use TLS. If I do have those two params in my config then 'galera_new_cluster' fails to bootstrap new cluster. (naturally all other bits to required are set with TLS) Suffices to take those out and cluster bootstrap okey, then, on such up&running cluster, I can on each node put those back in and, one by one, restart the service/server and... it works!? I filled a bug report - https://jira.mariadb.org/browse/MDEV-25435 - and will appreciate if somebody can comment. many thanks, L.

1 0

[Maria-discuss] Building mariadb without PCRE?
by Chris Ross (cross2) 21 Apr '21

21 Apr '21

Good day. We have been using MariaDB in our product for a while, and are upgrading to 10.5.8 at the moment. I’ve just noticed that it’s no longer using the PCRE on our system, it’s grabbing its own from outside since the upgrade to PCRE2. We’re not using PCRE extensions at all in our applications, and I’d rather not pull in another extraneous library. We are a largely embedded product, and adding libraries is a technical and bureaucratic effort. Can I just build mariadb without PCRE support at all, using the traditional extended POSIX regexps instead? I don’t see a way to do this in the cmake files/parameters. - Chris -- Chris Ross cross2(a)cisco.com

3 5

[Maria-discuss] Planning on setting up Postfix + Dovecot + Webmail + Apache + MariaDB + PHP using Webmin Control Panel in the Cloud
by Turritopsis Dohrnii Teo En Ming 21 Apr '21

21 Apr '21

Subject: Planning on setting up Postfix + Dovecot + Webmail + Apache + MariaDB + PHP using Webmin Control Panel in the Cloud Good day from the Republic of Singapore, I am planning to setup Postfix Email Server + Dovecot IMAP/POP3 Incoming Mail Server + Webmail (Roundcube or Squirrelmail) + Apache Web Server + MariaDB Database Server + PHP using Webmin Control Panel specifically, in the cloud, preferably Amazon EC2. Are there any very good and well written guides on doing this type of setup? I am looking forward to your reply. Thank you very much. Mr. Turritopsis Dohrnii Teo En Ming, 43 years old as of 21 April 2021 Wed, is a TARGETED INDIVIDUAL (TI) living in Singapore. He is an IT Consultant with a System Integrator (SI)/computer firm in Singapore. He is an IT enthusiast. -----BEGIN EMAIL SIGNATURE----- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html ******************************************************************************************** Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -----END EMAIL SIGNATURE-----

2 1

[Maria-discuss] mysql_upgrade fails
by Majed Zouhairy 21 Apr '21

21 Apr '21

in last time's upgrade and today i got: sudo mysql_upgrade -u root -p Enter password: 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.help_category OK mysql.help_keyword OK mysql.help_relation OK mysql.help_topic OK mysql.host OK mysql.index_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.user OK Phase 2/7: Installing used storage engines... Skipped Phase 3/7: Fixing views Phase 4/7: Running 'mysql_fix_privilege_tables' ERROR 1813 (HY000) at line 77: Tablespace for table '`mysql`.`innodb_table_stats`' exists. Please DISCARD the tablespace before IMPORT ERROR 1813 (HY000) at line 81: Tablespace for table '`mysql`.`innodb_index_stats`' exists. Please DISCARD the tablespace before IMPORT ERROR 1813 (HY000) at line 85: Tablespace for table '`mysql`.`transaction_registry`' exists. Please DISCARD the tablespace before IMPORT ERROR 1813 (HY000) at line 153: Tablespace for table '`mysql`.`gtid_slave_pos`' exists. Please DISCARD the tablespace before IMPORT ERROR 1146 (42S02) at line 642: Table 'mysql.innodb_index_stats' doesn't exist ERROR 1243 (HY000) at line 643: Unknown prepared statement handler (stmt) given to EXECUTE ERROR 1146 (42S02) at line 645: Table 'mysql.innodb_table_stats' doesn't exist ERROR 1243 (HY000) at line 646: Unknown prepared statement handler (stmt) given to EXECUTE ERROR 1146 (42S02) at line 650: Table 'mysql.innodb_index_stats' doesn't exist ERROR 1146 (42S02) at line 654: Table 'mysql.innodb_table_stats' doesn't exist ERROR 1146 (42S02) at line 657: Table 'mysql.innodb_table_stats' doesn't exist FATAL ERROR: Upgrade failed what to do?

2 1

[Maria-discuss] SST's TLS in Galera prevents bootstrapping a new cluster
by lejeczek 12 Apr '21

12 Apr '21

Hi guys. It's pretty strange, in fact so strange that I presume I must be messing up something rather that MariaDB/Galera behaving this way by design. Thus before I paste any log snippets this question first: Why having this - [sst] tkey = /etc/my.cnf.d/certs/sst/sst.key tcert = /etc/my.cnf.d/certs/sst/sst.crt - would prevent a user to bootstrap new cluster? If do not use tkey/tcert I can bootstrap fine and after, cluster is up & running I put those back, then very next restart of mariadb on any/each node will work just fine. What is happening there some expert would mind to shed more light? many thanks, L.

1 0

[Maria-discuss] Exceeding configured memory
by Sig Pam 12 Apr '21

12 Apr '21

Hi all! I run into problems with the memory configuration of MariaDB 10.3.27 on Debian 10. It looks as if it exceeds the configured memory. The server hat 4 GB of memory. It runs MariaDB and a Kopano (Mail/Collaboration) server. The configuration I believe I have made is 2GB for MariaDB, plus 1 GB for Kopano. The rest is for reserved for the OS. If I look at the process list, I can see that mysql greatly exceeds the configured 2GB limit: root@exchange64:~# ps -e -o "vsz rss pid comm" | grep mysql 4933304 1604212 852 mysqld The virtual process size is 4.9 GB, with 1.6 GB resident in RAM. I think this is the reason why the server heavily uses swap: root@exchange64:~# free total used free shared buff/cache available Mem: 4027240 2812284 117932 49712 1097024 875632 Swap: 4191228 1963464 2227764 <- 1.9 GB of swap in use The server runs only one database. The database itself consists only INNODB tables, with some of them being quite large: MariaDB [zarafa]> show table status; +-------------------+--------+---------+------------+---------+------------- ---+-------------+-----------------+--------------+-------------+----------- -----+---------------------+---------------------+------------+------------- -------+----------+-----------------------------------------+---------+----- -------------+-----------+ | Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Collation | Checksum | Create_options | Comment | Max_index_length | Temporary | +-------------------+--------+---------+------------+---------+------------- ---+-------------+-----------------+--------------+-------------+----------- -----+---------------------+---------------------+------------+------------- -------+----------+-----------------------------------------+---------+----- -------------+-----------+ | abchanges | InnoDB | 10 | Compact | 223 | 293 | 65536 | 0 | 98304 | 13429112832 | 57841 | 2019-10-02 08:01:57 | NULL | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | acl | InnoDB | 10 | Compact | 134 | 122 | 16384 | 0 | 0 | 13429112832 | NULL | 2019-10-02 08:01:57 | NULL | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | changes | InnoDB | 10 | Compact | 3531055 | 136 | 483393536 | 0 | 693075968 | 13429112832 | 4601576 | 2019-10-02 08:06:06 | 2021-04-12 08:06:29 | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | deferredupdate | InnoDB | 10 | Compact | 20038 | 116 | 2342912 | 0 | 442368 | 13429112832 | NULL | 2019-10-02 08:06:06 | 2021-04-12 08:06:29 | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | hierarchy | InnoDB | 10 | Compact | 348880 | 61 | 21495808 | 0 | 12976128 | 13429112832 | 2361351 | 2019-10-02 08:06:07 | 2021-04-12 08:06:29 | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | indexedproperties | InnoDB | 10 | Compact | 259399 | 103 | 26787840 | 0 | 25640960 | 13429112832 | NULL | 2019-10-02 08:06:10 | 2021-04-12 08:06:29 | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | lob | InnoDB | 10 | Compact | 130069 | 175090 | 22773825536 | 0 | 0 | 13429112832 | NULL | 2019-10-02 08:08:59 | 2021-04-12 08:05:53 | NULL | utf8mb4_general_ci | NULL | max_rows=1000000000 avg_row_length=1750 | | 0 | N | | mvproperties | InnoDB | 10 | Compact | 9703 | 158 | 1540096 | 0 | 0 | 13429112832 | NULL | 2019-10-02 08:08:59 | 2021-04-12 06:58:44 | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | names | InnoDB | 10 | Compact | 3283 | 69 | 229376 | 0 | 671744 | 13429112832 | 3294 | 2019-10-02 08:08:59 | NULL | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | object | InnoDB | 10 | Compact | 6 | 2730 | 16384 | 0 | 32768 | 13429112832 | 7 | 2019-10-02 08:08:59 | NULL | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | objectmvproperty | InnoDB | 10 | Compact | 0 | 0 | 16384 | 0 | 0 | 13429112832 | NULL | 2019-10-02 08:08:59 | NULL | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | objectproperty | InnoDB | 10 | Compact | 40 | 409 | 16384 | 0 | 0 | 13429112832 | NULL | 2019-10-02 08:08:59 | NULL | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | objectrelation | InnoDB | 10 | Compact | 3 | 5461 | 16384 | 0 | 0 | 13429112832 | NULL | 2019-10-02 08:08:59 | NULL | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | outgoingqueue | InnoDB | 10 | Compact | 0 | 0 | 16384 | 0 | 0 | 13429112832 | NULL | 2019-10-02 08:08:59 | 2021-04-12 07:20:40 | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | properties | InnoDB | 10 | Compact | 9895527 | 414 | 4104863744 | 0 | 0 | 13429112832 | NULL | 2019-10-02 08:12:52 | 2021-04-12 08:18:25 | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | receivefolder | InnoDB | 10 | Compact | 60 | 273 | 16384 | 0 | 16384 | 13429112832 | 209 | 2019-02-06 17:01:07 | NULL | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | searchresults | InnoDB | 10 | Compact | 7404 | 161 | 1196032 | 0 | 0 | 13429112832 | NULL | 2019-02-06 17:01:08 | 2021-04-12 06:58:46 | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | settings | InnoDB | 10 | Compact | 6 | 2730 | 16384 | 0 | 0 | 13429112832 | NULL | 2019-02-06 17:07:00 | 2021-04-12 08:05:53 | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | singleinstances | InnoDB | 10 | Compact | 93075 | 70 | 6553600 | 0 | 4472832 | 13429112832 | 789962 | 2019-02-06 17:01:09 | 2021-04-12 08:05:53 | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | stores | InnoDB | 10 | Compact | 16 | 1024 | 16384 | 0 | 16384 | 13429112832 | 55 | 2019-02-06 17:01:09 | NULL | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | syncedmessages | InnoDB | 10 | Compact | 31098 | 135 | 4210688 | 0 | 2113536 | 13429112832 | NULL | 2019-02-06 17:01:09 | 2021-04-12 08:08:07 | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | syncs | InnoDB | 10 | Compact | 30813 | 85 | 2621440 | 0 | 5750784 | 13429112832 | 255042 | 2019-02-06 17:01:10 | 2021-04-12 08:18:24 | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | tproperties | InnoDB | 10 | Compact | 8528065 | 103 | 881278976 | 0 | 319373312 | 13429112832 | NULL | 2019-02-06 17:06:59 | 2021-04-12 08:06:29 | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | usergroup_acl | InnoDB | 10 | Compact | 2 | 8192 | 16384 | 0 | 0 | 13429112832 | NULL | 2018-11-08 18:13:26 | NULL | NULL | latin1_swedish_ci | NULL | | | 0 | N | | users | InnoDB | 10 | Compact | 24 | 682 | 16384 | 0 | 16384 | 13429112832 | 86 | 2019-02-06 17:06:59 | NULL | NULL | utf8mb4_general_ci | NULL | | | 0 | N | | versions | InnoDB | 10 | Compact | 88 | 186 | 16384 | 0 | 0 | 13429112832 | NULL | 2019-02-06 17:06:59 | NULL | NULL | utf8mb4_general_ci | NULL | | | 0 | N | +-------------------+--------+---------+------------+---------+------------- ---+-------------+-----------------+--------------+-------------+----------- -----+---------------------+---------------------+------------+------------- -------+----------+-----------------------------------------+---------+----- -------------+-----------+ 26 rows in set (0.490 sec) These are the innodb variables: MariaDB [zarafa]> show variables like 'innodb%'; +---------------------------------------------+------------------------+ | Variable_name | Value | +---------------------------------------------+------------------------+ | innodb_adaptive_flushing | ON | | innodb_adaptive_flushing_lwm | 10.000000 | | innodb_adaptive_hash_index | ON | | innodb_adaptive_hash_index_parts | 8 | | innodb_adaptive_max_sleep_delay | 150000 | | innodb_autoextend_increment | 64 | | innodb_autoinc_lock_mode | 1 | | innodb_background_scrub_data_check_interval | 3600 | | innodb_background_scrub_data_compressed | OFF | | innodb_background_scrub_data_interval | 604800 | | innodb_background_scrub_data_uncompressed | OFF | | innodb_buf_dump_status_frequency | 0 | | innodb_buffer_pool_chunk_size | 134217728 | | innodb_buffer_pool_dump_at_shutdown | ON | | innodb_buffer_pool_dump_now | OFF | | innodb_buffer_pool_dump_pct | 25 | | innodb_buffer_pool_filename | ib_buffer_pool | | innodb_buffer_pool_instances | 8 | | innodb_buffer_pool_load_abort | OFF | | innodb_buffer_pool_load_at_startup | ON | | innodb_buffer_pool_load_now | OFF | | innodb_buffer_pool_size | 2147483648 | | innodb_change_buffer_max_size | 25 | | innodb_change_buffering | all | | innodb_checksum_algorithm | crc32 | | innodb_checksums | ON | | innodb_cmp_per_index_enabled | OFF | | innodb_commit_concurrency | 0 | | innodb_compression_algorithm | zlib | | innodb_compression_default | OFF | | innodb_compression_failure_threshold_pct | 5 | | innodb_compression_level | 6 | | innodb_compression_pad_pct_max | 50 | | innodb_concurrency_tickets | 5000 | | innodb_data_file_path | ibdata1:12M:autoextend | | innodb_data_home_dir | | | innodb_deadlock_detect | ON | | innodb_default_encryption_key_id | 1 | | innodb_default_row_format | dynamic | | innodb_defragment | OFF | | innodb_defragment_fill_factor | 0.900000 | | innodb_defragment_fill_factor_n_recs | 20 | | innodb_defragment_frequency | 40 | | innodb_defragment_n_pages | 7 | | innodb_defragment_stats_accuracy | 0 | | innodb_disable_sort_file_cache | OFF | | innodb_disallow_writes | OFF | | innodb_doublewrite | ON | | innodb_encrypt_log | OFF | | innodb_encrypt_tables | OFF | | innodb_encrypt_temporary_tables | OFF | | innodb_encryption_rotate_key_age | 1 | | innodb_encryption_rotation_iops | 100 | | innodb_encryption_threads | 0 | | innodb_fast_shutdown | 1 | | innodb_fatal_semaphore_wait_threshold | 600 | | innodb_file_format | | | innodb_file_per_table | ON | | innodb_fill_factor | 100 | | innodb_flush_log_at_timeout | 1 | | innodb_flush_log_at_trx_commit | 1 | | innodb_flush_method | fsync | | innodb_flush_neighbors | 1 | | innodb_flush_sync | ON | | innodb_flushing_avg_loops | 30 | | innodb_force_load_corrupted | OFF | | innodb_force_primary_key | OFF | | innodb_force_recovery | 0 | | innodb_ft_aux_table | | | innodb_ft_cache_size | 8000000 | | innodb_ft_enable_diag_print | OFF | | innodb_ft_enable_stopword | ON | | innodb_ft_max_token_size | 84 | | innodb_ft_min_token_size | 3 | | innodb_ft_num_word_optimize | 2000 | | innodb_ft_result_cache_limit | 2000000000 | | innodb_ft_server_stopword_table | | | innodb_ft_sort_pll_degree | 2 | | innodb_ft_total_cache_size | 640000000 | | innodb_ft_user_stopword_table | | | innodb_idle_flush_pct | 100 | | innodb_immediate_scrub_data_uncompressed | OFF | | innodb_instant_alter_column_allowed | add_last | | innodb_io_capacity | 200 | | innodb_io_capacity_max | 2000 | | innodb_large_prefix | | | innodb_lock_schedule_algorithm | fcfs | | innodb_lock_wait_timeout | 50 | | innodb_locks_unsafe_for_binlog | OFF | | innodb_log_buffer_size | 33554432 | | innodb_log_checksums | ON | | innodb_log_compressed_pages | ON | | innodb_log_file_size | 536870912 | | innodb_log_files_in_group | 2 | | innodb_log_group_home_dir | ./ | | innodb_log_optimize_ddl | OFF | | innodb_log_write_ahead_size | 8192 | | innodb_lru_scan_depth | 1024 | | innodb_max_dirty_pages_pct | 75.000000 | | innodb_max_dirty_pages_pct_lwm | 0.000000 | | innodb_max_purge_lag | 0 | | innodb_max_purge_lag_delay | 0 | | innodb_max_purge_lag_wait | 4294967295 | | innodb_max_undo_log_size | 10485760 | | innodb_monitor_disable | | | innodb_monitor_enable | | | innodb_monitor_reset | | | innodb_monitor_reset_all | | | innodb_old_blocks_pct | 37 | | innodb_old_blocks_time | 1000 | | innodb_online_alter_log_max_size | 134217728 | | innodb_open_files | 1000 | | innodb_optimize_fulltext_only | OFF | | innodb_page_cleaners | 4 | | innodb_page_size | 16384 | | innodb_prefix_index_cluster_optimization | OFF | | innodb_print_all_deadlocks | OFF | | innodb_purge_batch_size | 300 | | innodb_purge_rseg_truncate_frequency | 128 | | innodb_purge_threads | 4 | | innodb_random_read_ahead | OFF | | innodb_read_ahead_threshold | 56 | | innodb_read_io_threads | 4 | | innodb_read_only | OFF | | innodb_replication_delay | 0 | | innodb_rollback_on_timeout | OFF | | innodb_rollback_segments | 128 | | innodb_scrub_log | OFF | | innodb_scrub_log_speed | 256 | | innodb_sort_buffer_size | 1048576 | | innodb_spin_wait_delay | 4 | | innodb_stats_auto_recalc | ON | | innodb_stats_include_delete_marked | OFF | | innodb_stats_method | nulls_equal | | innodb_stats_modified_counter | 0 | | innodb_stats_on_metadata | OFF | | innodb_stats_persistent | ON | | innodb_stats_persistent_sample_pages | 20 | | innodb_stats_sample_pages | 8 | | innodb_stats_traditional | ON | | innodb_stats_transient_sample_pages | 8 | | innodb_status_output | OFF | | innodb_status_output_locks | OFF | | innodb_strict_mode | ON | | innodb_sync_array_size | 1 | | innodb_sync_spin_loops | 30 | | innodb_table_locks | ON | | innodb_temp_data_file_path | ibtmp1:12M:autoextend | | innodb_thread_concurrency | 0 | | innodb_thread_sleep_delay | 10000 | | innodb_tmpdir | | | innodb_undo_directory | ./ | | innodb_undo_log_truncate | OFF | | innodb_undo_logs | 128 | | innodb_undo_tablespaces | 0 | | innodb_use_atomic_writes | ON | | innodb_use_native_aio | ON | | innodb_version | 10.3.27 | | innodb_write_io_threads | 4 | +---------------------------------------------+------------------------+ 159 rows in set (0.217 sec) And for completeness, all variables (sorry, it's long and looks ugly): root@exchange64:/etc/mysql/conf.d# <mailto:root@exchange64:/etc/mysql/conf.d#> echo "show variables;" | mysql zarafa Variable_name Value alter_algorithm DEFAULT aria_block_size 8192 aria_checkpoint_interval 30 aria_checkpoint_log_activity 1048576 aria_encrypt_tables OFF aria_force_start_after_recovery_failures 0 aria_group_commit none aria_group_commit_interval 0 aria_log_file_size 1073741824 aria_log_purge_type immediate aria_max_sort_file_size 9223372036853727232 aria_page_checksum ON aria_pagecache_age_threshold 300 aria_pagecache_buffer_size 134217728 aria_pagecache_division_limit 100 aria_pagecache_file_hash_size 512 aria_recover_options BACKUP,QUICK aria_repair_threads 1 aria_sort_buffer_size 268434432 aria_stats_method nulls_unequal aria_sync_log_dir NEWFILE aria_used_for_temp_tables ON auto_increment_increment 1 auto_increment_offset 1 autocommit ON automatic_sp_privileges ON back_log 80 basedir /usr big_tables OFF bind_address 127.0.0.1 binlog_annotate_row_events ON binlog_cache_size 32768 binlog_checksum CRC32 binlog_commit_wait_count 0 binlog_commit_wait_usec 100000 binlog_direct_non_transactional_updates OFF binlog_file_cache_size 16384 binlog_format MIXED binlog_optimize_thread_scheduling ON binlog_row_image FULL binlog_stmt_cache_size 32768 bulk_insert_buffer_size 8388608 character_set_client utf8mb4 character_set_connection utf8mb4 character_set_database latin1 character_set_filesystem binary character_set_results utf8mb4 character_set_server utf8mb4 character_set_system utf8 character_sets_dir /usr/share/mysql/charsets/ check_constraint_checks ON collation_connection utf8mb4_general_ci collation_database latin1_swedish_ci collation_server utf8mb4_general_ci column_compression_threshold 100 column_compression_zlib_level 6 column_compression_zlib_strategy DEFAULT_STRATEGY column_compression_zlib_wrap OFF completion_type NO_CHAIN concurrent_insert AUTO connect_timeout 10 core_file OFF datadir /var/lib/mysql/ date_format %Y-%m-%d datetime_format %Y-%m-%d %H:%i:%s deadlock_search_depth_long 15 deadlock_search_depth_short 4 deadlock_timeout_long 50000000 deadlock_timeout_short 10000 debug_no_thread_alarm OFF default_master_connection default_regex_flags default_storage_engine InnoDB default_tmp_storage_engine default_week_format 0 delay_key_write ON delayed_insert_limit 100 delayed_insert_timeout 300 delayed_queue_size 1000 div_precision_increment 4 encrypt_binlog OFF encrypt_tmp_disk_tables OFF encrypt_tmp_files OFF enforce_storage_engine eq_range_index_dive_limit 0 error_count 0 event_scheduler OFF expensive_subquery_limit 100 expire_logs_days 10 explicit_defaults_for_timestamp OFF external_user extra_max_connections 1 extra_port 0 flush OFF flush_time 0 foreign_key_checks ON ft_boolean_syntax + -><()~*:""&| ft_max_word_len 84 ft_min_word_len 4 ft_query_expansion_limit 20 ft_stopword_file (built-in) general_log OFF general_log_file exchange64.log group_concat_max_len 1048576 gtid_binlog_pos gtid_binlog_state gtid_current_pos gtid_domain_id 0 gtid_ignore_duplicates OFF gtid_pos_auto_engines gtid_seq_no 0 gtid_slave_pos gtid_strict_mode OFF have_compress YES have_crypt YES have_dynamic_loading YES have_geometry YES have_openssl NO have_profiling YES have_query_cache YES have_rtree_keys YES have_ssl DISABLED have_symlink YES histogram_size 0 histogram_type SINGLE_PREC_HB host_cache_size 279 hostname exchange64 identity 0 idle_readonly_transaction_timeout 0 idle_transaction_timeout 0 idle_write_transaction_timeout 0 ignore_builtin_innodb OFF ignore_db_dirs in_predicate_conversion_threshold 1000 in_transaction 0 init_connect init_file init_slave innodb_adaptive_flushing ON innodb_adaptive_flushing_lwm 10.000000 innodb_adaptive_hash_index ON innodb_adaptive_hash_index_parts 8 innodb_adaptive_max_sleep_delay 150000 innodb_autoextend_increment 64 innodb_autoinc_lock_mode 1 innodb_background_scrub_data_check_interval 3600 innodb_background_scrub_data_compressed OFF innodb_background_scrub_data_interval 604800 innodb_background_scrub_data_uncompressed OFF innodb_buf_dump_status_frequency 0 innodb_buffer_pool_chunk_size 134217728 innodb_buffer_pool_dump_at_shutdown ON innodb_buffer_pool_dump_now OFF innodb_buffer_pool_dump_pct 25 innodb_buffer_pool_filename ib_buffer_pool innodb_buffer_pool_instances 8 innodb_buffer_pool_load_abort OFF innodb_buffer_pool_load_at_startup ON innodb_buffer_pool_load_now OFF innodb_buffer_pool_size 2147483648 innodb_change_buffer_max_size 25 innodb_change_buffering all innodb_checksum_algorithm crc32 innodb_checksums ON innodb_cmp_per_index_enabled OFF innodb_commit_concurrency 0 innodb_compression_algorithm zlib innodb_compression_default OFF innodb_compression_failure_threshold_pct 5 innodb_compression_level 6 innodb_compression_pad_pct_max 50 innodb_concurrency_tickets 5000 innodb_data_file_path ibdata1:12M:autoextend innodb_data_home_dir innodb_deadlock_detect ON innodb_default_encryption_key_id 1 innodb_default_row_format dynamic innodb_defragment OFF innodb_defragment_fill_factor 0.900000 innodb_defragment_fill_factor_n_recs 20 innodb_defragment_frequency 40 innodb_defragment_n_pages 7 innodb_defragment_stats_accuracy 0 innodb_disable_sort_file_cache OFF innodb_disallow_writes OFF innodb_doublewrite ON innodb_encrypt_log OFF innodb_encrypt_tables OFF innodb_encrypt_temporary_tables OFF innodb_encryption_rotate_key_age 1 innodb_encryption_rotation_iops 100 innodb_encryption_threads 0 innodb_fast_shutdown 1 innodb_fatal_semaphore_wait_threshold 600 innodb_file_format innodb_file_per_table ON innodb_fill_factor 100 innodb_flush_log_at_timeout 1 innodb_flush_log_at_trx_commit 1 innodb_flush_method fsync innodb_flush_neighbors 1 innodb_flush_sync ON innodb_flushing_avg_loops 30 innodb_force_load_corrupted OFF innodb_force_primary_key OFF innodb_force_recovery 0 innodb_ft_aux_table innodb_ft_cache_size 8000000 innodb_ft_enable_diag_print OFF innodb_ft_enable_stopword ON innodb_ft_max_token_size 84 innodb_ft_min_token_size 3 innodb_ft_num_word_optimize 2000 innodb_ft_result_cache_limit 2000000000 innodb_ft_server_stopword_table innodb_ft_sort_pll_degree 2 innodb_ft_total_cache_size 640000000 innodb_ft_user_stopword_table innodb_idle_flush_pct 100 innodb_immediate_scrub_data_uncompressed OFF innodb_instant_alter_column_allowed add_last innodb_io_capacity 200 innodb_io_capacity_max 2000 innodb_large_prefix innodb_lock_schedule_algorithm fcfs innodb_lock_wait_timeout 50 innodb_locks_unsafe_for_binlog OFF innodb_log_buffer_size 33554432 innodb_log_checksums ON innodb_log_compressed_pages ON innodb_log_file_size 536870912 innodb_log_files_in_group 2 innodb_log_group_home_dir ./ innodb_log_optimize_ddl OFF innodb_log_write_ahead_size 8192 innodb_lru_scan_depth 1024 innodb_max_dirty_pages_pct 75.000000 innodb_max_dirty_pages_pct_lwm 0.000000 innodb_max_purge_lag 0 innodb_max_purge_lag_delay 0 innodb_max_purge_lag_wait 4294967295 innodb_max_undo_log_size 10485760 innodb_monitor_disable innodb_monitor_enable innodb_monitor_reset innodb_monitor_reset_all innodb_old_blocks_pct 37 innodb_old_blocks_time 1000 innodb_online_alter_log_max_size 134217728 innodb_open_files 1000 innodb_optimize_fulltext_only OFF innodb_page_cleaners 4 innodb_page_size 16384 innodb_prefix_index_cluster_optimization OFF innodb_print_all_deadlocks OFF innodb_purge_batch_size 300 innodb_purge_rseg_truncate_frequency 128 innodb_purge_threads 4 innodb_random_read_ahead OFF innodb_read_ahead_threshold 56 innodb_read_io_threads 4 innodb_read_only OFF innodb_replication_delay 0 innodb_rollback_on_timeout OFF innodb_rollback_segments 128 innodb_scrub_log OFF innodb_scrub_log_speed 256 innodb_sort_buffer_size 1048576 innodb_spin_wait_delay 4 innodb_stats_auto_recalc ON innodb_stats_include_delete_marked OFF innodb_stats_method nulls_equal innodb_stats_modified_counter 0 innodb_stats_on_metadata OFF innodb_stats_persistent ON innodb_stats_persistent_sample_pages 20 innodb_stats_sample_pages 8 innodb_stats_traditional ON innodb_stats_transient_sample_pages 8 innodb_status_output OFF innodb_status_output_locks OFF innodb_strict_mode ON innodb_sync_array_size 1 innodb_sync_spin_loops 30 innodb_table_locks ON innodb_temp_data_file_path ibtmp1:12M:autoextend innodb_thread_concurrency 0 innodb_thread_sleep_delay 10000 innodb_tmpdir innodb_undo_directory ./ innodb_undo_log_truncate OFF innodb_undo_logs 128 innodb_undo_tablespaces 0 innodb_use_atomic_writes ON innodb_use_native_aio ON innodb_version 10.3.27 innodb_write_io_threads 4 insert_id 0 interactive_timeout 28800 join_buffer_size 262144 join_buffer_space_limit 2097152 join_cache_level 2 keep_files_on_create OFF key_buffer_size 134217728 key_cache_age_threshold 300 key_cache_block_size 1024 key_cache_division_limit 100 key_cache_file_hash_size 512 key_cache_segments 0 large_files_support ON large_page_size 0 large_pages OFF last_gtid last_insert_id 0 lc_messages en_US lc_messages_dir /usr/share/mysql lc_time_names en_US license GPL local_infile ON lock_wait_timeout 86400 locked_in_memory OFF log_bin OFF log_bin_basename log_bin_compress OFF log_bin_compress_min_len 256 log_bin_index log_bin_trust_function_creators OFF log_disabled_statements sp log_error /var/log/mysql/error.log log_output FILE log_queries_not_using_indexes OFF log_slave_updates OFF log_slow_admin_statements ON log_slow_disabled_statements sp log_slow_filter admin,filesort,filesort_on_disk,filesort_priority_queue,full_join,full_scan, query_cache,query_cache_miss,tmp_table,tmp_table_on_disk log_slow_rate_limit 1 log_slow_slave_statements ON log_slow_verbosity log_tc_size 24576 log_warnings 2 long_query_time 10.000000 low_priority_updates OFF lower_case_file_system OFF lower_case_table_names 0 master_verify_checksum OFF max_allowed_packet 16777216 max_binlog_cache_size 18446744073709547520 max_binlog_size 1073741824 max_binlog_stmt_cache_size 18446744073709547520 max_connect_errors 100 max_connections 151 max_delayed_threads 20 max_digest_length 1024 max_error_count 64 max_heap_table_size 16777216 max_insert_delayed_threads 20 max_join_size 18446744073709551615 max_length_for_sort_data 1024 max_long_data_size 16777216 max_prepared_stmt_count 16382 max_recursive_iterations 4294967295 max_relay_log_size 1073741824 max_seeks_for_key 4294967295 max_session_mem_used 9223372036854775807 max_sort_length 1024 max_sp_recursion_depth 0 max_statement_time 0.000000 max_tmp_tables 32 max_user_connections 0 max_write_lock_count 4294967295 metadata_locks_cache_size 1024 metadata_locks_hash_instances 8 min_examined_row_limit 0 mrr_buffer_size 262144 multi_range_count 256 myisam_block_size 1024 myisam_data_pointer_size 6 myisam_max_sort_file_size 9223372036853727232 myisam_mmap_size 18446744073709551615 myisam_recover_options BACKUP,QUICK myisam_repair_threads 1 myisam_sort_buffer_size 134216704 myisam_stats_method NULLS_UNEQUAL myisam_use_mmap OFF mysql56_temporal_format ON net_buffer_length 16384 net_read_timeout 30 net_retry_count 10 net_write_timeout 60 old OFF old_alter_table DEFAULT old_mode old_passwords OFF open_files_limit 16186 optimizer_prune_level 1 optimizer_search_depth 62 optimizer_selectivity_sampling_limit 100 optimizer_switch index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_in tersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=of f,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmat ch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_ma tch_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr _cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cac he=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optim ize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in= on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materi alized=on optimizer_use_condition_selectivity 1 performance_schema OFF performance_schema_accounts_size -1 performance_schema_digests_size -1 performance_schema_events_stages_history_long_size -1 performance_schema_events_stages_history_size -1 performance_schema_events_statements_history_long_size -1 performance_schema_events_statements_history_size -1 performance_schema_events_waits_history_long_size -1 performance_schema_events_waits_history_size -1 performance_schema_hosts_size -1 performance_schema_max_cond_classes 80 performance_schema_max_cond_instances -1 performance_schema_max_digest_length 1024 performance_schema_max_file_classes 50 performance_schema_max_file_handles 32768 performance_schema_max_file_instances -1 performance_schema_max_mutex_classes 200 performance_schema_max_mutex_instances -1 performance_schema_max_rwlock_classes 40 performance_schema_max_rwlock_instances -1 performance_schema_max_socket_classes 10 performance_schema_max_socket_instances -1 performance_schema_max_stage_classes 160 performance_schema_max_statement_classes 200 performance_schema_max_table_handles -1 performance_schema_max_table_instances -1 performance_schema_max_thread_classes 50 performance_schema_max_thread_instances -1 performance_schema_session_connect_attrs_size -1 performance_schema_setup_actors_size 100 performance_schema_setup_objects_size 100 performance_schema_users_size -1 pid_file /run/mysqld/mysqld.pid plugin_dir /usr/lib/x86_64-linux-gnu/mariadb19/plugin/ plugin_maturity gamma port 3306 preload_buffer_size 32768 profiling OFF profiling_history_size 15 progress_report_time 5 protocol_version 10 proxy_protocol_networks proxy_user pseudo_slave_mode OFF pseudo_thread_id 10804 query_alloc_block_size 16384 query_cache_limit 1048576 query_cache_min_res_unit 4096 query_cache_size 16777216 query_cache_strip_comments OFF query_cache_type ON query_cache_wlock_invalidate OFF query_prealloc_size 24576 rand_seed1 27429069 rand_seed2 533006049 range_alloc_block_size 4096 read_binlog_speed_limit 0 read_buffer_size 131072 read_only OFF read_rnd_buffer_size 262144 relay_log relay_log_basename relay_log_index relay_log_info_file relay-log.info relay_log_purge ON relay_log_recovery OFF relay_log_space_limit 0 replicate_annotate_row_events ON replicate_do_db replicate_do_table replicate_events_marked_for_skip REPLICATE replicate_ignore_db replicate_ignore_table replicate_wild_do_table replicate_wild_ignore_table report_host report_password report_port 3306 report_user rowid_merge_buff_size 8388608 rpl_semi_sync_master_enabled OFF rpl_semi_sync_master_timeout 10000 rpl_semi_sync_master_trace_level 32 rpl_semi_sync_master_wait_no_slave ON rpl_semi_sync_master_wait_point AFTER_COMMIT rpl_semi_sync_slave_delay_master OFF rpl_semi_sync_slave_enabled OFF rpl_semi_sync_slave_kill_conn_timeout 5 rpl_semi_sync_slave_trace_level 32 secure_auth ON secure_file_priv secure_timestamp NO server_id 1 session_track_schema ON session_track_state_change OFF session_track_system_variables autocommit,character_set_client,character_set_connection,character_set_resul ts,time_zone session_track_transaction_info OFF skip_external_locking ON skip_name_resolve OFF skip_networking OFF skip_parallel_replication OFF skip_replication OFF skip_show_database OFF slave_compressed_protocol OFF slave_ddl_exec_mode IDEMPOTENT slave_domain_parallel_threads 0 slave_exec_mode STRICT slave_load_tmpdir /tmp slave_max_allowed_packet 1073741824 slave_net_timeout 60 slave_parallel_max_queued 131072 slave_parallel_mode conservative slave_parallel_threads 0 slave_parallel_workers 0 slave_run_triggers_for_rbr NO slave_skip_errors OFF slave_sql_verify_checksum ON slave_transaction_retries 10 slave_transaction_retry_errors 1213,1205 slave_transaction_retry_interval 0 slave_type_conversions slow_launch_time 2 slow_query_log OFF slow_query_log_file exchange64-slow.log socket /run/mysqld/mysqld.sock sort_buffer_size 2097152 sql_auto_is_null OFF sql_big_selects ON sql_buffer_result OFF sql_log_bin ON sql_log_off OFF sql_mode STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE _SUBSTITUTION sql_notes ON sql_quote_show_create ON sql_safe_updates OFF sql_select_limit 18446744073709551615 sql_slave_skip_counter 0 sql_warnings OFF ssl_ca ssl_capath ssl_cert ssl_cipher ssl_crl ssl_crlpath ssl_key standard_compliant_cte ON storage_engine InnoDB stored_program_cache 256 strict_password_validation ON sync_binlog 0 sync_frm ON sync_master_info 10000 sync_relay_log 10000 sync_relay_log_info 10000 system_time_zone CEST system_versioning_alter_history ERROR system_versioning_asof DEFAULT table_definition_cache 400 table_open_cache 1000 table_open_cache_instances 8 tcp_keepalive_interval 0 tcp_keepalive_probes 0 tcp_keepalive_time 0 thread_cache_size 151 thread_concurrency 10 thread_handling one-thread-per-connection thread_pool_idle_timeout 60 thread_pool_max_threads 65536 thread_pool_oversubscribe 3 thread_pool_prio_kickup_timer 1000 thread_pool_priority auto thread_pool_size 4 thread_pool_stall_limit 500 thread_stack 299008 time_format %H:%i:%s time_zone SYSTEM timed_mutexes OFF timestamp 1618208688.935216 tmp_disk_table_size 18446744073709551615 tmp_memory_table_size 16777216 tmp_table_size 16777216 tmpdir /tmp transaction_alloc_block_size 8192 transaction_prealloc_size 4096 tx_isolation REPEATABLE-READ tx_read_only OFF unique_checks ON updatable_views_with_limit YES use_stat_tables NEVER userstat OFF version 10.3.27-MariaDB-0+deb10u1 version_comment Debian 10 version_compile_machine x86_64 version_compile_os debian-linux-gnu version_malloc_library system version_source_revision dba846ce2a4c57363c4f0256b0e6d2dd1a55ac40 version_ssl_library YaSSL 2.4.4 wait_timeout 28800 warning_count 0 wsrep_osu_method TOI wsrep_auto_increment_control ON wsrep_causal_reads OFF wsrep_certification_rules strict wsrep_certify_nonpk ON wsrep_cluster_address wsrep_cluster_name my_wsrep_cluster wsrep_convert_lock_to_trx OFF wsrep_data_home_dir /var/lib/mysql/ wsrep_dbug_option wsrep_debug OFF wsrep_desync OFF wsrep_dirty_reads OFF wsrep_drupal_282555_workaround OFF wsrep_forced_binlog_format NONE wsrep_gtid_domain_id 0 wsrep_gtid_mode OFF wsrep_load_data_splitting ON wsrep_log_conflicts OFF wsrep_max_ws_rows 0 wsrep_max_ws_size 2147483647 wsrep_mysql_replication_bundle 0 wsrep_node_address wsrep_node_incoming_address AUTO wsrep_node_name exchange64 wsrep_notify_cmd wsrep_on OFF wsrep_patch_version wsrep_25.24 wsrep_provider none wsrep_provider_options wsrep_recover OFF wsrep_reject_queries NONE wsrep_replicate_myisam OFF wsrep_restart_slave OFF wsrep_retry_autocommit 1 wsrep_slave_fk_checks ON wsrep_slave_uk_checks OFF wsrep_slave_threads 1 wsrep_sst_auth wsrep_sst_donor wsrep_sst_donor_rejects_queries OFF wsrep_sst_method rsync wsrep_sst_receive_address AUTO wsrep_start_position 00000000-0000-0000-0000-000000000000:-1 wsrep_sync_wait 0 Can somebody please give me an advice what I made wrong to limit the memory usage of MariaDB to 2 GB? Thank you very much! Sig

2 1

[Maria-discuss] MEMORY tables and binlog
by Dajka Tamás 07 Apr '21

07 Apr '21

Hi All, I'm facing a weird error. We're migrating our old 10.1 multi-master setup to a new 10.3 cluster (everything is running on Debian). New-node01 is connected as a slave to the old cluster's master. When I tried to set up the replication between the 2 new nodes (with data files copy), the slave thread stopped nearly immediatelly stating, that the command is invalid - containing illegal characters. After some investigation, it turned out, that binlog on the master (new-node01) is - let's say - corrupted. After a few iterations/checking I saw, that the error always happens with some MEMORY tables (I know I can exclude them from the replica, but want to understand the issue first). new-node01/02 running 10.3.27-MariaDB-0+deb10u1-log on latest Debian 10.9 (replication from old-node is OK), replication is GTID based. HW is a new HP Gen10 DL380. When checking the binlog on the new-node01 with mysqlbinlog, I get the following: # at 2361 #210407 11:13:34 server id 4 end_log_pos 2403 CRC32 0x90080d27 GTID 100-4-37336878143 trans /*!100001 SET @@session.gtid_seq_no=37336878143*//*!*/; START TRANSACTION /*!*/; # at 2403 #210407 11:13:34 server id 4 end_log_pos 2527 CRC32 0x27183d2f Query thread_id=341297541 exec_time=318 error_code=0 SET TIMESTAMP=1617786814/*!*/; DELETE FROM `mydb1`.`collect_output`e<FB>#<98> /*!*/; # at 2527 #210407 11:13:34 server id 4 end_log_pos 2598 CRC32 0x427f0ed7 Table_map: `mydb1`.`collect_output` mapped to number 1330 Please notice the illegal chars at the end of the "DELETE FROM" line. (DELETE FROM is normal, since new-node01 is starting up from shutdown and mydb1.collect_output is a MEMORY table -> will delete the contents, so that the replications slaves have the same data). Is this a bug or a known issue? Is there any other way to solve this, than exclude the MEMORY tables from the replication? Thanks, Tom

5 7

[Maria-discuss] ODBC picking nearby connections?
by Antony Stone 07 Apr '21

07 Apr '21

Hi. I have the following setup: Two data centres which I shall label North and South for the following explanation. Four virtual machines, Whiskey and Xray in data centre North, and Yankee and Zulu in data centre South, which have the Debian package unixodbc installed, together with libmaodbc. Four other virtual machines, Alfa and Bravo in North and Charlie and Delta in South, all running MariaDB with Galera replication. A single hostname DB.example.com which resolves to the four IP addresses of the four database servers Alfa, Bravo, Charlie and Delta. Every instance of /etc/odbc.ini on machines Whiskey, Xray, Yankee and Zulu has the setting "SERVER=DB.example.com" in it. When I start an application which uses ODBC (in my case this is Asterisk), I find that each application server manages to connect to a database server in its own data centre. Given a 50% chance of this happening for machine Whiskey, a 50% chance for machine Xray, etc., this comes out as a 1 in 16 combined probability of happening by chance. Therefore I think it is not by chance :) I've done some packet captures, and I see each machine Whiskey, Xray, Yankee and Zulu doing a single DNS query for DB.example.com and getting the four IP addresses of Alfa, Bravo, Chalie and Delta returned. As expected, the order the addresses is returned in is randomised for different queries. Each machine then makes a single connection to MariaDB on port 3306 on one of the IP addresses in the list. This address can be the first in the list returned from the DNS resolver, or it can the the last one, or it can be on in the middle. There is no attempt to ping the four addresses and compare round-trip times, or to connect to MariaDB on more than one server and measure the query response times. Each applicaton server connects to one database server, and they always manage to connect to a machine in their own data centre. My question is: how do they do this? How does machine Whiskey manage to select one of the two IP addresses for database servers Alfa and Bravo, and connect to it, ignoring the addresses for Charlie and Delta? If I can supply any further information to help with answering this question, please let me know. Thanks, Antony. -- "Have you been drinking brake fluid again? I think you're addicted to the stuff." "No, no, it's alright - I can stop any time I want to." Please reply to the list; please *don't* CC me.

1 0

[Maria-discuss] Galera with TLS not happy.
by lejeczek 30 Mar '21

30 Mar '21

Hi guys. I'm trying to add encryption to my already working galera cluster and I've look at number of tutorials, official ones included. I've added these to configs: [mariadb] ssl_cert = /etc/my.cnf.d/certs/c8kubernode2.private.pawel.crt ssl_key = /etc/my.cnf.d/certs/c8kubernode2.private.pawel.key ssl_ca = /etc/my.cnf.d/certs/ca.crt [mysqld] wsrep_provider_options="socket.ssl=yes;socket.ssl_cert=/etc/my.cnf.d/certs/c8kubernode2.private.pawel.crt;socket.ssl_key=/etc/my.cnf.d/certs/c8kubernode2.private.pawel.key;socket.ssl_ca=/etc/my.cnf.d/certs/ca.crt" First server, above configs, starts okey with 'galera_new_cluster' but the second, I'm on Centos 8, when started as normal with systemd shows: ... 2021-03-29 17:33:34 0 [ERROR] WSREP: gcomm/src/asio_tcp.cpp:handshake_handler():128: handshake with remote endpoint ssl://10.1.1.223:4567 failed: asio.ssl:337047686: 'certificate verify failed' ( 337047686: 'error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed') 2021-03-29 17:33:36 0 [ERROR] WSREP: gcomm/src/asio_tcp.cpp:handshake_handler():128: handshake with remote endpoint ssl://10.1.1.223:4567 failed: asio.ssl:337047686: 'certificate verify failed' ( 337047686: 'error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed') ... and eventually after a moment fails. The second server has the same bits in configs only, naturally, files names are different respectively. I also see this, in case might tell more or be relevant, this is on 'galera_new_cluster' up & running: -> $ mysql --ssl -h c8kubernode2.private.pawel -u wordpress -p --ssl-verify-server-cert=true Enter password: ERROR 2026 (HY000): SSL connection error: self signed certificate in certificate chain -> $ mysql --ssl -h c8kubernode2.private.pawel -u wordpress -p --ssl-verify-server-cert=false Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. But if this is 'CN' problem then looking at the mysql server cert: -> $ _my._sslPrintCert.sh c8kubernode2.private.pawel.crt issuer=CN = "nodemaster.private.pawel," # <= here, it matches server's hostname as expected. subject=CN = c8kubernode2.private.pawel notAfter=Jul 2 20:50:57 2023 GMT Certificate: ... Also, in case it might matter, I do not have as you can see [sst] bits done yet. Any ideas someone cares to share I'll appreciate. many thanks, L.

1 0

[Maria-discuss] Introduction and Task Suggestion
by Hemant Kumar Singh 22 Mar '21

22 Mar '21

Hi everyone, I am Hemant from Nepal, currently a Computer Science Junior at NIT Warangal, India willing to take part in GSoC 2021. I saw a major priority task "MDEV-13648- Add FULL OUTER JOIN to MariaDB (https://link.getmailspring.com/link/F02B618E-9401-406B-BD92-A573A39AD858@ge…)" unresolved since gsoc 2019; but it's not listed in 2021 List of Ideas. So, I was just wondering whether I can contribute to this task for gsoc 2021. Can anyone confirm this? Regards, Hemant Kumar Singh https://iamhks.com (https://link.getmailspring.com/link/F02B618E-9401-406B-BD92-A573A39AD858@ge…)

3 3

[Maria-discuss] Is it possible to upgrade SHA-1 and MD5 algorithms in Mariadb-10.5?
by Lukas Javorsky 22 Mar '21

22 Mar '21

Hi, In RHEL-9 we are deprecating, old SHA-1 and MD5 and that's why I want to ask you if there is any chance that upstream is going to change it, or we should do it downstream. These algorithms are no longer considered as safe, so it may be a good thing to upgrade them. AFAIK mariadb uses these algorithms in *mariadb* and *mariadb-connector-c.* Also if you have no intention to change it, is there any chance you could help us somehow. Maybe point out what we should be aware of. Please let me know what you think Lukas -- S pozdravom/ Best regards Lukáš Javorský Associate Software Engineer, Core service - Databases Red Hat <https://www.redhat.com> Purkyňova 115 (TPB-C) 612 00 Brno - Královo Pole ljavorsk(a)redhat.com <https://www.redhat.com>

5 8

[Maria-discuss] Why does MariaDB needs SELinux capability for setuid/setgid?
by Lukas Javorsky 16 Mar '21

16 Mar '21

Hi guys, I'm looking into SELinux in Fedora's MariaDB package and I can see that we have two types in MariaDB that have setuid/setgid capability. 1st: https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/module… 2nd: https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/module… My question is, does mysqld_t need to have this capability? I found that setuid/setgid is used inside mysqld_safe_helper (mariadbd-safe-helper). Are there any other cases when MariaDB uses these functions? Thank you for letting me know Lukas -- S pozdravom/ Best regards Lukáš Javorský Associate Software Engineer, Core service - Databases Red Hat <https://www.redhat.com> Purkyňova 115 (TPB-C) 612 00 Brno - Královo Pole ljavorsk(a)redhat.com <https://www.redhat.com>

3 5

[Maria-discuss] Problem with InnoDB: Semaphore wait after upgrading to 10.3.27
by Conor Murphy 16 Mar '21

16 Mar '21

Hi, We have a handful of servers running MariaDB 10.3. We noticed issues on two of them where we were getting issues like "InnoDB: A long semaphore wait:--Thread 140602802394880 has waited at dict0stats.cc line 1969 for 241.00 seconds the semaphore:" and crashes like "ERROR] [FATAL] InnoDB: Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.210215 7:14:24 [ERROR] mysqld got signal 6 ;" Turned out that these two servers were running 10.3.27 whereas the others were running 10.3.17. After downgrading the two problem servers to 10.3.17, all the issues with InnoDB semaphores stopped. Any ideas on how to track down what change between 10.3.17 to 10.3.27 might be causing this problem? Thanks, Conor

3 4

[Maria-discuss] RocksDB doubt
by Roberto Spadim 04 Mar '21

04 Mar '21

Hi folks! Could be possible write/read from rocksdb and at the same machine have a mariadb+myrocksdb running? -- Roberto Spadim

1 0

[Maria-discuss] GTID and missing domain
by mariadb＠Biblestuph.com 27 Feb '21

27 Feb '21

Greetings, I've had this issue before and never quite got to the bottom of it. It keeps biting me and I'm hoping I can figure out how to definitively solve it. In brief, my replica server has this for gtid_slave_pos: 0-303-67739600,1-303-7360639083,100-303-4337869 And my primary server has: gtid_binlog_pos 0-303-67739600,1-303-7363061243,100-303-4338582 gtid_binlog_state 0-302-67690294,0-301-67719794,0-303-67739600,1-301-7350472534,1-302-7350381758,1-303-7363061243,100-302-4242958,100-301-4332195,100-303-4338582 That's all well and good and I can connect that way. But if I do this on the replica server: stop slave; select @@global.gtid_slave_pos; 0-303-67739600,1-303-7360639083,100-303-4337869 set global gtid_slave_pos = '1-303-7360639083,100-303-4337869'; start slave; I get: Got fatal error 1236 from master when reading data from binary log: 'Could not find GTID state requested by slave in any binlog files. Probably the slave state is too old and required binlog files have been purged. Even though I'm positive there are no domain 0 transactions (again, hasn't been in service for years). If I add the `0-303-67739600` back in to gtid_slave_pos I can reconnect. At this point, I have only one server of a four server chain that I can actually connect to with gtid (as above). So I'm a little reluctant to do too much experimenting. But just to ask the question, if I: FLUSH BINARY LOGS DELETE_DOMAIN_ID=(0) on the master, would I then be able to connect to it via set global gtid_slave_pos = '1-303-7360639083,100-303-4337869'; from the replica? At this point, I cannot connect any of my other servers (which currently are all replicating from the same master) to each other, even the ones that don't show the 0- domain in the gtid-binlog vars. I'm hoping if I can figure out the above scenario it might help me deal with the rest, but I just keep feeling like I'm missing something. TIA, Dan

2 2

[Maria-discuss] Odd errors with TIMESTAMP columns
by David Buckley 26 Feb '21

26 Feb '21

Hello, I hope this is the correct list for this sort of question, apologies if not. I am working on importing data from a MySQL 5.1 database into a new MariaDB database (Server version: 10.4.14-MariaDB-1:10.4.14+maria~focal-log mariadb.org binary distribution), and am having trouble with a number of values in TIMESTAMP columns. For example: MariaDB [x]> create table y ( z timestamp ); MariaDB [x]> insert into y values ('2016-03-13 02:05:32'); ERROR 1292 (22007): Incorrect datetime value: '2016-03-13 02:05:32' for column `x`.`y`.`z` at row 1 MariaDB [x]> insert into y values ('2016-03-13 03:05:32'); Query OK, 1 row affected (0.091 sec) I have tried turning off mysql56_temporal_format but that doesn't seem to change anything. As far as I can tell the values should be valid, in the above example simply changing the hour from 2 to 3 allowed the insert to succeed. But I am at a loss as to why '2016-03-13 02:05:32' is not a valid value. There are a few hundred rows at least affected by this, with many different values. Any ideas as to what could be causing this? Or ways to resolve it? Thanks, -David

3 2

[Maria-discuss] Maximum possible memory usage: 123.3G
by Reindl Harald 19 Feb '21

19 Feb '21

hmmmm - i thought i had the per-thread buffers down to a value which would be reasonable in case the max number of connections is reached i guess that two are guilty but with low "myisam_sort_buffer_size" optimize large tables fail from my expierience and a small "join_buffer_size" don't work well too are these *really* allocated unconditional per-threaf or only in case it's needed? myisam_sort_buffer_size = 15M join_buffer_size = 1M ----------------------------------------------- [--] Up for: 19h 10m 52s (174K q [2.520 qps], 688 conn, TX: 65M, RX: 11M) [--] Reads / Writes: 69% / 31% [--] Binary logging is enabled (GTID MODE: ON) [--] Physical Memory : 31.2G [--] Max MySQL memory : 123.3G [--] Other process memory: 0B [--] Total buffers: 450.0M global + 251.7M per thread (500 max threads) [--] P_S Max memory usage: 0B [--] Galera GCache Max memory usage: 0B [OK] Maximum reached memory usage: 4.9G (15.57% of installed RAM) [!!] Maximum possible memory usage: 123.3G (394.87% of installed RAM) [!!] Overall possible memory usage with other process exceeded memory ----------------------------------------------- max_allowed_packet = 250M max_tmp_tables = 100 max_connect_errors = 500 max_delayed_threads = 30 max_connections = 500 back_log = 1000 query_cache_limit = 512K query_cache_min_res_unit = 1024 query_cache_size = 32M query_cache_type = 1 table_cache = 5000 table_definition_cache = 512 thread_cache_size = 100 tmp_table_size = 256M max_heap_table_size = 256M key_buffer_size = 32M sort_buffer_size = 128K myisam_sort_buffer_size = 15M join_buffer_size = 1M preload_buffer_size = 128K read_buffer_size = 128K read_rnd_buffer_size = 128K innodb_buffer_pool_size = 96M innodb-defragment = 1 innodb_buffer_pool_dump_at_shutdown = 0 innodb_buffer_pool_instances = 1 innodb_checksum_algorithm = NONE innodb_doublewrite = 1 innodb_file_per_table = 1 innodb_flush_log_at_trx_commit = 2 innodb_flush_method = O_DIRECT innodb_io_capacity = 1000 innodb_lock_wait_timeout = 50 innodb_log_buffer_size = 2M innodb_log_file_size = 32M innodb_max_dirty_pages_pct = 60 innodb_max_purge_lag = 200000 innodb_open_files = 300 innodb_page_cleaners = 1 innodb_purge_threads = 1 innodb_read_io_threads = 4 innodb_stats_on_metadata = 0 innodb_strict_mode = 1 innodb_table_locks = 0 innodb_thread_concurrency = 0 innodb_thread_sleep_delay = 10 innodb_write_io_threads = 4 transaction-isolation = READ-COMMITTED server-id = 1 expire_logs_days = 21 max_binlog_size = 256M binlog-format = ROW binlog_stmt_cache_size = 256K binlog_cache_size = 256K sync_binlog = 30 log_bin_compress = 1 binlog-ignore-db = autotest replicate-ignore-db = autotest low-priority-updates skip-symbolic-links skip-name-resolve safe-user-create [mariadb] aria_pagecache_buffer_size = 32m aria_sort_buffer_size = 32m aria_page_checksum = 0 key_cache_segments = 8 thread_handling = pool-of-threads thread_pool_idle_timeout = 900 ----------------------------------------------- MariaDB [(none)]> show variables where variable_name!='optimizer_switch' and variable_name!='log_slow_filter' and variable_name!='session_track_system_variables' and variable_name not like '%ssl%' and variable_name!='version_source_revision' and variable_name not like 'log_bin%' and value not like '/var/log%' and value not like '%/data/%' and value not like '/var/%' and value not like '/usr%'; +---------------------------------------------+------------------------+ | Variable_name | Value | +---------------------------------------------+------------------------+ | alter_algorithm | DEFAULT | | aria_block_size | 8192 | | aria_checkpoint_interval | 30 | | aria_checkpoint_log_activity | 1048576 | | aria_encrypt_tables | OFF | | aria_force_start_after_recovery_failures | 0 | | aria_group_commit | none | | aria_group_commit_interval | 0 | | aria_log_file_size | 1073741824 | | aria_log_purge_type | immediate | | aria_max_sort_file_size | 9223372036853727232 | | aria_page_checksum | OFF | | aria_pagecache_age_threshold | 300 | | aria_pagecache_buffer_size | 33554432 | | aria_pagecache_division_limit | 100 | | aria_pagecache_file_hash_size | 512 | | aria_recover_options | BACKUP,QUICK | | aria_repair_threads | 1 | | aria_sort_buffer_size | 33554432 | | aria_stats_method | nulls_unequal | | aria_sync_log_dir | NEWFILE | | aria_used_for_temp_tables | ON | | auto_increment_increment | 1 | | auto_increment_offset | 1 | | autocommit | ON | | automatic_sp_privileges | ON | | back_log | 1000 | | big_tables | OFF | | bind_address | | | binlog_annotate_row_events | ON | | binlog_cache_size | 262144 | | binlog_checksum | CRC32 | | binlog_commit_wait_count | 0 | | binlog_commit_wait_usec | 100000 | | binlog_direct_non_transactional_updates | OFF | | binlog_file_cache_size | 16384 | | binlog_format | ROW | | binlog_optimize_thread_scheduling | ON | | binlog_row_image | FULL | | binlog_stmt_cache_size | 262144 | | bulk_insert_buffer_size | 8388608 | | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | latin1 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | latin1 | | character_set_system | utf8 | | check_constraint_checks | ON | | collation_connection | utf8_general_ci | | collation_database | latin1_german1_ci | | collation_server | latin1_german1_ci | | column_compression_threshold | 100 | | column_compression_zlib_level | 6 | | column_compression_zlib_strategy | DEFAULT_STRATEGY | | column_compression_zlib_wrap | OFF | | completion_type | NO_CHAIN | | concurrent_insert | ALWAYS | | connect_timeout | 10 | | core_file | OFF | | date_format | %Y-%m-%d | | datetime_format | %Y-%m-%d %H:%i:%s | | deadlock_search_depth_long | 15 | | deadlock_search_depth_short | 4 | | deadlock_timeout_long | 50000000 | | deadlock_timeout_short | 10000 | | debug_no_thread_alarm | OFF | | default_master_connection | | | default_regex_flags | | | default_storage_engine | MyISAM | | default_tmp_storage_engine | | | default_week_format | 0 | | delay_key_write | ALL | | delayed_insert_limit | 100 | | delayed_insert_timeout | 300 | | delayed_queue_size | 1000 | | div_precision_increment | 4 | | encrypt_binlog | OFF | | encrypt_tmp_disk_tables | OFF | | encrypt_tmp_files | OFF | | enforce_storage_engine | | | eq_range_index_dive_limit | 0 | | error_count | 0 | | event_scheduler | OFF | | expensive_subquery_limit | 100 | | expire_logs_days | 21 | | explicit_defaults_for_timestamp | OFF | | external_user | | | extra_max_connections | 1 | | extra_port | 0 | | flush | OFF | | flush_time | 0 | | foreign_key_checks | ON | | ft_boolean_syntax | + -><()~*:""&| | | ft_max_word_len | 84 | | ft_min_word_len | 4 | | ft_query_expansion_limit | 20 | | ft_stopword_file | (built-in) | | general_log | OFF | | group_concat_max_len | 1048576 | | gtid_binlog_pos | 0-1-2075216 | | gtid_binlog_state | 0-1-2075216 | | gtid_current_pos | 0-1-2075216 | | gtid_domain_id | 0 | | gtid_ignore_duplicates | OFF | | gtid_pos_auto_engines | | | gtid_seq_no | 0 | | gtid_slave_pos | | | gtid_strict_mode | OFF | | have_compress | YES | | have_crypt | YES | | have_dynamic_loading | YES | | have_geometry | YES | | have_profiling | NO | | have_query_cache | YES | | have_rtree_keys | YES | | have_symlink | DISABLED | | histogram_size | 0 | | histogram_type | SINGLE_PREC_HB | | host_cache_size | 628 | | hostname | srv-rhsoft.rhsoft.net | | identity | 0 | | idle_readonly_transaction_timeout | 0 | | idle_transaction_timeout | 0 | | idle_write_transaction_timeout | 0 | | ignore_builtin_innodb | OFF | | ignore_db_dirs | | | in_predicate_conversion_threshold | 1000 | | in_transaction | 0 | | init_connect | | | init_file | | | init_slave | | | innodb_adaptive_flushing | ON | | innodb_adaptive_flushing_lwm | 10.000000 | | innodb_adaptive_hash_index | ON | | innodb_adaptive_hash_index_parts | 8 | | innodb_adaptive_max_sleep_delay | 150000 | | innodb_autoextend_increment | 64 | | innodb_autoinc_lock_mode | 1 | | innodb_background_scrub_data_check_interval | 3600 | | innodb_background_scrub_data_compressed | OFF | | innodb_background_scrub_data_interval | 604800 | | innodb_background_scrub_data_uncompressed | OFF | | innodb_buf_dump_status_frequency | 0 | | innodb_buffer_pool_chunk_size | 100663296 | | innodb_buffer_pool_dump_at_shutdown | OFF | | innodb_buffer_pool_dump_now | OFF | | innodb_buffer_pool_dump_pct | 25 | | innodb_buffer_pool_filename | ib_buffer_pool | | innodb_buffer_pool_instances | 1 | | innodb_buffer_pool_load_abort | OFF | | innodb_buffer_pool_load_at_startup | ON | | innodb_buffer_pool_load_now | OFF | | innodb_buffer_pool_size | 100663296 | | innodb_change_buffer_max_size | 25 | | innodb_change_buffering | all | | innodb_checksum_algorithm | none | | innodb_checksums | ON | | innodb_cmp_per_index_enabled | OFF | | innodb_commit_concurrency | 0 | | innodb_compression_algorithm | zlib | | innodb_compression_default | OFF | | innodb_compression_failure_threshold_pct | 5 | | innodb_compression_level | 6 | | innodb_compression_pad_pct_max | 50 | | innodb_concurrency_tickets | 5000 | | innodb_data_file_path | ibdata1:12M:autoextend | | innodb_data_home_dir | | | innodb_deadlock_detect | ON | | innodb_default_encryption_key_id | 1 | | innodb_default_row_format | dynamic | | innodb_defragment | ON | | innodb_defragment_fill_factor | 0.900000 | | innodb_defragment_fill_factor_n_recs | 20 | | innodb_defragment_frequency | 40 | | innodb_defragment_n_pages | 7 | | innodb_defragment_stats_accuracy | 0 | | innodb_disable_sort_file_cache | OFF | | innodb_doublewrite | ON | | innodb_encrypt_log | OFF | | innodb_encrypt_tables | OFF | | innodb_encrypt_temporary_tables | OFF | | innodb_encryption_rotate_key_age | 1 | | innodb_encryption_rotation_iops | 100 | | innodb_encryption_threads | 0 | | innodb_fast_shutdown | 1 | | innodb_fatal_semaphore_wait_threshold | 600 | | innodb_file_format | | | innodb_file_per_table | ON | | innodb_fill_factor | 100 | | innodb_flush_log_at_timeout | 1 | | innodb_flush_log_at_trx_commit | 2 | | innodb_flush_method | O_DIRECT | | innodb_flush_neighbors | 1 | | innodb_flush_sync | ON | | innodb_flushing_avg_loops | 30 | | innodb_force_load_corrupted | OFF | | innodb_force_primary_key | OFF | | innodb_force_recovery | 0 | | innodb_ft_aux_table | | | innodb_ft_cache_size | 8000000 | | innodb_ft_enable_diag_print | OFF | | innodb_ft_enable_stopword | ON | | innodb_ft_max_token_size | 84 | | innodb_ft_min_token_size | 3 | | innodb_ft_num_word_optimize | 2000 | | innodb_ft_result_cache_limit | 2000000000 | | innodb_ft_server_stopword_table | | | innodb_ft_sort_pll_degree | 2 | | innodb_ft_total_cache_size | 640000000 | | innodb_ft_user_stopword_table | | | innodb_idle_flush_pct | 100 | | innodb_immediate_scrub_data_uncompressed | OFF | | innodb_instant_alter_column_allowed | add_last | | innodb_io_capacity | 1000 | | innodb_io_capacity_max | 2000 | | innodb_large_prefix | | | innodb_lock_schedule_algorithm | fcfs | | innodb_lock_wait_timeout | 50 | | innodb_locks_unsafe_for_binlog | OFF | | innodb_log_buffer_size | 2097152 | | innodb_log_checksums | ON | | innodb_log_compressed_pages | ON | | innodb_log_file_size | 33554432 | | innodb_log_files_in_group | 2 | | innodb_log_group_home_dir | ./ | | innodb_log_optimize_ddl | OFF | | innodb_log_write_ahead_size | 8192 | | innodb_lru_scan_depth | 1024 | | innodb_max_dirty_pages_pct | 60.000000 | | innodb_max_dirty_pages_pct_lwm | 0.000000 | | innodb_max_purge_lag | 200000 | | innodb_max_purge_lag_delay | 0 | | innodb_max_purge_lag_wait | 4294967295 | | innodb_max_undo_log_size | 10485760 | | innodb_monitor_disable | | | innodb_monitor_enable | | | innodb_monitor_reset | | | innodb_monitor_reset_all | | | innodb_old_blocks_pct | 37 | | innodb_old_blocks_time | 1000 | | innodb_online_alter_log_max_size | 134217728 | | innodb_open_files | 300 | | innodb_optimize_fulltext_only | OFF | | innodb_page_cleaners | 1 | | innodb_page_size | 16384 | | innodb_prefix_index_cluster_optimization | OFF | | innodb_print_all_deadlocks | OFF | | innodb_purge_batch_size | 300 | | innodb_purge_rseg_truncate_frequency | 128 | | innodb_purge_threads | 1 | | innodb_random_read_ahead | OFF | | innodb_read_ahead_threshold | 56 | | innodb_read_io_threads | 4 | | innodb_read_only | OFF | | innodb_replication_delay | 0 | | innodb_rollback_on_timeout | OFF | | innodb_rollback_segments | 128 | | innodb_scrub_log | OFF | | innodb_scrub_log_speed | 256 | | innodb_sort_buffer_size | 1048576 | | innodb_spin_wait_delay | 4 | | innodb_stats_auto_recalc | ON | | innodb_stats_include_delete_marked | OFF | | innodb_stats_method | nulls_equal | | innodb_stats_modified_counter | 0 | | innodb_stats_on_metadata | OFF | | innodb_stats_persistent | ON | | innodb_stats_persistent_sample_pages | 20 | | innodb_stats_sample_pages | 8 | | innodb_stats_traditional | ON | | innodb_stats_transient_sample_pages | 8 | | innodb_status_output | OFF | | innodb_status_output_locks | OFF | | innodb_strict_mode | ON | | innodb_sync_array_size | 1 | | innodb_sync_spin_loops | 30 | | innodb_table_locks | OFF | | innodb_temp_data_file_path | ibtmp1:12M:autoextend | | innodb_thread_concurrency | 0 | | innodb_thread_sleep_delay | 10 | | innodb_tmpdir | | | innodb_undo_directory | ./ | | innodb_undo_log_truncate | OFF | | innodb_undo_logs | 128 | | innodb_undo_tablespaces | 0 | | innodb_use_atomic_writes | ON | | innodb_use_native_aio | ON | | innodb_version | 10.3.26 | | innodb_write_io_threads | 4 | | insert_id | 0 | | interactive_timeout | 86400 | | join_buffer_size | 1048576 | | join_buffer_space_limit | 2097152 | | join_cache_level | 2 | | keep_files_on_create | OFF | | key_buffer_size | 33554432 | | key_cache_age_threshold | 300 | | key_cache_block_size | 1024 | | key_cache_division_limit | 100 | | key_cache_file_hash_size | 512 | | key_cache_segments | 8 | | large_files_support | ON | | large_page_size | 0 | | large_pages | OFF | | last_gtid | | | last_insert_id | 0 | | lc_messages | en_US | | lc_messages_dir | | | lc_time_names | en_US | | license | GPL | | local_infile | OFF | | lock_wait_timeout | 86400 | | locked_in_memory | OFF | | log_disabled_statements | sp | | log_output | FILE | | log_queries_not_using_indexes | OFF | | log_slave_updates | OFF | | log_slow_admin_statements | ON | | log_slow_disabled_statements | sp | | log_slow_rate_limit | 1 | | log_slow_slave_statements | ON | | log_slow_verbosity | | | log_tc_size | 24576 | | log_warnings | 1 | | long_query_time | 1.000000 | | low_priority_updates | ON | | lower_case_file_system | OFF | | lower_case_table_names | 1 | | master_verify_checksum | OFF | | max_allowed_packet | 262144000 | | max_binlog_cache_size | 18446744073709547520 | | max_binlog_size | 268435456 | | max_binlog_stmt_cache_size | 18446744073709547520 | | max_connect_errors | 500 | | max_connections | 500 | | max_delayed_threads | 30 | | max_digest_length | 1024 | | max_error_count | 64 | | max_heap_table_size | 268435456 | | max_insert_delayed_threads | 30 | | max_join_size | 18446744073709551615 | | max_length_for_sort_data | 1024 | | max_long_data_size | 262144000 | | max_prepared_stmt_count | 16382 | | max_recursive_iterations | 4294967295 | | max_relay_log_size | 268435456 | | max_seeks_for_key | 4294967295 | | max_session_mem_used | 9223372036854775807 | | max_sort_length | 1024 | | max_sp_recursion_depth | 0 | | max_statement_time | 0.000000 | | max_tmp_tables | 100 | | max_user_connections | 0 | | max_write_lock_count | 4294967295 | | metadata_locks_cache_size | 1024 | | metadata_locks_hash_instances | 8 | | min_examined_row_limit | 0 | | mrr_buffer_size | 262144 | | multi_range_count | 256 | | myisam_block_size | 1024 | | myisam_data_pointer_size | 6 | | myisam_max_sort_file_size | 9223372036853727232 | | myisam_mmap_size | 18446744073709551615 | | myisam_recover_options | FORCE | | myisam_repair_threads | 1 | | myisam_sort_buffer_size | 15728640 | | myisam_stats_method | NULLS_UNEQUAL | | myisam_use_mmap | ON | | mysql56_temporal_format | ON | | net_buffer_length | 16384 | | net_read_timeout | 30 | | net_retry_count | 10 | | net_write_timeout | 60 | | old | OFF | | old_alter_table | DEFAULT | | old_mode | | | old_passwords | OFF | | open_files_limit | 500000 | | optimizer_prune_level | 1 | | optimizer_search_depth | 62 | | optimizer_selectivity_sampling_limit | 100 | | optimizer_use_condition_selectivity | 1 | | pid_file | /dev/null | | plugin_maturity | gamma | | port | 3306 | | preload_buffer_size | 131072 | | progress_report_time | 5 | | protocol_version | 10 | | proxy_protocol_networks | | | proxy_user | | | pseudo_slave_mode | OFF | | pseudo_thread_id | 727 | | query_alloc_block_size | 16384 | | query_cache_limit | 524288 | | query_cache_min_res_unit | 1024 | | query_cache_size | 33554432 | | query_cache_strip_comments | OFF | | query_cache_type | ON | | query_cache_wlock_invalidate | OFF | | query_prealloc_size | 24576 | | rand_seed1 | 577605648 | | rand_seed2 | 1011664119 | | range_alloc_block_size | 4096 | | read_binlog_speed_limit | 0 | | read_buffer_size | 131072 | | read_only | OFF | | read_rnd_buffer_size | 131072 | | relay_log | | | relay_log_basename | | | relay_log_index | | | relay_log_info_file | relay-log.info | | relay_log_purge | ON | | relay_log_recovery | OFF | | relay_log_space_limit | 0 | | replicate_annotate_row_events | ON | | replicate_do_db | | | replicate_do_table | | | replicate_events_marked_for_skip | REPLICATE | | replicate_ignore_db | autotest | | replicate_ignore_table | | | replicate_wild_do_table | | | replicate_wild_ignore_table | | | report_host | | | report_password | | | report_port | 3306 | | report_user | | | rowid_merge_buff_size | 8388608 | | rpl_semi_sync_master_enabled | OFF | | rpl_semi_sync_master_timeout | 10000 | | rpl_semi_sync_master_trace_level | 32 | | rpl_semi_sync_master_wait_no_slave | ON | | rpl_semi_sync_master_wait_point | AFTER_COMMIT | | rpl_semi_sync_slave_delay_master | OFF | | rpl_semi_sync_slave_enabled | OFF | | rpl_semi_sync_slave_kill_conn_timeout | 5 | | rpl_semi_sync_slave_trace_level | 32 | | secure_auth | ON | | secure_file_priv | | | secure_timestamp | NO | | server_id | 1 | | session_track_schema | ON | | session_track_state_change | OFF | | session_track_transaction_info | OFF | | skip_external_locking | ON | | skip_name_resolve | ON | | skip_networking | OFF | | skip_parallel_replication | OFF | | skip_replication | OFF | | skip_show_database | OFF | | slave_compressed_protocol | OFF | | slave_ddl_exec_mode | IDEMPOTENT | | slave_domain_parallel_threads | 0 | | slave_exec_mode | STRICT | | slave_load_tmpdir | /tmp | | slave_max_allowed_packet | 1073741824 | | slave_net_timeout | 60 | | slave_parallel_max_queued | 131072 | | slave_parallel_mode | conservative | | slave_parallel_threads | 0 | | slave_parallel_workers | 0 | | slave_run_triggers_for_rbr | NO | | slave_skip_errors | OFF | | slave_sql_verify_checksum | ON | | slave_transaction_retries | 10 | | slave_transaction_retry_errors | 1213,1205 | | slave_transaction_retry_interval | 0 | | slave_type_conversions | | | slow_launch_time | 2 | | slow_query_log | ON | | sort_buffer_size | 131072 | | sql_auto_is_null | OFF | | sql_big_selects | ON | | sql_buffer_result | OFF | | sql_log_bin | ON | | sql_log_off | OFF | | sql_mode | STRICT_ALL_TABLES | | sql_notes | ON | | sql_quote_show_create | ON | | sql_safe_updates | OFF | | sql_select_limit | 18446744073709551615 | | sql_slave_skip_counter | 0 | | sql_warnings | OFF | | standard_compliant_cte | ON | | storage_engine | MyISAM | | stored_program_cache | 256 | | strict_password_validation | ON | | sync_binlog | 30 | | sync_frm | OFF | | sync_master_info | 10000 | | sync_relay_log | 10000 | | sync_relay_log_info | 10000 | | system_time_zone | CET | | system_versioning_alter_history | ERROR | | system_versioning_asof | DEFAULT | | table_definition_cache | 512 | | table_open_cache | 5000 | | table_open_cache_instances | 8 | | tcp_keepalive_interval | 0 | | tcp_keepalive_probes | 0 | | tcp_keepalive_time | 0 | | thread_cache_size | 100 | | thread_concurrency | 10 | | thread_handling | pool-of-threads | | thread_pool_idle_timeout | 900 | | thread_pool_max_threads | 65536 | | thread_pool_oversubscribe | 3 | | thread_pool_prio_kickup_timer | 1000 | | thread_pool_priority | auto | | thread_pool_size | 8 | | thread_pool_stall_limit | 500 | | thread_stack | 299008 | | time_format | %H:%i:%s | | time_zone | Europe/Vienna | | timed_mutexes | OFF | | timestamp | 1613721594.324895 | | tmp_disk_table_size | 18446744073709551615 | | tmp_memory_table_size | 268435456 | | tmp_table_size | 268435456 | | tmpdir | /tmp | | transaction_alloc_block_size | 8192 | | transaction_prealloc_size | 4096 | | tx_isolation | READ-COMMITTED | | tx_read_only | OFF | | unique_checks | ON | | updatable_views_with_limit | YES | | use_stat_tables | NEVER | | userstat | OFF | | version | 10.3.26-MariaDB-log | | version_comment | thelounge | | version_compile_machine | x86_64 | | version_compile_os | Linux | | version_malloc_library | system | | wait_timeout | 86400 | | warning_count | 0 | +---------------------------------------------+------------------------+ 535 rows in set (0.002 sec)

2 2

[Maria-discuss] Help needed. Replication slave hangs on 'stop slave; '
by Thomas 01 Feb '21

01 Feb '21

Hello, we have upgraded our MySQL Master/Slave server vom 10.1.24 to 10.1.48 on 25.01. Backups worked as usual, but since friday (29.01.) our backups do not work anymore. I have seen that entering a 'stop slave;' on mysql cli hangs forever, while in the background (on a second console, I see the replication going on, but the gtid is far away from the master. According to MaxScale, on the slave it is '0-1-8696229561 and on the master '0-1-8705275411' and not moving forward on the slave. Slave 'show slave status': MariaDB [(none)]> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 172.16.1.1 Master_User: replication_user Master_Port: 3306 Connect_Retry: 10 Master_Log_File: mysql-bin.005595 Read_Master_Log_Pos: 581894706 Relay_Log_File: relay-bin.000002 Relay_Log_Pos: 693 Relay_Master_Log_File: mysql-bin.005587 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 967647646 Relay_Log_Space: 8205026277 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 1 Master_SSL_Crl: Master_SSL_Crlpath: Using_Gtid: Slave_Pos Gtid_IO_Pos: 0-1-8705427292 Replicate_Do_Domain_Ids: Replicate_Ignore_Domain_Ids: Parallel_Mode: optimistic 1 row in set (0.00 sec) Master status is this: MariaDB [(none)]> show master status\G *************************** 1. row *************************** File: mysql-bin.005595 Position: 581594839 Binlog_Do_DB: Binlog_Ignore_DB: 1 row in set (0.01 sec) If I try to stop the server it hangs also. Waited half an hour after I saw the backups hanging on the 'stop slave' command, then killed the server with kill -9. It restarted without complaining, but the hang is still occuring when doing a 'stop slave'. Can anybody help me diagnosing and possibly resolving this issue? Server is a baremetal with battery backed raid10. OS is Centos 7 all updated. Thanks, Thomas

2 7

[Maria-discuss] Streaming telemetry and ColumnStore - viable or not
by Richard Ellerbrock 19 Jan '21

19 Jan '21

Hi all, I am investigating the viability of using MariaDB as a datastore for streaming telemetry data sourced via gRPC. The data ingestion rate will be quite high (write once, read many with no change to the data), but the data can be buffered and bulk loaded in 10-60sec intervals. We are currently using MariaDB for OLTP purposes (Innodb) and also graphs (OQGRAPH) with no issues. My journey so far has been mainly focused on Kafka but the more I dig the more future trouble I uncover. So many components required to solve even a simple problem. Now I am investigating if using our current tooling that our team knows already will get the job done. Reading up on ColumnStore has also uncovered more gotchas and deprectations that I am comfortable with. Things that concern me are: 1. Is ColumnStore going to go the way of TokuDB? 2. The docs warn that data needs to be bulk inserted - not super ideal for streaming applications. Is streaming via cpimport viable? 3. The bulk write API's have been deprecated ( https://mariadb.com/kb/en/columnstore-bulk-write-sdk/) which then implies that streaming is not advised (Kafka connectors are thus also not viable). This slideshow talks about streaming with ColumnStore 1.1 https://www.slideshare.net/MariaDB/big-data-analytics-with-mariadb-columnst… 4. Streaming data is a combination of fixed columns and key / value pairs. How to deal with the dynamic nature of the key / value pairs (see below for sample data that was sourced via gRPC and converted to OpenTSDB format - we can convert the data into any required format, this is just one example). So some questions: What is the current recommended streaming telemetry data store solution from MariaDB, or should I rather look at a custom solution (different tooling, more skills/re-skilling required)? Is there a writeup or reference design? Any insights will be helpful. Thanks. put eos.intflagpktcounter.counter.pkt 1611032330 547181 intf=Port-Channel553 direction=in type=Multicast host=30.7.253.145 put eos.intflagcounter.counter.octets 1611032330 121113118 intf=Port-Channel553 direction=in host=30.7.253.145 put eos.intflagpktcounter.counter.pkt 1611032330 3649031 type=Ucast host=30.7.253.145 intf=Port-Channel553 direction=out put eos.intflagpktcounter.counter.pkt 1611032330 297600 host=30.7.253.145 intf=Port-Channel553 direction=in type=Ucast put eos.intflagcounter.counter.errors 1611032330 0 intf=Port-Channel553 direction=out host=30.7.253.145 put eos.totalcpu.cpu.utilization.total 1611032330 21 type=util host=30.7.253.145 put eos.totalcpu.cpu.utilization.total 1611032330 225275556 host=30.7.253.145 type=user put eos.corecpu.cpu.utilization.total 1611032330 42929390 type=system host=30.7.253.145 put eos.corecpu.cpu.utilization.total 1611032330 4005894390 type=idle host=30.7.253.145 put eos.corecpu.cpu.utilization.cpu.0 1611032330 55264287 type=user host=30.7.253.145 put eos.corecpu.cpu.utilization.cpu.0 1611032330 10865672 host=30.7.253.145 type=system put eos.corecpu.cpu.utilization.cpu.0 1611032330 1002366784 type=idle host=30.7.253.145 put eos.corecpu.cpu.utilization.cpu.1 1611032330 20 type=util host=30.7.253.145 put eos.corecpu.cpu.utilization.cpu.1 1611032330 50596732 type=user host=30.7.253.145 put eos.corecpu.cpu.utilization.cpu.1 1611032330 10883378 type=system host=30.7.253.145 put eos.corecpu.cpu.utilization.cpu.1 1611032330 1006988024 type=idle host=30.7.253.145 put eos.corecpu.cpu.utilization.cpu.2 1611032330 21 type=util host=30.7.253.145 put eos.corecpu.cpu.utilization.cpu.2 1611032330 58921103 type=user host=30.7.253.145 put eos.corecpu.cpu.utilization.cpu.2 1611032330 10405231 type=system host=30.7.253.145 put eos.corecpu.cpu.utilization.cpu.2 1611032330 999355549 type=idle host=30.7.253.145 put eos.corecpu.cpu.utilization.cpu.3 1611032330 21 type=util host=30.7.253.145 put eos.corecpu.cpu.utilization.cpu.3 1611032330 60493433 type=user host=30.7.253.145 put eos.corecpu.cpu.utilization.cpu.3 1611032330 10775108 type=system host=30.7.253.145 put eos.corecpu.cpu.utilization.cpu.3 1611032330 997184032 type=idle host=30.7.253.145 put eos.tempsensor.environment.temperature 1611032330 45.526831652731964 sensor=cell/1/TempSensor1 host=30.7.253.145 put eos.fanspeed.environment.cooling 1611032330 60.57142857142857 fan=Fan2\/1 host=30.7.253.145 put eos.fanspeed.environment.cooling 1611032330 60.57142857142857 host=30.7.253.145 fan=Fan2\/1 put eos.fanspeed.environment.cooling 1611032330 60.57142857142857 fan=Fan1\/1 host=30.7.253.145 put eos.fanspeed.environment.cooling 1611032330 60.57142857142857 fan=Fan1\/1 host=30.7.253.145 put eos.fanspeed.environment.cooling 1611032330 60.57142857142857 fan=Fan3\/1 host=30.7.253.145 put eos.fanspeed.environment.cooling 1611032330 60.57142857142857 fan=Fan3\/1 host=30.7.253.145 put eos.fanspeed.environment.cooling 1611032330 60.57142857142857 fan=Fan4\/1 host=30.7.253.145 put eos.fanspeed.environment.cooling 1611032330 60.57142857142857 fan=Fan4\/1 host=30.7.253.145 put eos.sfpfixedtemperature.xcvr.temperature 1611032330 38.0390625 host=30.7.253.145 intf=Ethernet3 put eos.sfpfixedrxtxpower.xcvr.power 1611032330 -2.0398103065285085 intf=Ethernet3 powerdirection=tx host=30.7.253.145 put eos.sfpfixedrxtxpower.xcvr.power 1611032330 -1.92938760082761 powerdirection=rx host=30.7.253.145 intf=Ethernet3 put eos.sfpfixedrxtxpower.xcvr.power 1611032330 -1.92938760082761 intf=Ethernet3 powerdirection=rx host=30.7.253.145 -- Richard Ellerbrock

1 0

[Maria-discuss] Setting a System Global Variable
by brian＠smitherconsulting.com 15 Jan '21

15 Jan '21

Hello, Concerning: SET GLOBAL general_log_file='/path/to/general.log'; Some locations in the documentation suggests this can only be done by a super-user. https://mariadb.com/kb/en/general-query-log/ "A user with the SUPER privilege can disable logging to the general query log for a connection by setting the SQL_LOG_OFF system variable to 1." https://mariadb.com/kb/en/grant/#super SUPER: "Execute superuser statements: ..., SET global system variables,...." Q: Does setting the general_log_file, in fact, require super user privileges? Then, once the setting is made, and the task completed, the desire is to restore the setting back to what it was without having to know what it was. https://mariadb.com/kb/en/set/#global-session DEFAULT: "Setting a global variable to DEFAULT will restore it to the server default, and setting a session variable to DEFAULT will restore it to the current global value." Q: By "server default" is this {host_name}.log or is it the value set in my.cnf? Thank you.

1 0

[Maria-discuss] Issue authenticating as mysql in 10.5 on Ubuntu 20.04
by Alexander Nolting 11 Jan '21

11 Jan '21

Hi all, This was probably already discussed. I did a fresh 20.04 and MariaDB 10.5.8 install and now I'm having a question related to the new authentication concept starting from 10.4. As stated at Authentication from MariaDB 10.4 and Authentication in MariaDB 10.4 — Understanding the Changes there are two administrative accounts created: root and mysql. As I understand using both account sockets. Logging as normal user as root into mariadb using unix_sockets is no problem: testusr@host:~$ sudo mariadb -u root Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 38 Server version: 10.5.8-MariaDB-1:10.5.8+maria~focal 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)]> Ctrl-C -- exit! Aborted Doing the same with as mysql testusr@host:~$ sudo mariadb -u mysql returns ERROR 1698 (28000): Access denied for user 'mysql'@'localhost'. If someone can point me to a source detailing me what I may not have understood - any help is appreciated. --- Best Alex

2 2

[Maria-discuss] MariaDB Server MiniFest Dec 9 14h00 CET (UTC+1)
by Ian Gilfillan 22 Dec '20

22 Dec '20

The MariaDB Server MiniFest is scheduled to start on December 9th 2020, at 14:00 UTC+1. The main topic for the MiniFest is MariaDB Server Releases, their quality, frequency and security. You will get a view both from a developer perspective and from a user perspective when it comes to new MariaDB Server releases and we will conclude with a Panel discussing the topic. Details at: https://mariadb.org/minifest2020/ Hope to see you there!

1 1

[Maria-discuss] Galera replication - optimistic locking problems
by Antony Stone 16 Dec '20

16 Dec '20

Hi. I hope this is a reasonable place to ask about Galera replication problems - if not, please point me elsewhere and I'll happily ask others :) I have four Debian 10 "Buster" servers installed with MariaDB 10.1.47 and Galera 25.3.19-2. I have other servers which write to these machines (there's no single "master", since I don't want any particular client to depend on any single master being available), and also read from them (in case it matters, those machines are running Asterisk, and writing Call Event Logs and Call Detail Records into MariaDB via ODBC). My problem is the optimistic locking used by Galera when replicating between nodes. It results in Asterisk log file entries such as: WARNING[20089]: res_odbc.c:460 in ast_odbc_print_errors: SQL Execute returned an error: 40001: [ma-3.0.6][10.1.47-MariaDB-0+deb9u1]Deadlock found when trying to get lock; try restarting transaction Now, that's all very well for an application which can respond to such a warning (personally I'd call it an error, when a write did not take place, but that's a question for Asterisk, not MariaDB) and perform the retry, but Asterisk does not do this. Therefore I'd like to find some way to: 1. tell Galera to use pessimistic locking for replication if possible (I can accept the performance penalty) 2. tell MariaDB to automatically retry the write when the error occurs (although I can't think of any way that could be done, since I can't create a transaction of any sort - the operation is entirely determined for me by Asterisk) 3. find a High-Availability (which basically means no single point of failure) front-end for the whole cluster of 4 MariaDB servers so that the problem does not occur. Questions: 1. How do other people deal with this problem? 2. Are any of my potential solutions above actually feasible? (If so, how?) 3. Does anyone have any alternative ideas about how to connect an application which doesn't understand retrying database writes (Asterisk) with a database which doesn't guarantee to write the data you give it (MariaDB + Galera)? Thanks, Antony. -- Schrödinger's rule of data integrity: the condition of any backup is unknown until a restore is attempted. Please reply to the list; please *don't* CC me.

3 4

Re: [Maria-discuss] Is GET_LOCK() & friends safe when using MIXED mode replication?
by pslawek83 08 Dec '20

08 Dec '20

I think what the documentation is trying to say is that you cannot get VALUE of GET_LOCK(...) inside insert, update, etc. because in statement based replication that VALUE will be obtained both on the master and then again, on the replica itself. So it would probably create data discrepancy between master and slave. INSERT INTO mytable VALUES(GET_LOCK(...)) with replication in STATEMENT mode, you can get eg. "1" inserted to your db on the master and "0" on the slave. True for functions which are non-deterministic, while GET_LOCK is deterministic, we could say is not deterministic on the slave because slave could hold different locks so you can be sure what it'll return on the master but you can't be sure what it'll return on the slave AFTER it gets read from replication log. a. It's of course safe to do in your case, it isn't even DB related as you're not storing the returned value in the DB so the replica can't get out of sync because of that. b. correct Best, S. Dnia 8 grudnia 2020 10:28 Jan Zankowski <jan.zankowski(a)gmail.com> napisał(a): Hello, I'd like to use GET_LOCK() and RELEASE_LOCK() on MariaDB 10.2 to implement basic distributed locking, to prevent simultaneous runs of a job unrelated to the DB. I see however in the mariadb.com MariaDB docs that: "Statements using the GET_LOCK function are not safe for statement-based replication." I also see in dev.mysql.com MySQL docs that this is likely only for statements such as "INSERT INTO mytable VALUES(GET_LOCK(...))." Full excerpt from MySQL docs: The following restriction applies to statement-based replication only, not to row-based replication. The GET_LOCK(), RELEASE_LOCK(), IS_FREE_LOCK(), and IS_USED_LOCK() functions that handle user-level locks are replicated without the replica knowing the concurrency context on the source. Therefore, these functions should not be used to insert into a source table because the content on the replica would differ. For example, do not issue a statement such as INSERT INTO mytable VALUES(GET_LOCK(...)). These functions are automatically replicated using row-based replication when using MIXED mode, and generate a warning in STATEMENT mode. Could someone please confirm that: (a) We will be safe using GET_LOCK() & RELEASE_LOCK() in MIXED mode. (b) If we used STATEMENT mode, the only case of not being safe is when the return value of GET_LOCK() etc. is directly involved in some other DB operations (e.g. inserted into a table). In particular, the use case when the locks are used only to prevent simultaneous runs of an external job should be fine. I strongly suspect this is not what "unsafe" means in this context, but not being an expert on replication, what I'm really worried about is that our replication would simply blow up or get totally out of sync if I used GET_LOCK(). Please calm these fears if you can. :) Thanks! Jan ______________________________ Mailing list: launchpad.net launchpad.net Post to : maria-discuss(a)lists.launchpad. Unsubscribe : launchpad.net launchpad.net More help : help.launchpad.net help.launchpad.net

1 0

[Maria-discuss] Is GET_LOCK() & friends safe when using MIXED mode replication?
by Jan Zankowski 08 Dec '20

08 Dec '20

Hello, I'd like to use GET_LOCK() and RELEASE_LOCK() on MariaDB 10.2 to implement basic distributed locking, to prevent simultaneous runs of a job unrelated to the DB. I see however in the MariaDB docs <https://mariadb.com/kb/en/get_lock/> that: "Statements using the GET_LOCK function are not safe for statement-based replication." I also see in MySQL docs <https://dev.mysql.com/doc/refman/5.7/en/replication-features-functions.html> that this is likely only for statements such as "INSERT INTO mytable VALUES(GET_LOCK(...))." Full excerpt from MySQL docs: *The following restriction applies to statement-based replication only, not to row-based replication. The GET_LOCK(), RELEASE_LOCK(), IS_FREE_LOCK(), and IS_USED_LOCK() functions that handle user-level locks are replicated without the replica knowing the concurrency context on the source. Therefore, these functions should not be used to insert into a source table because the content on the replica would differ. For example, do not issue a statement such as INSERT INTO mytable VALUES(GET_LOCK(...)). These functions are automatically replicated using row-based replication when using MIXED mode, and generate a warning in STATEMENT mode.* Could someone please confirm that: (a) We will be safe using GET_LOCK() & RELEASE_LOCK() in MIXED mode. (b) If we used STATEMENT mode, the only case of not being safe is when the return value of GET_LOCK() etc. is directly involved in some other DB operations (e.g. inserted into a table). In particular, the use case when the locks are used only to prevent simultaneous runs of an external job should be fine. I strongly suspect this is not what "unsafe" means in this context, but not being an expert on replication, what I'm really worried about is that our replication would simply blow up or get totally out of sync if I used GET_LOCK(). Please calm these fears if you can. :) Thanks! Jan

1 0

[Maria-discuss] Remove everything except email addresses in from_addr table in mariaDB
by Indunil Jayasooriya 27 Nov '20

27 Nov '20

Hi list, I am running MariaDB Server version: 10.4.17-MariaDB in Cent OS7. I have a column called from_addr from table msgs. Plz see its OUTPUT. select from_addr from msgs; +----------------------------------------------------------------+ | from_addr | +----------------------------------------------------------------+ | admin(a)sender.com | | userl(a)mysys.net | | Firstname Lastname <user622(a)yahoo.com> | | userl(a)mysys.net | | Firstname Lastname <user75(a)gmail.com> | | root(a)domain.net (root) | | userl(a)mysys.net | | userl(a)mysys.net | | Firstname Lastname <user75(a)gmail.com> | | userl(a)mysys.net | +--------------------------------------------------------------+ When Users send mails this from_addr column fills. some times with just email addresses, Some times email address with Display names. What I expect is to remove all the display name part. I only need email addresses. I expect from_addr column in this way. +--------------------------------------------+ | from_addr | +--------------------------------------------+ | admin(a)sender.com | | userl(a)mysys.net | | user622(a)yahoo.com | | userl(a)mysys.net | | user75(a)gmail.com | | root(a)domain.net | | userl(a)mysys.net | | userl(a)mysys.net | | user75(a)gmail.com | | userl(a)mysys.net | +--------------------------------------------+ How can I solve it. I tried a lot. But, I could NOT get what I expect. finally I subscribed to mariaDB mailing list. I need your INPUTS. -- cat /etc/motd Thank you Indunil Jayasooriya http://www.theravadanet.net/

2 1

[Maria-discuss] MaxScale 2.5 - [mariadbclient] (send_authetication_error)
by Micha Ballmann 23 Nov '20

23 Nov '20

Hi @all, I have a problem and I stuck with MaxScale 2.5. I deployed a 5 node galeracluster and installed MaxScale as proxy. First i thought everthing is fine. I can monitor and connect each galera node but i have a strange problem by connecting a client through the proxy. I have a media wiki db and user. user: wiki dbname: wiki permissions: grant all host: wiki@% I can successful connect the dabatabse from my client server on cli like: # mysql -u wiki -p jlkadjfg78 -h maxscale.example.com -> this ist working. Now when configuring the database in media wiki my proxy throws the following error: Nov 20 16:17:45 maxscale maxscale[12714]: (95) [mariadbclient] (process_authentication): User accounts have been recently updated, cannot update again for 'wiki'@'<IP.-from-media-wiki>'. Nov 20 16:17:45 maxscale maxscale[12714]: (95) [mariadbclient] (send_authetication_error): Authentication failed for user 'wiki'@['<IP.-from-media-wiki>] to service 'Galera-Service'. Originating listener: 'Galera-Listener'. MariaDB error: 'Access denied for user 'wiki'@''<IP.-from-media-wiki>' to database 'wiki''. I dont know why access denied. I can connect with the local mysql client from the media wiki server. I checked the grants of my maxscale "admin" user (https://mariadb.com/kb/en/maxscale-troubleshooting/) This is my maxscale config: ################## # Globals [maxscale] threads = auto syslog = 1 maxlog = 1 log_augmentation = 1 ms_timestamp = 1 # Servers [maria1] type = server address = 10.20.105.224 port = 3306 protocol = MariaDBBackend ... # Galera Monitor [Galera-Monitor] type = monitor module = galeramon servers = maria1,maria2,maria3,maria4,maria5 user =maxscale password =passwd monitor_interval= 2000 # Galera Router [Galera-Service] type = service router = readwritesplit servers = maria1,maria2,maria3,maria4,maria5 user = maxscale password = passwd # Galera Listener [Galera-Listener] type = listener service = Galera-Service protocol = MariaDBClient port = 3306 address = 0.0.0.0 ################## I hope you can help. Feel free to ask for information. All servers are running on Ubuntu 20.04 - latest mariadb and maxscale. Br fettfoen

2 1

[Maria-discuss] Increase in IOPS between 5.5 and 10.4
by martin doc 14 Nov '20

14 Nov '20

Recently upgraded a cluster of MariaDB servers from 5.5 to 10.4 and with grafana, I can see that all of the 10.4 instances use about 20% IOPS for the same workload. i.e, if inserting 100,000 rows took 200,000 IOPs with 5.5 then on 10.4 it takes 240,000. Has anyone else noticed this? Or know how to tune MariaDB to get better IOPS out of 10.4?

2 2

Re: [Maria-discuss] Using SSH keys for authenticating MariaDB users? (pam_ssh module or ed25519)
by Otto Kekäläinen 20 Oct '20

20 Oct '20

> > PS. The die links from the wiki seem a bit outdated. I would recommend > > > linking directly to a source that inherits its contents from fresh > > > Linux distro packages, such as > > > https://manpages.debian.org/unstable/libpam-ssh/pam_ssh.8.en.html or > > > https://manpages.ubuntu.com/manpages/focal/en/man8/pam_ssh.8.html > > > > > > > > This seems like a good suggestion, anybody object? > Yes but there are lot's of other die.net links in the page so maybe we > should change them all then. Also regarding pam_unix manual, this seems > to be the source (but there is no pam_ssh man on that site): > http://linux-pam.org/Linux-PAM-html/sag-pam_unix.html Yes, I suggest so. Seems die.net has been stagnant since 2017. I prefer the distro sites or man7.org by Michael Kerrisk.

1 0

[Maria-discuss] Using SSH keys for authenticating MariaDB users? (pam_ssh module or ed25519)
by Otto Kekäläinen 20 Oct '20

20 Oct '20

Hello! Has anybody successfully set up MariaDB authentication using SSH keys? I've tried but can't figure out how to get the client part working.. On https://mariadb.com/kb/en/authentication-plugin-pam/ it is stated that using the PAM module one can benefit of the pam_ssh PAM module: > Authentication using SSH keys. See the pam_ssh PAM module. This got me thinking that it might be possible. I installed the module in MariaDB, installed the PAM module on the system, configured the MariaDB server part and added a user but then ran into a wall when trying to authenticate. There does not seem to be any way to tell the mariadb client that "send this SSH key to server", it always wants to use a password. It got me thinking, that since the mariadb client does not seem to support anything else than dialog and password, maybe "Authentication using SSH keys" isn't actually possible yet? Should the documentation in the wiki be updated a bit to outline what is actually possible now, and what is potentially in the future? Here are my configs global_priv user localhost@: {"access":0,"ssl_type":0,"ssl_cipher":"","x509_issuer":"","x509_subject":"","max_questions":0,"max_updates":0,"max_connections":0,"max_user_connections":0,"max_statement_time":0.000000,"plugin":"pam","authentication_string":"mariadb","password_last_changed":1602657078,"password_lifetime":-1,"account_locked":false,"default_role":"","is_role":false} # mysql -e "show plugins" | grep pam pam ACTIVE AUTHENTICATION auth_pam.so GPL # cat /etc/mysql/conf.d/pam-ssh.cnf [mariadb] plugin_load_add = auth_pam # cat /etc/pam.d/mariadb auth required pam_ssh.so audit account required pam_ssh.so audit On https://mariadb.com/kb/en/authentication-plugin-ed25519/ there is also documentation about the plugin that stores passwords in the ed25519 format. My SSH keys are using ed25519 - can this auth plugin be (mis)used so that I store the public key in the MariaDB user database as a password somehow and then send in as username/password some proof signed by my private key? Thus essentially using SSH keys and the same authentication, but without invoking any SSH? PS. The die links from the wiki seem a bit outdated. I would recommend linking directly to a source that inherits its contents from fresh Linux distro packages, such as https://manpages.debian.org/unstable/libpam-ssh/pam_ssh.8.en.html or https://manpages.ubuntu.com/manpages/focal/en/man8/pam_ssh.8.html

2 2

[Maria-discuss] How to write streaming data to mariaDB columnStorage efficiently？
by wanglei2＠geekplus.com 16 Oct '20

16 Oct '20

I just have a try. CREATE TABLE `robotmetrics2` ( `robotid` varchar(16) DEFAULT NULL, `ts` bigint(20) DEFAULT NULL, `xloc` int(11) DEFAULT NULL, `yloc` int(11) DEFAULT NULL, `velocity` int(11) DEFAULT NULL, `angular_velocity` int(11) DEFAULT NULL ) ENGINE=Columnstore DEFAULT CHARSET=utf8 But when i write data to the table with python connector, the qps is only about 10/s. And the cpu is 60%+. And it takes a lot of disk space. Mainly this file: /var/lib/columnstore/data1/versionbuffer.cdf Does i do something wrong? Thanks, Lei wanglei2(a)geekplus.com

1 0

[Maria-discuss] InnoDB: background jobs & fsyncs
by Julien Muchembled 21 Sep '20

21 Sep '20

Hello, We are evaluating new hardware by reproducing real-life workload on real-life data which works fine on an existing server. We copied over the software used to ensure an apple-to-apple comparison, which is based on MariaDB 10.2.23 and uses primarily InnoDB tables, with a few Mroonga tables which do not seem involved in the problem. On the new hardware, we are seeing catastrophically bad performance, especially chain-deadlocks happening and being resolved but producing virtually no useful work at our usual parallelism level of 64 active connections. If we reduce parallelism to 2 active connections, queries start to succeed in any meaningful proportion. The database was freshly restored from a mysqldump (as we cannot interrupt the original database), could this have any effect on deadlocks ? The main tables involved in the deadlocking queries (job queues) are initially (in the test, and periodically in reality) empty, so it would seem surprising. What should I check to debug further ? Note that these deadlocks happen in production but they're negligible. See attachment for mariadb configuration file. Some more details: When we restore from mysqldump, we use the following extra options to speed things up: innodb_flush_log_at_trx_commit = 0 innodb_flush_method = nosync innodb_doublewrite = 0 sync_frm = 0 as during that period nothing of value can be lost (worst case we restart the restore from scratch). BTW, despite these settings, we are still noticing a lot of fsyncs. Is this expected ? Are we missing some other option ? Also, after the import and without any connection, MariaDB was still producing a non-trivial amount of activity on the machine: 5% CPU, read <1MB/s, write 10MB/s, 60 fsync/s. I could not identify what is causing these, where should I look ? How can I tell when it will stabilise back to idle ? When I interrupt the benchmark workload, I see a similar resource usage. I saw https://jira.mariadb.org/browse/MDEV-18698 And InnoDB seems to throttle its background activity: is there a way to tell InnoDB to perform its background tasks at maximum speed ? (the goal is that after the import, we can make a clean tarball that we extract when we want to launch the test case again) Regards, Julien

3 3

[Maria-discuss] How to replicate TO a HA pair of MariaDB servers?
by martin doc 16 Sep '20

16 Sep '20

Hi, I've got a bit of a different question regarding MariaDB replication. But first, let me say that I'm familiar with both master-master and master-slave replication. What I'm after advice on is how to replicate tables from a number of single host instances of MariaDB to a single HA pair of MariaDB servers (HA-1/HA-2) that have a VIP that moves between them. One way of looking at this might be to say that the single host instances of MariaDB are satellite servers that I need to pull table data back into a primary pair. Kind of like a backup. I've tried to think of how I could do this using what I know. Can I setup master-slave relationships and specify the source address on the slave (in this case the HA pair)? The idea is that the replication would fail from HA-1 when the VIP is on HA-2. In this case the single-host masters would only allow replication connections from the VIP. Or the connection out from the slave to the master would fail to bind to the VIP (and thus fail to connect to the master) if the VIP was not on a local interface. Of course I want both servers (HA-1/HA-2) in the redundant pool to be able to serve queries, so I'm not too keen on setting the bind address in [mysqld] to be the VIP and using net.ipv4.ip_nonlocal_bind - but I could be open to that. Is it possible to specify a bind address for replication that is separate to that used in [msyqld]? Are there other ways to solve this problems? Cheers.

3 7

[Maria-discuss] MariaDB Server Fest 14-20 September
by Ian Gilfillan 13 Sep '20

13 Sep '20

1 0

Re: [Maria-discuss] mariadb-config sym-link in MariaDB 10.5.5
by Chris Ross (cross2) 13 Sep '20

13 Sep '20

Following up, with some more specifics... After configuring with below options, we have the first `maria*config` find(1) results, and then running “make” yields the expected binary : % find . -name maria\*config ./srcdir/mariadb-10.5.5/libmariadb/mariadb_config ./srcdir/mariadb-10.5.5/debian/mariadb-server-10.5.config <make> % find . -name maria\*config ./srcdir/mariadb-10.5.5/libmariadb/mariadb_config ./srcdir/mariadb-10.5.5/libmariadb/mariadb_config/mariadb_config ./srcdir/mariadb-10.5.5/debian/mariadb-server-10.5.config Then, a “make DESTDIR=destdir install” yields the following: ./destdir/usr/bin/mariadb_config ./srcdir/mariadb-10.5.5/libmariadb/mariadb_config ./srcdir/mariadb-10.5.5/libmariadb/mariadb_config/mariadb_config ./srcdir/mariadb-10.5.5/debian/mariadb-server-10.5.config And, after no other changes, rerunning the exact same make install command produces the following. Clearly, something is wrong with the make install process. So, should the first install create the sym-link, but isn’t? Or, is it configured in some way that the sym-link shouldn’t be created, and it is, but only when running make install twice? ./destdir/usr/bin/mariadb_config ./destdir/usr/bin/mariadb-config ./srcdir/mariadb-10.5.5/libmariadb/mariadb_config ./srcdir/mariadb-10.5.5/libmariadb/mariadb_config/mariadb_config ./srcdir/mariadb-10.5.5/debian/mariadb-server-10.5.config % ls -l destdir/usr/bin/maria*config -rwxr-xr-x 1 cross2 5011 25936 Sep 11 14:05 destdir/usr/bin/mariadb_config lrwxrwxrwx 1 cross2 5011 14 Sep 11 14:56 destdir/usr/bin/mariadb-config -> mariadb_config Please let me know. This looks like a bug in the build/install process, but I want to know how to work around it on my side while the fix is developed. Thank you! - Chris From: Maria-discuss <maria-discuss-bounces+cross2=cisco.com(a)lists.launchpad.net> on behalf of "Chris Ross (cross2)" <cross2(a)cisco.com> Date: Friday, September 11, 2020 at 08:42 To: "maria-discuss(a)lists.launchpad.net" <maria-discuss(a)lists.launchpad.net> Subject: [Maria-discuss] mariadb-config sym-link in MariaDB 10.5.5 Hello there friends. We have recently moved our product to MariaDB 10.5.5, and someone on my team noticed an oddity that occurs in some build processes. The product has a complicated make-based build system, and many phases including “make src” and “make build” which pre-req’s the “src” target, and includes packaging. The dev work to integrate mariadb used “make build”, which works. Someone found unexpectedly this morning, that if we perform a “make src ; make build” we get a different outcome. There is a sym-link created by the install target lrwxrwxrwx 1 cross2 5011 14 Sep 11 08:30 ./destdir/usr/bin/mariadb-config -> mariadb_config that is _not_ created in the first build. The first build, which given the dependencies of other parts of our product needing mariadb libraries to build, performs the destdir install (via “make install” in mariadb). And, that includes mariadb_config, but _not_ mariadb-config. Can someone help me figure out where that sym-link is created, and why it seems to only be created when maria’s “make install” is run twice? - Chris Cmake config: CONF_OPTIONS:=-DBUILD_CONFIG=mysql_release \ -DAWS_SDK_EXTERNAL_PROJECT=OFF \ -DCMAKE_INSTALL_PREFIX:PATH=${EXTRAPREFIX}/usr \ -DINSTALL_LAYOUT=RPM \ -DINSTALL_PLUGINDIR=lib64/plugin \ -DINSTALL_SYSCONFDIR="" \ -DINSTALL_MYSQLTESTDIR="" \ -DWITH_EMBEDDED_SERVER=NO \ -DWITH_JEMALLOC=OFF \ -DWITH_PCRE=auto \ -DWITH_SSL=system \ -DWITH_ZLIB=system \ -DWITH_WSREP=OFF -DPLUGIN_WSREP_INFO=NO \ -DPLUGIN_AUTH_TEST_PLUGIN=NO \ -DPLUGIN_FUNC_TEST=NO \ -DPLUGIN_TYPE_TEST=NO \ -DPLUGIN_TEST_SQL_DISCOVERY=NO \ -DPLUGIN_TEST_VERSIONING=NO \ -DPLUGIN_BLACKHOLE=NO \ -DPLUGIN_CONNECT=NO \ -DPLUGIN_EXAMPLE=NO -DPLUGIN_EXAMPLE_KEY_MANAGEMENT=NO \ -DPLUGIN_FTEXAMPLE=NO \ -DPLUGIN_FEDERATED=NO -DPLUGIN_FEDERATEDX=NO \ -DPLUGIN_MROONGA=NO -DMRN_GROONGA_EMBED=OFF \ -DPLUGIN_S3=NO \ -DPLUGIN_SPIDER=NO \ -DPLUGIN_SPHINX=NO \ -DPLUGIN_TOKUDB=NO \ -DPLUGIN_ROCKSDB=NO CONF_OPTIONS += -DSKIP_TESTS=ON -DWITH_UNIT_TESTS=NO -- Chris Ross Software Engineering Manager – Eventing/Datastore Teams cross2(a)cisco.com

2 3

[Maria-discuss] mariadb-config sym-link in MariaDB 10.5.5
by Chris Ross (cross2) 11 Sep '20

11 Sep '20

Hello there friends. We have recently moved our product to MariaDB 10.5.5, and someone on my team noticed an oddity that occurs in some build processes. The product has a complicated make-based build system, and many phases including “make src” and “make build” which pre-req’s the “src” target, and includes packaging. The dev work to integrate mariadb used “make build”, which works. Someone found unexpectedly this morning, that if we perform a “make src ; make build” we get a different outcome. There is a sym-link created by the install target lrwxrwxrwx 1 cross2 5011 14 Sep 11 08:30 ./destdir/usr/bin/mariadb-config -> mariadb_config that is _not_ created in the first build. The first build, which given the dependencies of other parts of our product needing mariadb libraries to build, performs the destdir install (via “make install” in mariadb). And, that includes mariadb_config, but _not_ mariadb-config. Can someone help me figure out where that sym-link is created, and why it seems to only be created when maria’s “make install” is run twice? - Chris Cmake config: CONF_OPTIONS:=-DBUILD_CONFIG=mysql_release \ -DAWS_SDK_EXTERNAL_PROJECT=OFF \ -DCMAKE_INSTALL_PREFIX:PATH=${EXTRAPREFIX}/usr \ -DINSTALL_LAYOUT=RPM \ -DINSTALL_PLUGINDIR=lib64/plugin \ -DINSTALL_SYSCONFDIR="" \ -DINSTALL_MYSQLTESTDIR="" \ -DWITH_EMBEDDED_SERVER=NO \ -DWITH_JEMALLOC=OFF \ -DWITH_PCRE=auto \ -DWITH_SSL=system \ -DWITH_ZLIB=system \ -DWITH_WSREP=OFF -DPLUGIN_WSREP_INFO=NO \ -DPLUGIN_AUTH_TEST_PLUGIN=NO \ -DPLUGIN_FUNC_TEST=NO \ -DPLUGIN_TYPE_TEST=NO \ -DPLUGIN_TEST_SQL_DISCOVERY=NO \ -DPLUGIN_TEST_VERSIONING=NO \ -DPLUGIN_BLACKHOLE=NO \ -DPLUGIN_CONNECT=NO \ -DPLUGIN_EXAMPLE=NO -DPLUGIN_EXAMPLE_KEY_MANAGEMENT=NO \ -DPLUGIN_FTEXAMPLE=NO \ -DPLUGIN_FEDERATED=NO -DPLUGIN_FEDERATEDX=NO \ -DPLUGIN_MROONGA=NO -DMRN_GROONGA_EMBED=OFF \ -DPLUGIN_S3=NO \ -DPLUGIN_SPIDER=NO \ -DPLUGIN_SPHINX=NO \ -DPLUGIN_TOKUDB=NO \ -DPLUGIN_ROCKSDB=NO CONF_OPTIONS += -DSKIP_TESTS=ON -DWITH_UNIT_TESTS=NO -- Chris Ross Software Engineering Manager – Eventing/Datastore Teams cross2(a)cisco.com

1 0

[Maria-discuss] Set password for all users, regardless of host value
by Chris Ross (cross2) 08 Sep '20

08 Sep '20

Hello there. We have scripts to restore credentials to MySQL databases from external store. The mechanism that was in use, however, stores usernames and passwords, without consideration of the scope (host) of that auth record. In older systems, UPDATE mysql.user SET password = PASSWORD(‘rawpassword’) WHERE user = ‘username’ worked, updating it for all values of that user that might exist in the table. But, I’m not sure how to do this for MariaDB 10.5. Is there way to form an “ALTER USER” statement such that it will set the password for any and all userspecs that exist with the given username? We don’t have that many, and I could iterate the known configurations with “ALTER USER IF EXISTS”, but I worry that might miss things added in the future. Thank you. - Chris -- Chris Ross Software Engineering Manager – Eventing/Datastore Teams cross2(a)cisco.com

4 8

[Maria-discuss] How to Migrate Wordpress Website from 32-bit CentOS Linux 6.3 to 64-bit CentOS Linux 8.2 (2004)
by Turritopsis Dohrnii Teo En Ming 31 Aug '20

31 Aug '20

Subject: How to Migrate Wordpress Website from 32-bit CentOS Linux 6.3 to 64-bit CentOS Linux 8.2 (2004) Author of this Guide: Mr. Turritopsis Dohrnii Teo En Ming (TARGETED INDIVIDUAL) Country: Singapore Date: 31 August 2020 Monday Singapore Time Type of Publication: Plain Text Document Version: 20200831.01 Redundant links to my guide: [1] https://lkml.org/lkml/2020/8/31/454 [2] http://lkml.iu.edu/hypermail/linux/kernel/2008.3/09047.html [3] https://marc.info/?l=linux-kernel&m=159888024529073&w=2 [4] https://lwn.net/ml/linux-kernel/70ce3070fa816dbbe2e6424b2ae7f322%40teo-en-m… [5] http://lists.linuxfromscratch.org/pipermail/lfs-chat/2020-August/029149.html [6] https://lists.centos.org/pipermail/centos/2020-August/351448.html [7] https://marc.info/?l=apache-httpd-users&m=159888114229385&w=2 [8] https://marc.info/?l=php-general&m=159888203429670&w=2 [9] https://mta.openssl.org/pipermail/openssl-users/2020-August/012915.html -----BEGIN EMAIL SIGNATURE----- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html ******************************************************************************************** Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -----END EMAIL SIGNATURE-----

1 0

[Maria-discuss] Can't disable Mariadb general query log
by Artem Russakovskii 31 Aug '20

31 Aug '20

Hi folks, I'm at a loss here. I've had a mysql and now mariadb (MariaDB 10.4.13-MariaDB-log) slave with query logging enabled for years, but I'm now trying to turn it off using the my.cnf option and it does not seem to stick on server restarts. What's weird is the other slaves with the exact same my.cnf don't log, but this one slave refuses to stop doing it. To clarify, SET global general_log = 0 does stop logging but the setting comes back on after a restart. I'm turning it off in my.cnf like this: general_log = off #Enter a name for the query log file. Otherwise a default name will be used. general_log_file=/var/log/mysql/mysqld-queries.log Commenting out general_log_file simply changes it to go to a different location. I also tried general_log=0 without any luck. ps shows it as running with: mysql 27580 1 99 16:26 ? 00:01:40 /usr/sbin/mysqld --defaults-file=/etc/my.cnf --user=mysql So --general-log isn't getting set on command line. What am I missing? Why does it insist on getting turned on and refuses to listen to the setting? Is it a bug? Thanks. Sincerely, Artem -- Founder, Android Police <http://www.androidpolice.com>, APK Mirror <http://www.apkmirror.com/>, Illogical Robot LLC beerpla.net | @ArtemR <http://twitter.com/ArtemR>

2 6

[Maria-discuss] Missing table rows when importing a MySQL 5.7.8 database into MariaDB 10.4.8 database
by Elliot Holden 27 Aug '20

27 Aug '20

Hello All, New to the list, so maybe an expert has the easy answer to this one... When I use mysqldump to backup a MySQL 5.7.8 database then import that database into a MariaDB 10.4.8 database, at least one (maybe more) of the imported tables is missing rows. This a WordPress database and the table in question is the *wp_options* table. I'm only getting 29 rows imported when there should be over 600 (in the original MySQL database). I'm using the *mysqldump* and *mysql* utilities located on the MariaDB server: mysqldump Ver 10.17 Distrib 10.4.8-MariaDB, for Linux (x86_64) mysql Ver 15.1 Distrib 10.4.8-MariaDB, for Linux (x86_64) using readline 5.1 My steps as performed on the MariaDB server. 1. mysqldump -u username -pPassword -h remote_mysql_server database_name > wp_backup.sql 2.mysql -u username -pPassword -h localhost database_name < wp_backup.sql _* *_ When I run *mysql* (on the local MariaDB server) and import the wp_backup.sql to the remote_mysql_server everything works fine and all rows are importing into a test database out there_*:*_ mysql -u username -pPassword -h remote_mysql_server database_name < wp_backup.sql So the above works I know I'm probably missing something simple but just don't know... they both seem to use the same InnoDB engine. I did notice the Db character set is different between the databases though (highlighted in blue below). Maybe do I need to upgrade to MariaDB *10.4.14* Any help would be greatly appreciated.....? Details about each server listed below: _* *_ _*MySQL*_ Server version: 5.7.28-log Source distribution Protocol version: 10 Server characterset: latin1 Db characterset: utf8 Client characterset: utf8 Conn. characterset: utf8 *************************** 1. row *************************** Engine: InnoDB Support: DEFAULT Comment: Supports transactions, row-level locking, and foreign keys Transactions: YES XA: YES Savepoints: YES _* *__*MariaDB*_ Server version: 5.5.5-10.4.8-MariaDB MariaDB Server Protocol version: 10 Server characterset: latin1 Db characterset: latin1 Client characterset: utf8 Conn. characterset: utf8 *************************** 7. row *************************** Engine: InnoDB Support: DEFAULT Comment: Supports transactions, row-level locking, foreign keys and encryption for tables Transactions: YES XA: YES Savepoints: YES -- Elliot Holden ‪(404)884-8593‬ elliot(a)elliotmywebguy.com https://www.ElliotMyWebGuy.com

7 15

[Maria-discuss] Out of sort memory, consider increasing server sort buffer size - after upgrade to 10.5.5
by Jeff Dyke 26 Aug '20

26 Aug '20

Unfortunately, I can't easily give you a repro case, or show you the queries. I upgraded a replica/DW server from 10.4.latest to 10.5.5. I did this on Friday night. We're not a high volume site (by design) so nothing would really pop up over the weekend. We use google data studio to present reports of aggregated data after the daily events have run. Any given report page will generate from 5-25 connections from datastudio, lots of joins, group bys etc. All of the daily events and reporting and ad-hoc querying by our data analyst was working fine on 10.4, but on 10.5.5, started generating "Out of sort memory, consider increasing server sort buffer size" errors. That's the background, there were no query changes, no significant increase in data. I changed sort_buffer_size and made a couple other optimizations that fit our environment and table types. And i'll have more information in the next few days. All that, leads me to a simple question, that I have not been able to find an answer to or missed something in the changelogs that would indicate this behaviour would have changed. Has anyone seen anything similar. Or does this ring a bell to a change I need to tune other than increasing sort_buffer_size. The only thing that changed was an upgrade. Thanks for reading and giving it a thought.

2 3