- developers - lists.mariadb.org

[Maria-developers] Problems installing mariadb published debian packages when using tmpfs for /tmp
by Andrew McDonnell 17 Feb '14

17 Feb '14

Hiya, I followed the instructions here: https://downloads.mariadb.org/mariadb/repositories/#mirror=aarnet_pty_ltd&d… cluminating with: apt-get install mariadb-server mariadb-client -t wheezy and eventually after almost everything appears to have worked, I get a fail starting mysqld. (Log follows after) To summarise the log below, my interpetation of the errors is: * mysql doesnt like tmpfs * I am using tmpfs for /tmp. But the ibdata files getcreated in /var/lib/mysql which is not on tmpfs. So I dont understand what is happening here... * I am running zfs. Could be part of the problem? So I set innodb_data_home_dir = /path/to/something/on/ext4, then chown mysql:mysql /path/to/something/on/ext4 And fail with "Cannot create ./ib_logfile101" So I reverted my change to the location and instead tried using innodb_flush_method = O_DSYNC (which seems to default to O_DIRECT) This time things moved a little further, failing instead at 'Setting log file ./ib_logfile1 size to 48 MB 2014-02-16 21:51:39 7f03b252b780 InnoDB: Operating system error number 22 in a file operation.' Now I have managed to build mariadb from source and run without these problems. So there seems to be something tricky needed mariadb 10 to run in Debian? This on a wheezy 7.2 amd64 system. ---- Long trace follows ---- So I noted that mysql-common remained in the system, so I apt-get purged it (not just removed) and tried again. Purging this took out mariadb which obviously seems to have mysql-common as a dependency, so they all got a reinstalling. Which drags back in mysql-common, but this time as a 10.0, the one that got purged was 5.5.x This time I had the same errors, plus the following as well: 140216 21:22:08 [ERROR] InnoDB: Failed to set O_DIRECT on file ./ibdata1: OPEN: Invalid argument, continuing anyway 140216 21:22:08 [ERROR] InnoDB: O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662 I noticed then that /var/log/mysql.err was empty, oddly. So if I then manually run mysqld-safe --syslog: Feb 16 21:31:05 atlantis4 mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] InnoDB: The InnoDB memory heap is disabled Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Not e] InnoDB: Compressed tables use zlib 1.2.7 Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] InnoDB: Using Linux native AIO Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] InnoDB: Not using CPU crc32 instructions Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] InnoDB: Initializing buffer pool, size = 256.0M Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] InnoDB: Completed initialization of buffer pool Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] InnoDB: Failed to set O_DIRECT on file ./ibdata1: OPEN: Invalid argument, continuing anyway Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] InnoDB: O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662 Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] InnoDB: auto-extending data file ./ibdata1 is of a different size 640 pages (rounded down to MB) than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages! Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data! Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] Plugin 'InnoDB' init function returned error. Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] Plugin 'FEEDBACK' is disabled. Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] Unknown/unsupported storage engine: InnoDB Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] Aborting Feb 16 21:31:05 atlantis4 mysqld: Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] /usr/sbin/mysqld: Shutdown complete Feb 16 21:31:05 atlantis4 mysqld: Feb 16 21:31:05 atlantis4 mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended (END) So I deleted /var/log/mysql and reran mysql_installdb. # mysql_install_db Installing MariaDB/MySQL system tables in '/var/lib/mysql' ... 140216 21:33:12 [Note] InnoDB: The InnoDB memory heap is disabled 140216 21:33:12 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 140216 21:33:12 [Note] InnoDB: Compressed tables use zlib 1.2.7 140216 21:33:12 [Note] InnoDB: Using Linux native AIO 140216 21:33:12 [Note] InnoDB: Not using CPU crc32 instructions 140216 21:33:12 [Note] InnoDB: Initializing buffer pool, size = 256.0M 140216 21:33:12 [Note] InnoDB: Completed initialization of buffer pool 140216 21:33:12 [ERROR] InnoDB: Failed to set O_DIRECT on file ./ibdata1: CREATE: Invalid argument, continuing anyway 140216 21:33:12 [ERROR] InnoDB: O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662 140216 21:33:12 [Note] InnoDB: The first specified data file ./ibdata1 did not exist: a new database to be created! 140216 21:33:12 [Note] InnoDB: Setting file ./ibdata1 size to 12 MB 140216 21:33:12 [Note] InnoDB: Database physically writes the file full: wait... 140216 21:33:12 [Note] InnoDB: Setting log file ./ib_logfile101 size to 48 MB 140216 21:33:12 [Note] InnoDB: Setting log file ./ib_logfile1 size to 48 MB 140216 21:33:12 [ERROR] InnoDB: Failed to set O_DIRECT on file ./ibdata1: OPEN: Invalid argument, continuing anyway 140216 21:33:12 [ERROR] InnoDB: O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662 2014-02-16 21:33:12 7f66ea899780 InnoDB: Operating system error number 22 in a file operation. InnoDB: Error number 22 means 'Invalid argument'. InnoDB: Some operating system error numbers are described at InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html 140216 21:33:12 [ERROR] InnoDB: File ./ib_logfile101: 'aio write' returned OS error 122. Cannot continue operation Installation of system tables failed! Examine the logs in /var/lib/mysql for more information. <snipped> Errors after setting innodb_data_home_dir = /scratch/mysql # chown -R mysql:mysql /scratch/mysql/ root@atlantis4:/scratch# mysql_install_db Installing MariaDB/MySQL system tables in '/var/lib/mysql' ... 140216 21:47:44 [Note] InnoDB: The InnoDB memory heap is disabled 140216 21:47:44 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 140216 21:47:44 [Note] InnoDB: Compressed tables use zlib 1.2.7 140216 21:47:44 [Note] InnoDB: Using Linux native AIO 140216 21:47:44 [Note] InnoDB: Not using CPU crc32 instructions 140216 21:47:44 [Note] InnoDB: Initializing buffer pool, size = 256.0M 140216 21:47:44 [Note] InnoDB: Completed initialization of buffer pool 140216 21:47:44 [Note] InnoDB: The first specified data file /scratch/mysql/ibdata1 did not exist: a new database to be created! 140216 21:47:44 [Note] InnoDB: Setting file /scratch/mysql/ibdata1 size to 12 MB 140216 21:47:44 [Note] InnoDB: Database physically writes the file full: wait... 140216 21:47:44 [ERROR] InnoDB: Cannot create ./ib_logfile101 140216 21:47:44 [ERROR] Plugin 'InnoDB' init function returned error. 140216 21:47:44 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 140216 21:47:44 [ERROR] Unknown/unsupported storage engine: InnoDB 140216 21:47:44 [ERROR] Aborting --- Log trace of first failed install follows --- Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libmariadbclient18 libmysqlclient18 mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common mariadb-server-10.0 mariadb-server-core-10.0 Suggested packages: tinyca mariadb-test The following packages will be REMOVED: mysql-client-5.5 mysql-server-core-5.5Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libmariadbclient18 libmysqlclient18 mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common mariadb-server-10.0 mariadb-server-core-10.0 Suggested packages: tinyca mariadb-test The following packages will be REMOVED: mysql-client-5.5 mysql-server-core-5.5 The following NEW packages will be installed: libmariadbclient18 mariadb-client mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common mariadb-server mariadb-server-10.0 mariadb-server-core-10.0 The following packages will be upgraded: libmysqlclient18 1 upgraded, 8 newly installed, 2 to remove and 147 not upgraded. Need to get 36.2 MB of archives. After this operation, 65.4 MB of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-common all 10.0.8+maria-1~wheezy [3,310 B] Get:2 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main libmysqlclient18 amd64 10.0.8+maria-1~wheezy [2,966 B] Get:3 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main libmariadbclient18 amd64 10.0.8+maria-1~wheezy [941 kB] Get:4 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-client-core-10.0 amd64 10.0.8+maria-1~wheezy [1,993 kB] Get:5 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-client-10.0 amd64 10.0.8+maria-1~wheezy [5,593 kB] Get:6 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-server-core-10.0 amd64 10.0.8+maria-1~wheezy [6,096 kB] Get:7 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-server-10.0 amd64 10.0.8+maria-1~wheezy [21.6 MB] Get:8 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-client all 10.0.8+maria-1~wheezy [2,874 B] Get:9 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-server all 10.0.8+maria-1~wheezy [3,004 B] Fetched 36.2 MB in 2min 8s (281 kB/s) Preconfiguring packages ... (Reading database ... 358195 files and directories currently installed.) Removing mysql-client-5.5 ... Removing mysql-server-core-5.5 ... Processing triggers for man-db ... Selecting previously unselected package mariadb-common. (Reading database ... 358053 files and directories currently installed.) Unpacking mariadb-common (from .../mariadb-common_10.0.8+maria-1~wheezy_all.deb) ... Preparing to replace libmysqlclient18:amd64 5.5.31+dfsg-0+wheezy1 (using .../libmysqlclient18_10.0.8+maria-1~wheezy_amd64.deb) ... Unpacking replacement libmysqlclient18 ... Selecting previously unselected package libmariadbclient18. Unpacking libmariadbclient18 (from .../libmariadbclient18_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-client-core-10.0. Unpacking mariadb-client-core-10.0 (from .../mariadb-client-core-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-client-10.0. Unpacking mariadb-client-10.0 (from .../mariadb-client-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-server-core-10.0. Unpacking mariadb-server-core-10.0 (from .../mariadb-server-core-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Processing triggers for man-db ... Processing triggers for menu ... Setting up mariadb-common (10.0.8+maria-1~wheezy) ... Selecting previously unselected package mariadb-server-10.0. (Reading database ... 358190 files and directories currently installed.) Unpacking mariadb-server-10.0 (from .../mariadb-server-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-client. Unpacking mariadb-client (from .../mariadb-client_10.0.8+maria-1~wheezy_all.deb) ... Selecting previously unselected package mariadb-server. Unpacking mariadb-server (from .../mariadb-server_10.0.8+maria-1~wheezy_all.deb) ... Processing triggers for man-db ... Setting up libmysqlclient18 (10.0.8+maria-1~wheezy) ... Setting up libmariadbclient18 (10.0.8+maria-1~wheezy) ... Setting up mariadb-client-core-10.0 (10.0.8+maria-1~wheezy) ... Setting up mariadb-client-10.0 (10.0.8+maria-1~wheezy) ... Setting up mariadb-server-core-10.0 (10.0.8+maria-1~wheezy) ... Setting up mariadb-server-10.0 (10.0.8+maria-1~wheezy) ... [ ok ] Stopping MariaDB database server: mysqld. 140216 21:14:37 [Note] InnoDB: The InnoDB memory heap is disabled 140216 21:14:37 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 140216 21:14:37 [Note] InnoDB: Compressed tables use zlib 1.2.7 140216 21:14:37 [Note] InnoDB: Using Linux native AIO 140216 21:14:37 [Note] InnoDB: Not using CPU crc32 instructions 140216 21:14:37 [Note] InnoDB: Initializing buffer pool, size = 128.0M 140216 21:14:37 [Note] InnoDB: Completed initialization of buffer pool 140216 21:14:37 [ERROR] InnoDB: auto-extending data file ./ibdata1 is of a different size 640 pages (rounded down to MB) than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages! 140216 21:14:37 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data! 140216 21:14:37 [ERROR] Plugin 'InnoDB' init function returned error. 140216 21:14:37 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 140216 21:14:37 [Note] Plugin 'FEEDBACK' is disabled. 140216 21:14:37 [ERROR] Missing system table mysql.roles_mapping; please run mysql_upgrade to create it [FAIL] Starting MariaDB database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed! invoke-rc.d: initscript mysql, action "start" failed. dpkg: error processing mariadb-server-10.0 (--configure): subprocess installed post-installation script returned error exit status 1 Setting up mariadb-client (10.0.8+maria-1~wheezy) ... dpkg: dependency problems prevent configuration of mariadb-server: mariadb-server depends on mariadb-server-10.0 (= 10.0.8+maria-1~wheezy); however: Package mariadb-server-10.0 is not configured yet. dpkg: error processing mariadb-server (--configure): dependency problems - leaving unconfigured Processing triggers for menu ... Errors were encountered while processing: mariadb-server-10.0 mariadb-server localepurge: Disk space freed in /usr/share/locale: 0 KiB localepurge: Disk space freed in /usr/share/man: 0 KiB localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB localepurge: Disk space freed in /usr/share/omf: 0 KiB localepurge: Disk space freed in /usr/share/doc/kde/HTML: 0 KiB Total disk space freed by localepurge: 0 KiB E: Sub-process /usr/bin/dpkg returned an error code (1) The following NEW packages will be installed: libmariadbclient18 mariadb-client mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common mariadb-server mariadb-server-10.0 mariadb-server-core-10.0 The following packages will be upgraded: libmysqlclient18 1 upgraded, 8 newly installed, 2 to remove and 147 not upgraded. Need to get 36.2 MB of archives. After this operation, 65.4 MB of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-common all 10.0.8+maria-1~wheezy [3,310 B] Get:2 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main libmysqlclient18 amd64 10.0.8+maria-1~wheezy [2,966 B] Get:3 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main libmariadbclient18 amd64 10.0.8+maria-1~wheezy [941 kB] Get:4 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-client-core-10.0 amd64 10.0.8+maria-1~wheezy [1,993 kB] Get:5 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-client-10.0 amd64 10.0.8+maria-1~wheezy [5,593 kB] Get:6 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-server-core-10.0 amd64 10.0.8+maria-1~wheezy [6,096 kB] Get:7 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-server-10.0 amd64 10.0.8+maria-1~wheezy [21.6 MB] Get:8 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-client all 10.0.8+maria-1~wheezy [2,874 B] Get:9 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-server all 10.0.8+maria-1~wheezy [3,004 B] Fetched 36.2 MB in 2min 8s (281 kB/s) Preconfiguring packages ... (Reading database ... 358195 files and directories currently installed.) Removing mysql-client-5.5 ... Removing mysql-server-core-5.5 ... Processing triggers for man-db ... Selecting previously unselected package mariadb-common. (Reading database ... 358053 files and directories currently installed.) Unpacking mariadb-common (from .../mariadb-common_10.0.8+maria-1~wheezy_all.deb) ... Preparing to replace libmysqlclient18:amd64 5.5.31+dfsg-0+wheezy1 (using .../libmysqlclient18_10.0.8+maria-1~wheezy_amd64.deb) ... Unpacking replacement libmysqlclient18 ... Selecting previously unselected package libmariadbclient18. Unpacking libmariadbclient18 (from .../libmariadbclient18_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-client-core-10.0. Unpacking mariadb-client-core-10.0 (from .../mariadb-client-core-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-client-10.0. Unpacking mariadb-client-10.0 (from .../mariadb-client-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-server-core-10.0. Unpacking mariadb-server-core-10.0 (from .../mariadb-server-core-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Processing triggers for man-db ... Processing triggers for menu ... Setting up mariadb-common (10.0.8+maria-1~wheezy) ... Selecting previously unselected package mariadb-server-10.0. (Reading database ... 358190 files and directories currently installed.) Unpacking mariadb-server-10.0 (from .../mariadb-server-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-client. Unpacking mariadb-client (from .../mariadb-client_10.0.8+maria-1~wheezy_all.deb) ... Selecting previously unselected package mariadb-server. Unpacking mariadb-server (from .../mariadb-server_10.0.8+maria-1~wheezy_all.deb) ... Processing triggers for man-db ... Setting up libmysqlclient18 (10.0.8+maria-1~wheezy) ... Setting up libmariadbclient18 (10.0.8+maria-1~wheezy) ... Setting up mariadb-client-core-10.0 (10.0.8+maria-1~wheezy) ... Setting up mariadb-client-10.0 (10.0.8+maria-1~wheezy) ... Setting up mariadb-server-core-10.0 (10.0.8+maria-1~wheezy) ... Setting up mariadb-server-10.0 (10.0.8+maria-1~wheezy) ... [ ok ] Stopping MariaDB database server: mysqld. 140216 21:14:37 [Note] InnoDB: The InnoDB memory heap is disabled 140216 21:14:37 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 140216 21:14:37 [Note] InnoDB: Compressed tables use zlib 1.2.7 140216 21:14:37 [Note] InnoDB: Using Linux native AIO 140216 21:14:37 [Note] InnoDB: Not using CPU crc32 instructions 140216 21:14:37 [Note] InnoDB: Initializing buffer pool, size = 128.0M 140216 21:14:37 [Note] InnoDB: Completed initialization of buffer pool 140216 21:14:37 [ERROR] InnoDB: auto-extending data file ./ibdata1 is of a different size 640 pages (rounded down to MB) than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages! 140216 21:14:37 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data! 140216 21:14:37 [ERROR] Plugin 'InnoDB' init function returned error. 140216 21:14:37 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 140216 21:14:37 [Note] Plugin 'FEEDBACK' is disabled. 140216 21:14:37 [ERROR] Missing system table mysql.roles_mapping; please run mysql_upgrade to create it insserv: warning: script 'K01fcron' missing LSB tags and overrides insserv: warning: script 'fcron' missing LSB tags and overrides [FAIL] Starting MariaDB database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed! invoke-rc.d: initscript mysql, action "start" failed. dpkg: error processing mariadb-server-10.0 (--configure): subprocess installed post-installation script returned error exit status 1 Setting up mariadb-client (10.0.8+maria-1~wheezy) ... dpkg: dependency problems prevent configuration of mariadb-server: mariadb-server depends on mariadb-server-10.0 (= 10.0.8+maria-1~wheezy); however: Package mariadb-server-10.0 is not configured yet. dpkg: error processing mariadb-server (--configure): dependency problems - leaving unconfigured Processing triggers for menu ... Errors were encountered while processing: mariadb-server-10.0 mariadb-server localepurge: Disk space freed in /usr/share/locale: 0 KiB localepurge: Disk space freed in /usr/share/man: 0 KiB localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB localepurge: Disk space freed in /usr/share/omf: 0 KiB localepurge: Disk space freed in /usr/share/doc/kde/HTML: 0 KiB Total disk space freed by localepurge: 0 KiB E: Sub-process /usr/bin/dpkg returned an error code (1)

3 4

[Maria-developers] Open Knowledge Base questions
by Ian Gilfillan 16 Feb '14

16 Feb '14

There are a few open questions on the Knowledge Base - some have been around a while, and it would be great if anyone can answer them: 1) Licensing question about MariaDB and dot net Connector: https://mariadb.com/kb/en/licencing-of-mariadb-and-mysql-dot-net-connector/ 2) Query on whether the MariaDB Java Client can support Java 1.5 https://mariadb.com/kb/en/java-15-and-mariadb-connector/ The answer's presumably no, but a 1-liner on why not would be nice to have 3) Another Java client query: https://mariadb.com/kb/en/client-for-mysql-zerodatetimebehaviorconverttonul… 4) A couple of Galera queries: https://mariadb.com/kb/en/asynchronous-replication-with-galera-cluster/ https://mariadb.com/kb/en/simple-cluster-two-nodes-error/ https://mariadb.com/kb/en/strange-ssl-messages-in-error-log/ thanks, ian

1 0

Re: [Maria-developers] uint6korr optimization
by Michael Widenius 16 Feb '14

16 Feb '14

Hi! >>>>> "Alexey" == Alexey Botchkov <holyfoot(a)askmonty.org> writes: Alexey> Hi, Monty. Alexey> I've looked at that part of the code, and tried to make the improved Alexey> versions of uint6korr and mi_uint6korr. Alexey> The small program attached that benchmarks these. Alexey> Depending on enabled macros it loops uint6korr, hf_uint6korr, Alexey> mi_uint6korr and hf_mi_uint6korr respectively. It performs 2 loops on Alexey> each functions first runs it once, the second - twice, so we can Alexey> calculate how much time was spent on the operation itself. Alexey> The results i got so far are: Alexey> elapsed 103 seconds on korr6-1 Alexey> elapsed 190 seconds on korr6-2 Alexey> elapsed 50 seconds on hf_korr6-1 Alexey> elapsed 79 seconds on hf_korr6-2 Alexey> elapsed 106 seconds on mi6-1 Alexey> elapsed 195 seconds on mi6-2 Alexey> elapsed 56 seconds on hf_mi6B-1 Alexey> elapsed 88 seconds on hf_mi6-2 Alexey> So the Alexey> hf_uint6korr is 3 times faster than uint6korr. Alexey> hf_mi_uint6korr is 2.8 times faster than mi_uint6korr. Alexey> You're welcome to check the code out. Thanks. What is important is to get fast versions of mi_uint3korr (Used a lot in ma_dynrec.c and gis) mi_uint4korr mi_uint5korr mi_uint6korr mi_uint7korr mi_uint8korr (Used for some variables) uint5korr uint6korr (Used a lot in Aria) uint8korr (I am including the full test so that anyone can comment upon this) ---------------------------------------------------------------------- #include <stdio.h> #include <time.h> #include <malloc.h> #define TEST_KORR6 #define TEST_HF_KORR6 #define TEST_MI6 #define TEST_HF_MI6 #define uint6korr(A) ((ulonglong)(((uint32) ((uchar) (A)[0])) + \ (((uint32) ((uchar) (A)[1])) << 8) + \ (((uint32) ((uchar) (A)[2])) << 16) + \ (((uint32) ((uchar) (A)[3])) << 24)) + \ (((ulonglong) ((uchar) (A)[4])) << 32) + \ (((ulonglong) ((uchar) (A)[5])) << 40)) #define mi_uint6korr(A) ((ulonglong)(((uint32) (((const uchar*) (A))[5])) +\ (((uint32) (((const uchar*) (A))[4])) << 8) +\ (((uint32) (((const uchar*) (A))[3])) << 16) +\ (((uint32) (((const uchar*) (A))[2])) << 24)) +\ (((ulonglong) (((uint32) (((const uchar*) (A))[1])) +\ (((uint32) (((const uchar*) (A))[0]) << 8)))) <<\ 32)) #define hf_uint6korr(A) (((ulonglong) ((uint32 *) (A))[0]) + (((ulonglong) ((uint16 *) (A))[2]) << 32)) #define hf_mi_uint6korr(src, dest) \ __asm__ ( \ "bswapq %1;" \ "mov %1, %0;" \ :"=r"(dest) \ :"r"(hf_uint6korr(src)<<16) \ : \ ) typedef unsigned long long int ulonglong; typedef unsigned int uint32; typedef unsigned char uchar; typedef unsigned short uint16; time_t t0, t1; ulonglong i; #define GM 10000000000LL #define BAS 2000000 int main() { ulonglong *pb, *pb2; char *art, *art2; ulonglong ci; art= malloc(6*BAS); pb= malloc(sizeof(ulonglong)*BAS); for (i=0; i<6*BAS; i++) art[i]= (char)i; art2= malloc(6*BAS); pb2= malloc(sizeof(ulonglong)*BAS); for (i=0; i<6*BAS; i++) art2[i]= (char)i; #ifdef TEST_KORR6 ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; pb[ci]= uint6korr(art+ci*6); ci++; } t1= time(0); printf("elapsed %d seconds on korr6-1\n", t1 - t0); ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; pb[ci]= uint6korr(art+ci*6); pb2[ci]= uint6korr(art2+ci*6); ci++; } t1= time(0); printf("elapsed %d seconds on korr6-2\n", t1 - t0); #endif /*KORR6*/ #ifdef TEST_HF_KORR6 ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; pb[ci]= hf_uint6korr(art+ci*6); ci++; } t1= time(0); printf("elapsed %d seconds on hf_korr6-1\n", t1 - t0); ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; pb[ci]= hf_uint6korr(art+ci*6); pb2[ci]= hf_uint6korr(art2+ci*6); ci++; } t1= time(0); printf("elapsed %d seconds on hf_korr6-2\n", t1 - t0); #endif /*HF_KORR6*/ #ifdef TEST_MI6 ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; pb[ci]= mi_uint6korr(art+ci*6); ci++; } t1= time(0); printf("elapsed %d seconds on mi6-1\n", t1 - t0); ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; pb[ci]= mi_uint6korr(art+ci*6); pb2[ci]= mi_uint6korr(art2+ci*6); ci++; } t1= time(0); printf("elapsed %d seconds on mi6-2\n", t1 - t0); #endif /*MI6*/ #ifdef TEST_HF_MI6 ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; hf_mi_uint6korr(art+ci*6, pb[ci]); ci++; } t1= time(0); printf("elapsed %d seconds on hf_mi6B-1\n", t1 - t0); ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; hf_mi_uint6korr(art+ci*6, pb[ci]); hf_mi_uint6korr(art2+ci*6, pb2[ci]); ci++; } t1= time(0); printf("elapsed %d seconds on hf_mi6-2\n", t1 - t0); #endif /*HF_MI6*/ return 0; } Looks ok. Did you try with: #define hf_uint6korr(A) (*((uint64 *) A) & 0xffffffffffffLL) That may be faster, with the extra cost problem of reading 2 bytes extra, so this only safe to use if one knows that there is a few extra bytes in the buffer. Can you do a patch to my_global.h and myisampack and add the new functions there. What to do: - All improvements for now only for x64 architecture - Replace uint6korr(A) and any other function that can be improved without reading extra bytes with a faster version. - Improve with faster variants: mi_uint3korr mi_uint4korr mi_uint5korr mi_uint6korr mi_uint7korr mi_uint8korr uint5korr uint6korr uint8korr If the above suggested version of uint6korr() that reads extra bytes is notable faster, add a function: uint6korr_unsafe() Which of course should map to uint6korr for other architectures. ok? Regards, Monty

4 5

[Maria-developers] Potential participation in Google Summer of Code 2014
by Colin Charles 15 Feb '14

15 Feb '14

Hi! We have applied to be part of the Google Summer of Code 2014 project, and hope to gain some new contributors. If you are on this list and think you can be a mentor for a project, please consider writing a note at: https://mariadb.com/kb/en/google-summer-of-code-2014/ I think the aim for the GSoC students code should be for 10.1 inclusion If you have any queries, don't hesitate to ask me about them, I'm happy to help. Typically mentors need about 4 hours or so per week to assist the student in seeing their project become a reality I encourage many to participate as its a rewarding experience. In 2013, we did participate, and got 3 features out of it: SQL ROLES, PCRE regular expressions, and a Kerberos authentication plugin Looking forward to seeing more happen in 2014! (here's hoping we get accepted into GSoC 2014 of course!) cheers, -colin -- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles

1 0

Re: [Maria-developers] Rev 4056: MDEV-5616 - Deadlock between CREATE/DROP FUNCTION and SELECT from view
by Sergei Golubchik 13 Feb '14

13 Feb '14

Hi, Sergey! Ok to push. A couple of comments below. On Feb 07, Sergey Vojtovich wrote: > revno: 4056 > revision-id: svoj(a)mariadb.org-20140207100451-8pnzn85pjjwvwfs4 > parent: elenst(a)wheezy-64.home-20140205102537-7ern5gfca6a6ojg3 > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 5.5-mdev5616 > timestamp: Fri 2014-02-07 14:04:51 +0400 > message: > MDEV-5616 - Deadlock between CREATE/DROP FUNCTION and SELECT from view > > Deadlock happened due to mixed lock order. > CREATE/DROP function: wrlock(THR_LOCK_udf) -> lock(LOCK_open) > SELECT from view: lock(LOCK_open) -> rdlock(THR_LOCK_udf) > > Fixed CREATE/DROP function so that LOCK_open does not intersect with > wrlock(THR_LOCK_udf). > > 10.0 is not affected: it doesn't hold LOCK_open while opening view. I'm pretty sure it'll auto-merge and nobody will remember this warning at that time. So this patch will be in 10.0. Perhaps you should add #if MYSQL_VERSION_ID > 50600 #error don't merge into 10.0 #endif ? Or, may be, it's not a big deal to have it in 10.0... > === modified file 'sql/sql_udf.cc' > --- a/sql/sql_udf.cc 2012-03-27 23:04:46 +0000 > +++ b/sql/sql_udf.cc 2014-02-07 10:04:51 +0000 > @@ -466,7 +467,11 @@ int mysql_create_function(THD *thd,udf_f > if ((save_binlog_row_based= thd->is_current_stmt_binlog_format_row())) > thd->clear_current_stmt_binlog_format_row(); > > + tables.init_one_table("mysql", 5, "func", 4, "func", TL_WRITE); I know it's a old line that you've moved and it's a matter of taste anyway, so up to you, but generally I prefer to see STRING_WITH_LEN here. It 1) makes a certain class of typos impossible; 2) documents the code, one doesn't need to think what these 4 and 5 stand for. Regards, Sergei

2 1

Re: [Maria-developers] Rev 3967: MDEV-5597 - Reduce usage of LOCK_open: LOCK_flush
by Sergei Golubchik 12 Feb '14

12 Feb '14

Hi, Sergey! On Jan 31, Sergey Vojtovich wrote: > At lp:maria/10.0 > > ------------------------------------------------------------ > revno: 3967 > revision-id: svoj(a)mariadb.org-20140131141943-fjyyih3h92lek62n > parent: svoj(a)mariadb.org-20140130124905-vy28zbs9swlpg8uq > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 10.0 > timestamp: Fri 2014-01-31 18:19:43 +0400 > message: > MDEV-5597 - Reduce usage of LOCK_open: LOCK_flush > > Replaced LOCK_flush with per-share conditional variable. > === modified file 'sql/table_cache.cc' > --- a/sql/table_cache.cc 2014-01-30 12:49:05 +0000 > +++ b/sql/table_cache.cc 2014-01-31 14:19:43 +0000 > @@ -945,6 +949,7 @@ bool tdc_remove_table(THD *thd, enum_tdc > if ((share= tdc_delete_share(db, table_name))) > { > I_P_List <TABLE, TABLE_share> purge_tables; > + uint my_refs= 1; > > mysql_mutex_lock(&LOCK_open); > /* > @@ -969,28 +974,48 @@ bool tdc_remove_table(THD *thd, enum_tdc > if (kill_delayed_threads) > kill_delayed_threads_for_table(share); > > -#ifndef DBUG_OFF > - if (remove_type == TDC_RT_REMOVE_NOT_OWN) > + if (remove_type == TDC_RT_REMOVE_NOT_OWN || > + remove_type == TDC_RT_REMOVE_NOT_OWN_KEEP_SHARE) > { > TABLE_SHARE::All_share_tables_list::Iterator it(share->tdc.all_tables); > while ((table= it++)) > + { > + my_refs++; > DBUG_ASSERT(table->in_use == thd); > + } > } > -#endif > - > - mysql_rwlock_rdlock(&LOCK_flush); > + DBUG_ASSERT(share->tdc.all_tables.is_empty() || remove_type != TDC_RT_REMOVE_ALL); > mysql_mutex_unlock(&LOCK_open); > > while ((table= purge_tables.pop_front())) > intern_close_table(table); > - mysql_rwlock_unlock(&LOCK_flush); > > - DBUG_ASSERT(share->tdc.all_tables.is_empty() || remove_type != TDC_RT_REMOVE_ALL); > - tdc_release_share(share); > + if (remove_type != TDC_RT_REMOVE_UNUSED) > + { > + /* > + Even though current thread holds exclusive metadata lock on this share > + (asserted above), concurrent FLUSH TABLES threads may be in process of > + closing unused table instances belonging to this share. E.g.: > + thr1 (FLUSH TABLES): table= share->tdc.free_tables.pop_front(); > + thr1 (FLUSH TABLES): share->tdc.all_tables.remove(table); > + thr2 (ALTER TABLE): tdc_remove_table(); > + thr1 (FLUSH TABLES): intern_close_table(table); > + > + Current remove type assumes that all table instances (except for those > + that are owned by current thread) must be closed before > + thd_remove_table() returns. Wait for such tables here. > + > + Unfortunately TABLE_SHARE::wait_for_old_version() cannot be used here > + because it waits for all table instances, whereas we have to wait only > + for those that are not owned by current thread. > + */ > + mysql_mutex_lock(&share->tdc.LOCK_table_share); > + while (share->tdc.ref_count > my_refs) > + mysql_cond_wait(&share->tdc.COND_release, &share->tdc.LOCK_table_share); > + mysql_mutex_unlock(&share->tdc.LOCK_table_share); I'm sorry, I don't understand that at all. Why my_refs is only incremented in debug builds? In non-debug builds you wait until all tables but one are closed, in debug builds you may keep more than one table opened. You wait here on a condition, how do you know there's FLUSH TABLES (or anything at all) running that will signal this condition? > + } > > - /* Wait for concurrent threads to free unused objects. */ > - mysql_rwlock_wrlock(&LOCK_flush); > - mysql_rwlock_unlock(&LOCK_flush); > + tdc_release_share(share); > > found= true; > } Regards, Sergei

2 4

[Maria-developers] MariaDB config for Akonadi - suggestions?
by Sergey Petrunia 12 Feb '14

12 Feb '14

Hi, Daniel Vratil from Akonadi (a PIM manager for KDE) has asked me at FOSDEM about optimal MariaDB configuration for Akonadi. Some specific questions: * innodb_flush_log_at_trx_commit. Currently, Akonadi uses innodb_flush_log_at_trx_commit=2 which as far as I understand can cause up to 1 second of changes to be lost. Using value of 1 (always flush on commit) should be safer, but maybe it would put an unnecessary load on the system? Akonadi's use case has a bit different idea of what load is - there is only one person making changes, but the system is likely to be a laptop where one cares about battery life, etc. * innodb_buffer_pool_size=80M. The dataset size can vary from very small to up to 1-1.5Gb. Some users have very little data and complain that 80M is too much. Does anybody have an experience with using very small innodb_buffer_pool_size? Please find the full config file below: === Akonadi configuration file === # These settings can be adjusted using $HOME/.config/akonadi/mysql-local.conf # # Based on advice by Kris Köhntopp <kris(a)mysql.com> # [mysqld] # strict query parsing/interpretation # TODO: make Akonadi work with those settings enabled # sql_mode=strict_trans_tables,strict_all_tables,strict_error_for_division_by_zero,no_auto_create_user,no_auto_value_on_zero,no_engine_substitution,no_zero_date,no_zero_in_date,only_full_group_by,pipes_as_concat # sql_mode=strict_trans_tables # DEBUGGING: # log all queries, useful for debugging but generates an enormous amount of data # log=mysql.full # log queries slower than n seconds, log file name relative to datadir (for debugging only) # log_slow_queries=mysql.slow # long_query_time=1 # log queries not using indices, debug only, disable for production use # log_queries_not_using_indexes=1 # # mesure database size and adjust innodb_buffer_pool_size # SELECT sum(data_length) as bla, sum(index_length) as blub FROM information_schema.tables WHERE table_schema not in ("mysql", "information_schema"); # NOTES: # Keep Innob_log_waits and keep Innodb_buffer_pool_wait_free small (see show global status like "inno%", show global variables) #expire_logs_days=3 #sync_bin_log=0 # Use UTF-8 encoding for tables character_set_server=utf8 collation_server=utf8_general_ci # use InnoDB for transactions and better crash recovery default_storage_engine=innodb # memory pool InnoDB uses to store data dictionary information and other internal data structures (default:1M) # Deprecated in MySQL >= 5.6.3 innodb_additional_mem_pool_size=1M # memory buffer InnoDB uses to cache data and indexes of its tables (default:128M) # Larger values means less I/O innodb_buffer_pool_size=80M # Create a .ibd file for each table (default:0) innodb_file_per_table=1 # Write out the log buffer to the log file at each commit (default:1) innodb_flush_log_at_trx_commit=2 # Buffer size used to write to the log files on disk (default:1M for builtin, 8M for plugin) # larger values means less I/O innodb_log_buffer_size=1M # Size of each log file in a log group (default:5M) larger means less I/O but more time for recovery. innodb_log_file_size=64M # # error log file name, relative to datadir (default:hostname.err) log_error=mysql.err # print warnings and connection errors (default:1) log_warnings=2 # Convert table named to lowercase lower_case_table_names=1 # Maximum size of one packet or any generated/intermediate string. (default:1M) max_allowed_packet=32M # Maximum simultaneous connections allowed (default:100) max_connections=256 # The two options below make no sense with prepared statements and/or transactions # (make sense when having the same query multiple times) # Memory allocated for caching query results (default:0 (disabled)) query_cache_size=0 # Do not cache results (default:1) query_cache_type=0 # Do not use the privileges mechanisms skip_grant_tables # Do not listen for TCP/IP connections at all skip_networking # The number of open tables for all threads. (default:64) table_open_cache=200 # How many threads the server should cache for reuse (default:0) thread_cache_size=3 # wait 365d before dropping the DB connection (default:8h) wait_timeout=31536000 # We use InnoDB, so don't let MyISAM eat up memory key_buffer_size=16K [client] default-character-set=utf8 BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

2 1

[Maria-developers] Minor glitch when doing out of tree cmake build
by Andrew McDonnell 10 Feb '14

10 Feb '14

Hi, I like to build MariaDB in a separate directory to keep the source tree clean. This works for me as follows: cd path/to/maria/source mkdir mybuildir cd mybuildir cmake .. "-DWITH_PLUGIN_ARIA=1 (etc...)" make mysql-test/mysql-test-run --suite oqgraph (etc) However when I want to use this build to create a non-MTR database as follows: MARIA_HOME=path/to/maria/source MARIA_BUILD=path/to/maria/source/mybuilddir sh $MARIA_BUILD/scripts/mysql_install_db \ --srcdir=$MARIA_HOME \ --builddir=$MARIA_BUILD \ --datadir=path/to/data --defaults-file=... This fails with FATAL ERROR: Could not find maria/source/sql/share/english/errmsg.sys Different combinations of --srcdir and --builddir produce similar but different errors. I tracked down where the files are set to to lines 263..303 of scripts/mysql_install_db.sh >From my reading of the help: --builddir=path If using --srcdir with out-of-directory builds, you will need to set this to the location of the build directory where built files reside. --srcdir=path The path to the MariaDB source directory. This option uses the compiled binaries and support files within the source tree, useful for if you don't want to install MariaDB yet and just want to create the system tables. I was able to make the install script work with the following patch === modified file 'scripts/mysql_install_db.sh' --- scripts/mysql_install_db.sh 2014-02-03 14:22:39 +0000 +++ scripts/mysql_install_db.sh 2014-02-08 11:52:52 +0000 @@ -267,7 +267,7 @@ bindir="$basedir/client" extra_bindir="$basedir/extra" mysqld="$basedir/sql/mysqld" - langdir="$srcdir/sql/share/english" + langdir="$basedir/sql/share/english" pkgdatadir="$srcdir/scripts" scriptdir="$srcdir/scripts" elif test -n "$basedir" What I dont know enough about, is whether this breaks other scenarios? any advice appreciated, thanks, Andrew -- http://blog.oldcomputerjunk.net https://launchpad.net/~andymc73 https://github.com/andymc73 Twitter: @pastcompute GPG: http://www.andrewmcdonnell.net/gpg.html

2 3

Re: [Maria-developers] Rev 4056: MDEV-5607: Query cache destroys uninitialized rwlock
by Sergei Golubchik 10 Feb '14

10 Feb '14

Hi, Sanja! On Feb 08, sanja(a)askmonty.org wrote: > ------------------------------------------------------------ > revno: 4056 > revision-id: sanja(a)askmonty.org-20140208132448-qdkkpdncnya0tr6j > parent: elenst(a)wheezy-64.home-20140205102537-7ern5gfca6a6ojg3 > committer: sanja(a)askmonty.org > branch nick: work-maria-5.5-MDEV-5607 > timestamp: Sat 2014-02-08 15:24:48 +0200 > message: > MDEV-5607: Query cache destroys uninitialized rwlock > > - Resize destroyed rw_lock twice, now it is prevented. > - Trash destroyed rw lock. > === modified file 'include/mysql/psi/mysql_thread.h' > --- a/include/mysql/psi/mysql_thread.h 2013-01-11 00:03:43 +0000 > +++ b/include/mysql/psi/mysql_thread.h 2014-02-08 13:24:48 +0000 > @@ -16,6 +16,8 @@ > #ifndef MYSQL_THREAD_H > #define MYSQL_THREAD_H > > +#include <my_valgrind.h> This is not ok. Files under include/mysql/ are Plugin API files, they should be clean from internal includes. You cannot include my_valgrind.h from there. Do it in my_pthread.h Regards, Sergei

2 1

[Maria-developers] Please merge 5.3 -> 5.5, mdev-5468
by Sergei Petrunia 10 Feb '14

10 Feb '14

Hello Igor, Your fix for mdev-5468 is the oldest fix in 5.3 that is not merged to 5.5. I've tried merging it. The changes in the code auto-merged, but after that the testsuite failed with crashes. Could you please merge mdev-5468 from 5.3 to 5.5? BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0