- discuss - lists.mariadb.org

[Maria-discuss] WSREP: BF lock wait long
by Jesus 22 Dec '17

22 Dec '17

Hi I'm getting this message almost daily or even more and I must restart the server that generates it: WSREP: BF lock wait long How can I solve this? Thanks for your help

2 3

Re: [Maria-discuss] About data encryption
by Sergei Golubchik 15 Dec '17

15 Dec '17

Hi, Cesar! On Dec 15, Cesar Hernandez wrote: > > Thanks Sergei! > > So the database is encrypted by using AES-128-CBC or AES-128-CRT, right? > Can I use AES-256-CBC? No. Each tablespace is encrypted with a different per-tablespace key. This key is 128 bit. It's generated by encrypting a random 128-bit nonce with the user-specified key. So, if you specify a 256-bit key in the file_key_manager plugin, this 256-bit key will be used to generate the 128-bit tablespace key. The tablespace itself will be encrypted using the 128-bit key. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

[Maria-discuss] About data encryption
by Cesar Hernandez 14 Dec '17

14 Dec '17

Hi Can someone tell me which algorithm uses MariaDB when using table encryption? Looking at https://mariadb.com/kb/en/library/data-at-rest-encryption/ <https://mariadb.com/kb/en/library/data-at-rest-encryption/> Seems to talk only about encryption of the key file, but not on the database data. I've been looking for a while and haven't found complete documentation about it. I've even taken a look at the MariaDB source code, in the file /storage/innobase/fil/fil0crypt.cc <http://fil0crypt.cc/> Seems the encryption is done by AES algorithm, but I'm not sure, and I don't know the key size neither the mode of operation. Thanks Cesar

2 1

[Maria-discuss] Debian 9.2 - Kytea
by Guillermo Cespedes 29 Nov '17

29 Nov '17

Hi, I'm compiling MariaDb in Debian 9.2. Is dependence on Kytea necessary? I need to compile Kytea previously. As you know, the Kytea package is no longer available in the Debian repositories. http://www.phontron.com/kytea/ <http://www.phontron.com/kytea/> https://github.com/dertin/lemp-stack-debian/blob/develop/install.sh#L105 <https://github.com/dertin/lemp-stack-debian/blob/develop/install.sh#L105> regards Guillermo Céspedes Full Stack Developer

3 2

[Maria-discuss] Mariadb-10.2.11 missing tokudb rpm
by Reinis Rozitis 29 Nov '17

29 Nov '17

Hi, the mariadb-10.2.11 release (all distros) is missing *-tokudb-engine.rpm package. Is this a build/packaging error or something more (though nothing in the Release notes)? rr

2 1

[Maria-discuss] MariaDB 10.2 now available on CentOS 6 &7 via SCL !!
by Michal Schorm 29 Nov '17

29 Nov '17

Hello everybody, In case you missed it, I just want to share an announce of availability of MariaDB 10.2 on CentOS 6 & 7 as a Software collections. Here are the announce emails from CentOS mailing list, which contains most basic howto: https://lists.centos.org/pipermail/centos-announce/2017-November/022640.html https://lists.centos.org/pipermail/centos-announce/2017-November/022642.html -- This made MariaDB 10.2 a big step closer to a new mass of users, because the standard MDB version in CentOS & RHEL is 5.5. It took quite an effort to fine-tune and perk-up the MDB 10.2 since its first attemps in Fedora, however it is always pleasure to cooperate with developers like you :) -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat

1 0

[Maria-discuss] installing mariadb using rpm
by Mark Edwards 28 Nov '17

28 Nov '17

hello - i was following an earlier thread titled: [Maria-discuss] Install MariaDB repo official Centos-7 this is the first time i have attempted an RPM install. so i decided to try it myself, using 10.2 on a new Centos7 installation created in google-console. the installation went perfectly, but now i have a question. i let mariadb generate my repo using this link: https://downloads.mariadb.org/mariadb/repositories/#mirror=jaleco&distro=Ce… and the following repo was generated: # MariaDB 10.2 CentOS repository list - created 2017-11-28 17:28 UTC # http://downloads.mariadb.org/mariadb/repositories/ [mariadb] name = MariaDB baseurl = http://yum.mariadb.org/10.2/centos7-amd64 gpgkey= https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1 my question: when i cat /proc/cpuinfo, i see the following: vendor_id : GenuineIntel model name : Intel(R) Xeon(R) CPU @ 2.30GHz and yet the repo specifies "centos7-amd64". does it matter that amd64 is being specified rather than Intel? Thank you, Mark Edwards

2 2

[Maria-discuss] Install MariaDB repo official Centos-7
by Wilmer Arambula 28 Nov '17

28 Nov '17

Hi, install MariaDB from the official repository [mariadb.org] for Centos-7: 1.- yum install MariaDB-server MariaDB-client When executing: 2.- systemctl start mariadb.service Error: Failed to start mariadb.service: Unit not found. Thks,

4 4

[Maria-discuss] MariaDB won't start after updating Fedora 26 to Fedora 27
by Bill Damage 23 Nov '17

23 Nov '17

After checking the logs I see mysqld: Can't create/write to file '/var/run/mariadb/mariadb.pid' (Errcode: 2 "No such file or directory")If I manually create this dir I can then start it ... until the next reboot. What is the correct fix to ensure its works as it did before the update please?

3 4

[Maria-discuss] ALTER TABLE removes check constraint
by Peter Laursen 22 Nov '17

22 Nov '17

Test case: CREATE TABLE checks (a INT CHECK (a>2), b INT CHECK (b>2), CONSTRAINT a_greater CHECK (a>b)); SHOW CREATE TABLE checks; ALTER TABLE `test`.`checks` CHANGE `a` `a` INT(11) NULL; SHOW CREATE TABLE checks; /' -- and now one constraint is gone! CREATE TABLE `checks` ( `a` int(11) DEFAULT NULL, `b` int(11) DEFAULT NULL CHECK (`b` > 2), CONSTRAINT `a_greater` CHECK (`a` > `b`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 */ This docs page https://mariadb.com/kb/en/library/constraint/ does not say that (unnamed) CHECK constraints (ie. defined "column-wise") may be removed like this. In this case the ALTER changes one column to what it already was and still the CONSTRAINT is removed. A more realistic scenario is that someone has an INT column that is about to overflow and wants to change it to a BIGINT. I am not sure if this is an oversight/a bug or not. But if it is not, I think the docs page should clearly state that "an unnamed CHECK constraint is droppped implicitly when an ALTER TABLE statement is executed and this ALTER TABLE statement references the particular column and the ALTER TABLE statement does not recreate the CONSTRAINT". There will be other cases where such ALTER TABLE would violate the CONSTRAINT due to already existing data. Wasn't it better if the ALTER TABLE failed then, rather than dropping the CONSTRAINT? What do standards say? How do other RDBMS behave with this? Does somebody know more about this? What say? -- Peter -- Webyog

3 5