- discuss - lists.mariadb.org

[Maria-discuss] gtid and current_pos vs slave_pos
by mariadb＠Biblestuph.com 24 Apr '19

24 Apr '19

I have four servers all running 10.3 as follows: A <=> B => C => D where server_ids are: A => 301 B => 302 C => 303 D => 304 I.E., A is a master to B, B is a master to A, B is also a master to C, and C is a master to D. In addition to their actual replicating DBs, all four servers also have a "norep" DB that is used to create temporary tables for local report processing (as well as any other possible writes we might want to make locally without affecting the slave chain). Historically we've prevented replication for the norep DB via: replicate_ignore_db = mysql,norep replicate_wild_ignore_table = mysql.%,norep.% Which is set as such on all four servers (the replicate_do and binlog_do/ignore flavor of filters are all unset). Writes to the A and B servers are programmatically controlled such that only one of the two servers will accept writes at any given moment. Server D writes binlogs for potential backup/disaster recovery, but has no attached slave. All that in mind, looking at the binary logs on D, I see this statement: # at 51363132 #190423 9:07:51 server id 302 end_log_pos 51363170 GTID 1-302-47886064 ddl /*!100001 SET @@session.server_id=302*//*!*/; /*!100001 SET @@session.gtid_seq_no=47886064*//*!*/; # at 51363170 #190423 9:07:51 server id 302 end_log_pos 51363324 Query thread_id=345449 exec_time=1800 error_code=0 SET TIMESTAMP=1556024871/*!*/; SET @@session.pseudo_thread_id=345449/*!*/; DROP TEMPORARY TABLE IF EXISTS `norep`.`locations` /* generated by server */ /*!*/; How is it that that statement made it all the way through to server D from B? Shouldn't it have been filtered out by server C? Next, I'm reading up on gtid-based replication with the thought that I would love to be able to do things like bring down C for maintenance and temporarily point D to B. I read the docs here: https://mariadb.com/kb/en/library/gtid/ however, in looking at the actual binary logs of the servers they don't seem to reflect the explanations that I read there especially in regards to gtid_current_pos vs. gtid_slave_pos. Specifically, when I look at the gtid_slave_pos on server D, which I thought was only supposed to reflect transactions that were actually replicated, I sometimes see statements coming from server C; these are temporary tables being written into norep on C. They are not actually replicating on D (at least as far as I can tell), and they don't show up D's binary log. So why would they be reflected in D's gtid_slave_pos? For example, just a moment ago SELECT @@GLOBAL.gtid_slave_pos on D showed this: 1-303-48758339 This transaction does not appear in D's binlog, which I would expect since it should not in fact actually be replicated. But because it is reflected in gtid_slave_pos, it seems to me that in my setup I cannot reliably use gtid_current_pos or gtid_slave_pos, since either may at any given time point to an entry on C that of course won't exist on B should I ever want to redirect D to B. Am I missing or mis-understanding something here? Cheers, Dan

4 5

[Maria-discuss] How do I determine if versions of phpMyAdmin before 4.8.5 is SQL Injectable using sqlmap?
by Turritopsis Dohrnii Teo En Ming 17 Apr '19

17 Apr '19

Subject/Topic: How do I determine if versions of phpMyAdmin before 4.8.5 is SQL Injectable using sqlmap? Good evening from Singapore, Our customer (company name is Confidential/not disclosed) reported that their MySQL database has been found missing or was deleted a few times. They are using Ubuntu 16.04 LTS Linux server with Apache2 Web Server, MySQL and PHP (LAMP). We responded to these security incidents by changing the passwords of the regular user, root user, and MySQL database user root. We have also examined /var/log/auth.log and think that the hacker could not have come in through ssh or sftp over ssh. From /var/log/mysql/error.log, we can ascertain that the MySQL database has been deleted at certain timings. We have also found nothing abnormal after examining /var/log/apache2/access.log. Even though we have secured the Ubuntu Linux server by changing passwords, the hacker was still able to delete our customer's MySQL database again and again. I have already proposed to install ModSecurity Open Source Web Application Firewall (WAF) to defend against web application attacks but my boss has told me to put that on hold at the moment. In fact, I have already deployed ModSecurity 2.9.0 on a Ubuntu 16.04 LTS *Testing* server and found that it actively detects and logs Nessus and sqlmap vulnerability scans in blocking mode. Since we did not find any evidence that the hacker had breached our customer's Ubuntu 16.04 LTS production server through ssh or Teamviewer, we suspect that the hacker could have achieved it by SQL injection. I took the initiative of downloading and installing Nessus Professional 8.3.1 Trial version for Windows 64-bit. The vulnerability scan report generated by Nessus Web Application Tests shows that our customer is using a version of phpMyAdmin prior to 4.8.5 which could be vulnerable to SQL injection using the designer feature. Further research shows that I can use sqlmap to determine if phpMyAdmin is SQL injectable. I already have a Testing Ubuntu 16.04 LTS Linux server with a Testing MySQL database and a Testing phpMyAdmin 4.8.4. I have purposely installed phpMyAdmin 4.8.4 because this version was reported to be vulnerable to SQL injection using the designer feature, and our customer is using a vulnerable version, according to CVE-2019-6798 ( https://nvd.nist.gov/vuln/detail/CVE-2019-6798 ). Then I proceeded to download and execute sqlmap on our Ubuntu Linux desktop against our Testing server. No matter how many commands I try, sqlmap always report that phpMyAdmin 4.8.4 is *NOT* SQL injectable. Perhaps I was using the wrong sqlmap commands all the time? The following is one of the many sqlmap commands I have used. $ python sqlmap.py -u "https://www.EXAMPLE.com/phymyadmin/index.php?id=1" --level=1 --dbms=mysql --sql-query="drop database" Replace database by database name. May I know what is the correct sqlmap command that I should use to determine that my Testing phpMyAdmin 4.8.4 is SQL injectable? I would like to know if I can successfully drop/delete the Testing database on our Testing server. If I can successfully drop/delete the Testing MySQL database using sqlmap, I would be able to conclude that the hacker must have carried out SQL injection to drop/delete the customer's database. I have already turned off the Testing ModSecurity Web Application Firewall on our Testing server to allow sqlmap to go through. Please point me to any good tutorial on SQL injection using sqlmap. Maybe I do not understand SQL injection well enough. Our customer is also using a customised in-house inventory management system that relies on PHP application and MySQL database. Would open source Snort Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) be able to detect and block SQL injection as well? Please advise. Thank you very much. -----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 [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -----END EMAIL SIGNATURE-----

3 10

[Maria-discuss] Strange timestamp index behaviour / bug
by Reinis Rozitis 03 Apr '19

03 Apr '19

Hello, before reporting it as bug I wanted to understand what's really going on or how to investigate it further: Because of the DST changes we experienced a strange issue where afterwards a query suddenly wouldn't use an index on a timestamp column anymore and would do a full tablescan and because of the table size literally brought down the db. The table itself is more complex but I could simplify it down to: CREATE TABLE `tmp` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `ts` timestamp NOT NULL DEFAULT current_timestamp(), PRIMARY KEY (`id`), KEY `ts_2` (`ts`) ) ENGINE=InnoDB CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; (the original table is TokuDB but the same behavior happens also on InnoDB / Server Mariadb 10.3.13): And the issue is: MariaDB [db]> explain select * from tmp where `ts` > '2019-03-31 03:00:00'; +------+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+ | 1 | SIMPLE | tmp | index | ts_2 | ts_2 | 4 | NULL | 1000 | Using where; Using index | +------+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+ While actually: MariaDB [db]> select count(*) from tmp where `ts` > '2019-03-31 03:00:00'; +----------+ | count(*) | +----------+ | 175 | +----------+ So either the sql optimizer or the engine does something strange. While for example: MariaDB [db]> explain select * from tmp where `ts` > '2019-03-31 04:00:00'; +------+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+ | 1 | SIMPLE | tmp | range | ts_2 | ts_2 | 4 | NULL | 175 | Using where; Using index | +------+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+ .. works as expected. The data is basically (just missing the 3:xx because of the clock spin): | 35458195 | 2019-03-31 02:55:44 | | 35458196 | 2019-03-31 02:55:45 | | 35458197 | 2019-03-31 02:56:37 | | 35458198 | 2019-03-31 02:59:16 | | 35458199 | 2019-03-31 02:59:39 | | 35458200 | 2019-03-31 04:01:42 | | 35458201 | 2019-03-31 04:02:59 | | 35458202 | 2019-03-31 04:04:02 | | 35458203 | 2019-03-31 04:04:26 | | 35458204 | 2019-03-31 04:04:38 | In the Innodb case the explain while showing that it will return all rows (the test table has 1000) also showing that it will use the 'ts_2' index on the original tokudb table it won't use the index even forced: MariaDB [db]> explain select * from twitt_ext_posts_url where `ts` > '2019-03-31 04:00:00'; +------+-------------+---------------------+-------+---------------+------+---------+------+-------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+---------------------+-------+---------------+------+---------+------+-------+-------------+ | 1 | SIMPLE | twitt_ext_posts_url | range | ts_2 | ts_2 | 4 | NULL | 42444 | Using where | +------+-------------+---------------------+-------+---------------+------+---------+------+-------+-------------+ .. works again fine, but: MariaDB [db]> explain select * from twitt_ext_posts_url where `ts` > '2019-03-31 03:00:00'; +------+-------------+---------------------+------+---------------+------+---------+------+----------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+---------------------+------+---------------+------+---------+------+----------+-------------+ | 1 | SIMPLE | twitt_ext_posts_url | ALL | ts_2 | NULL | NULL | NULL | 28547845 | Using where | +------+-------------+---------------------+------+---------------+------+---------+------+----------+-------------+ MariaDB [db]> explain select * from twitt_ext_posts_url force index(ts_2) where `ts` > '2019-03-31 03:00:00'; +------+-------------+---------------------+------+---------------+------+---------+------+----------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+---------------------+------+---------------+------+---------+------+----------+-------------+ | 1 | SIMPLE | twitt_ext_posts_url | ALL | ts_2 | NULL | NULL | NULL | 28547872 | Using where | +------+-------------+---------------------+------+---------------+------+---------+------+----------+-------------+ Is this to be expected or a bug? Should a gap in index values drop the index use for range queries? Is there anything else I need to add to the report? rr

3 3

[Maria-discuss] required mysql_upgrade; MDEV-14637
by Michal Schorm 03 Apr '19

03 Apr '19

Hello, I have a questions regarding the warnings showing up at 10.2 and 10.3 releases: When upgrading from MariaDB 10.2.16 or earlier to MariaDB 10.2.17 or higher, running mysql_upgrade is required due to changes introduced in MDEV-14637. When upgrading from MariaDB 10.3.8 or earlier to MariaDB 10.3.9 or higher, running mysql_upgrade is required due to changes introduced in MDEV-14637. -- 1) The same applies for upgrading <=10.2.16 to >= 10.3.9, right? 2) Does it mean, it is impossible to use "dump and restore" technique, or it only means I need to run the mysql_upgrade afterwards? 3) The problem is not triggered when upgrading from 5.5, 10.0 and 10.1? 4) The problem is not triggered when upgrading to 10.4 ? -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat --

4 7

[Maria-discuss] Row vs Statement Replication in 10.3
by mariadb＠biblestuph.com 02 Apr '19

02 Apr '19

Using binlog-format=MIXED I'm trying to get my head around why certain statements are being written as RBR instead of as a statement. On my 10.3 test server running a fraction of my full load binary logs are getting written to the tune of about 30M/minute (the 5.5 production server with a currently much heavier load writes about 8.5M/minute). All of the tables are currently MyISAM. Here's a couple examples: This always gets written as a statement in 10.3: UPDATE mydb.t1 SET rundate = '2019-03-28 23:04:00' , runtime = UTC_TIMESTAMP() , runstatus = 1 WHERE hostname = 'my.host.com' While this always gets written as a row: UPDATE mydb.t1 SET rundate = '2019-03-28 23:04:00' , runtime = UTC_TIMESTAMP() , runstatus = 10 WHERE hostname = 'my.host.com' If it matters, runstatus (the only difference in the two) is a TINYINT(3) UNSIGNED NOT NULL DEFAULT 0. Both statements are written as statements in 5.5. And this one always gets written as RBR on 10.3, but I don't see why. I reviewed the information at https://mariadb.com/kb/en/library/unsafe-statements-for-statement-based-rep… but can't seem to see what is triggering it. UPDATE mydb.t1 AS i LEFT JOIN mydb.t2 AS j1 ON ( i.f1 = j1.f1 ) LEFT JOIN mydb.t3 AS j2 ON ( i.f1 = j2.f1 AND i.f2 > 0 AND i.f2 = j2.f2 ) SET i.f3 = IF ( i.f2 < 0, IF ( j1.f3 IS NULL, i.f3, j1.f3 ), IF ( j2.f3 IS NULL, i.f3, j2.f3 ) ) , i.f4 = IF ( i.f2 < 0, IF ( j1.f3 IS NULL, i.f4, j1.f3 ), IF ( j2.f3 IS NULL, i.f4, j2.f3 ) ) WHERE i.f5 != 0 AND i.f2 != 0 AND i.f6 = 1 AND i.f7 = 0 The 10.3 logs don't offer anything by way of explanation, presumably because I have it set to MIXED. Looking at it I see I can use a COALESCE instead of the inner IFs, but I'm still unclear why it must be row-based. Thanks, Dan

3 5

[Maria-discuss] install plugin “if not installed”?
by Felipe Gasper 30 Mar '19

30 Mar '19

Hello, Is there any way to install a plugin via SQL but to trap the error that comes up if the plugin is already installed? I’d like to do it without creating a “throwaway” procedure, if that’s possible. Thank you! -Felipe Gasper Mississauga, Ontario

2 1

[Maria-discuss] auth_socket.so on upgrade 5.7 -> 10.2
by Felipe Gasper 29 Mar '19

29 Mar '19

Hello, Is mysql_upgrade meant to facilitate a migration from auth_socket.so to MariaDB’s unix_socket.so? I just tried to upgrade 5.7 to 10.2 and found root@localhost (which was set up to use MySQL auth_socket.so) was no longer able to connect because “ERROR 1524 (HY000): Plugin 'auth_socket' is not loaded”. -FG

2 1

[Maria-discuss] question on how to get test working on Windows for mariadb server....
by Luuk 28 Mar '19

28 Mar '19

After noticing that a bug i reported was set to 'solved' i wanted to see/check that. So, i downloaded/compiled Now i seem to be able to run the server, but i am unable to connect using 'mysql.exe' Luuk@ZES MINGW64 /d/TEMP/server (master) $ bld/client/RelWithDebInfo/mysqladmin -h localhost -u root version D:\TEMP\server\bld\client\RelWithDebInfo\mysqladmin.exe Ver 9.1 Distrib 10.4.4-MariaDB, for Win32 on AMD64 Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Server version 10.4.4-MariaDB Protocol version 10 Connection localhost via TCP/IP TCP port 3306 Uptime: 23 min 15 sec Threads: 7 Questions: 4 Slow queries: 0 Opens: 16 Flush tables: 1 Open tables: 10 Queries per second avg: 0.002 Luuk@ZES MINGW64 /d/TEMP/server (master) $ bld/client/RelWithDebInfo/mysql -h localhost -u root #### no reaction, killin 'mysql.exe' just add another 'Aborted connection' to the server-log.... QUESTION: What am i missing here? The log from the server (Windows 10): Luuk@ZES MINGW64 /d/TEMP/server/bld (master) $ sql/RelWithDebInfo/mysqld.exe --console 2019-03-24 16:20:01 0 [Note] D:\TEMP\server\bld\sql\RelWithDebInfo\mysqld.exe (mysqld 10.4.4-MariaDB) starting as process 2024 ... 2019-03-24 16:20:01 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions 2019-03-24 16:20:01 0 [Note] InnoDB: Uses event mutexes 2019-03-24 16:20:01 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2019-03-24 16:20:01 0 [Note] InnoDB: Number of pools: 1 2019-03-24 16:20:01 0 [Note] InnoDB: Using SSE2 crc32 instructions 2019-03-24 16:20:01 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M 2019-03-24 16:20:01 0 [Note] InnoDB: Completed initialization of buffer pool 2019-03-24 16:20:01 0 [Note] InnoDB: 128 out of 128 rollback segments are active. 2019-03-24 16:20:01 0 [Note] InnoDB: Creating shared tablespace for temporary tables 2019-03-24 16:20:01 0 [Note] InnoDB: Setting file '.\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2019-03-24 16:20:01 0 [Note] InnoDB: File '.\ibtmp1' size is now 12 MB. 2019-03-24 16:20:01 0 [Note] InnoDB: Waiting for purge to start 2019-03-24 16:20:01 0 [Note] InnoDB: 10.4.4 started; log sequence number 139881; transaction id 21 2019-03-24 16:20:01 0 [Note] InnoDB: Loading buffer pool(s) from D:\TEMP\server\bld\sql\data\ib_buffer_pool 2019-03-24 16:20:01 0 [Note] Plugin 'FEEDBACK' is disabled. 2019-03-24 16:20:01 0 [Note] InnoDB: Buffer pool(s) load completed at 190324 16:20:01 2019-03-24 16:20:01 0 [Note] Server socket created on IP: '::'. 2019-03-24 16:20:01 0 [Note] Reading of all Master_info entries succeded 2019-03-24 16:20:01 0 [Note] Added new Master_info '' to hash table 2019-03-24 16:20:01 0 [Note] D:\TEMP\server\bld\sql\RelWithDebInfo\mysqld.exe: ready for connections. Version: '10.4.4-MariaDB' socket: '' port: 3306 Source distribution 2019-03-24 16:21:24 8 [Warning] Aborted connection 8 to db: 'unconnected' user: 'root' host: 'localhost' (Got an error reading communication packets) 2019-03-24 16:21:49 9 [Warning] Aborted connection 9 to db: 'unconnected' user: 'root' host: 'localhost' (Got an error reading communication packets)

1 0

[Maria-discuss] Why does local root need a password?
by Felipe Gasper 27 Mar '19

27 Mar '19

Hello, I’ve submitted a proposal to the MySQL team to allow the system administrator, when logging in via a local socket that indicates reliably that the DB client is the superuser (e.g., SO_PEERCRED in Linux), to not need a password. As implemented, my suggestion allows root to log in as any user. The rationale is that the system administrator can do anything on the server (including manual edits to the DB files) anyway; thus, every user already implicitly trusts that user with their data. This will simplify DB administration on several levels, but most conspicuously because a lost DB admin password will no longer necessitate the awkward one-time-init-file recovery method. Would MariaDB be interested in this proposal? -FG

6 8

Re: [Maria-discuss] [MariaDB Announce] MariaDB 10.2.23 and MariaDB Connector/J 2.4.1 now available
by Reindl Harald 26 Mar '19

26 Mar '19

congratulations, again a point update which just don't compile frankly what about RC announcements so that idiots like me building packages from source can point out such issues *before* official announcements? [ 92%] Building CXX object sql/CMakeFiles/sql.dir/sql_plugin.cc.o [ 92%] Building CXX object sql/CMakeFiles/sql.dir/sql_prepare.cc.o [ 92%] Building CXX object sql/CMakeFiles/sql.dir/sql_rename.cc.o /home/builduser/rpmbuild/BUILD/mariadb-10.2.23/sql/sql_parse.cc: In function 'int mysql_execute_command(THD*)': /home/builduser/rpmbuild/BUILD/mariadb-10.2.23/sql/sql_parse.cc:3515:16: error: 'class THD' has no member named 'profiling' thd->profiling.discard_current_query(); cmake . \ -DFEATURE_SET="large" \ -DCMAKE_INSTALL_PREFIX="%{_prefix}" \ -DINSTALL_INCLUDEDIR=include/mysql \ -DINSTALL_LAYOUT=RPM \ -DDAEMON_NAME="mysqld" \ -DDAEMON_NO_PREFIX="mysqld" \ -DNICE_PROJECT_NAME="MariaDB" \ -DINSTALL_LIBDIR="%{_lib}/mysql" \ -DINSTALL_MANDIR=share/man \ -DINSTALL_MYSQLSHAREDIR=share/mysql \ -DINSTALL_MYSQLTESTDIR=share/mysql-test \ -DINSTALL_PLUGINDIR="%{_lib}/mysql/plugin" \ -DINSTALL_SBINDIR=libexec \ -DINSTALL_SCRIPTDIR=bin \ -DINSTALL_SQLBENCHDIR= \ -DINSTALL_SUPPORTFILESDIR=share/mysql \ -DMYSQL_DATADIR="%{_sharedstatedir}/mysql" \ -DMYSQL_UNIX_ADDR="%{_sharedstatedir}/mysql/mysql.sock" \ -DENABLED_PROFILING=OFF \ -DENABLE_DEBUG_SYNC=OFF \ -DENABLE_DTRACE=OFF \ -DPLUGIN_ARIA=YES \ -DPLUGIN_CSV=YES \ -DPLUGIN_MYISAM=YES \ -DPLUGIN_ARCHIVE=NO \ -DPLUGIN_BLACKHOLE=NO \ -DPLUGIN_CASSANDRA=NO \ -DPLUGIN_CONNECT=NO \ -DPLUGIN_EXAMPLE=NO \ -DPLUGIN_FEDERATED=NO \ -DPLUGIN_FEDERATEDX=NO \ -DPLUGIN_FEEDBACK=NO \ -DPLUGIN_MROONGA=NO \ -DPLUGIN_MYISAMMRG=NO \ -DPLUGIN_OQGRAPH=NO \ -DPLUGIN_PARTITION=NO \ -DPLUGIN_PERFSCHEMA=NO \ -DPLUGIN_ROCKSDB=NO \ -DPLUGIN_SEMISYNC=NO \ -DPLUGIN_SEQUENCE=NO \ -DPLUGIN_SPHINX=NO \ -DPLUGIN_SPIDER=NO \ -DPLUGIN_TOKUDB=NO \ -DPLUGIN_XTRADB=NO \ -DWITHOUT_DYNAMIC_PLUGINS=ON \ -DWITH_ATOMIC_OPS=smp \ -DWITH_EMBEDDED_SERVER=OFF \ -DWITH_INNODB_DISALLOW_WRITES=OFF \ -DWITH_INNODB_BZIP2=OFF \ -DWITH_INNODB_LZ4=OFF \ -DWITH_INNODB_LZMA=OFF \ -DWITH_INNODB_LZO=OFF \ -DWITH_INNODB_SNAPPY=OFF \ -DWITH_MYSQLCOMPAT=ON \ -DSECURITY_HARDENED=OFF \ -DWITH_LIBARCHIVE=OFF \ -DWITH_LIBWRAP=OFF \ -DWITH_MARIABACKUP=OFF \ -DWITH_PIC=NO \ -DWITH_READLINE=OFF \ -DWITH_SAFEMALLOC=OFF \ -DWITH_VALGRIND=OFF \ -DWITH_WSREP=OFF \ -DWITH_JEMALLOC=OFF \ -DWITH_SSL=system \ -DWITH_ZLIB=system Am 25.03.19 um 22:28 schrieb MariaDB Announce List: > The MariaDB Foundation is pleased to announce the availability > of MariaDB 10.2.23, the latest stable release in the MariaDB > 10.2 series, as well as MariaDB Connector/J 2.4.1, the latest > stable MariaDB Connector/J release. > > See the Release Notes and Changelogs for details. > > > - - Links - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > MariaDB 10.2.23 > - Release Notes: https://mariadb.com/kb/en/mdb-10223-rn/ > - Changelog: https://mariadb.com/kb/en/mdb-10223-cl/ > - Downloads: https://downloads.mariadb.org/mariadb/10.2.23 > > About MariaDB 10.2: > - https://mariadb.com/kb/en/what-is-mariadb-102/ > > APT and YUM Repository Configuration Generator: > - https://downloads.mariadb.org/mariadb/repositories/ > > > MariaDB Connector/J 2.4.1 > - Release Notes: https://mariadb.com/kb/en/mcj-241-rn/ > - Changelog: https://mariadb.com/kb/en/mcj-241-cl/ > - Downloads: https://downloads.mariadb.org/connector-java/2.4.1/ > > - - MariaDB Books - - - - - - - - - - - - - - - - - - - - - - - - - - > > There is an ever-growing library of MariaDB books available to help > you get the most out of MariaDB. See the MariaDB Books page for > details and links: > > - https://mariadb.org/learn/books/ > > > - - User Feedback plugin - - - - - - - - - - - - - - - - - - - - - - - > > MariaDB includes a User Feedback plugin. This plugin is disabled by > default. If enabled, it submits basic, completely anonymous MariaDB > usage information. This information is used by the developers to > track trends in MariaDB usage to better guide development efforts. > > If you would like to help make MariaDB better, please add > "feedback=ON" to your my.cnf or my.ini file! > > See http://mariadb.com/kb/en/user-feedback-plugin for more > information. > > > - - Quality - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > The project always strives for quality, but in reality, nothing is > perfect. Please take time to report any issues you encounter at: > > - http://jira.mariadb.org > > Note that the bug tracker is not a support channel. If you are > running MariaDB in an enterprise environment, please consider paying > for support and related services from a commercial company: > > - https://mariadb.org/about/service-providers/ > > MariaDB is a true open source project. We welcome everyone's > contributions, be it by testing, submitting good bug reports, > debugging and writing code, writing documentation or in any other > way that helps to make the MariaDB server and related > software ever better.

2 2