Why you should take care of MySQL data types

May 25, 2016, 2:42 am

≫ Next: MySQL spatial functionality - points of interest around me

≪ Previous: MariaDB 10.2 Window Function Examples

A customer reported last month that MySQL does a full table scan (FTS) if a query was filtered by a INT value on a VARCHAR column. First I told him that this is not true any more because MySQL has fixed this behaviour long time ago. He showed me that I was wrong:

CREATE TABLE `test` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `data` varchar(64) DEFAULT NULL,
  `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `data` (`data`)
) ENGINE=InnoDB;

EXPLAIN SELECT * FROM test WHERE data = 42\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: test
   partitions: NULL
         type: ALL
possible_keys: data
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 522500
     filtered: 10.00
        Extra: Using where

EXPLAIN SELECT * FROM test WHERE data = '42'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: test
   partitions: NULL
         type: ref
possible_keys: data
          key: data
      key_len: 67
          ref: const
         rows: 1
     filtered: 100.00
        Extra: NULL

When I executed the query I got some more interesting information:

SELECT * FROM test WHERE data = '42';
Empty set (0.00 sec)

SELECT * FROM test WHERE data = 42;
+--------+----------------------------------+---------------------+
| id     | data                             | ts                  |
+--------+----------------------------------+---------------------+
|   1096 | 42a5cb4a3e76857a3efe7af44ba9f4dd | 2016-05-25 10:26:59 |
...
| 718989 | 42a1921fb2df42126d85f9586532eda4 | 2016-05-25 10:27:12 |
+--------+----------------------------------+---------------------+
767 rows in set, 65535 warnings (0.26 sec)

Looking at the warnings we also find the reason: MySQL does the cast on the column and not on the value which is a bit odd IMHO:

show warnings;
| Warning | 1292 | Truncated incorrect DOUBLE value: '80f52706c2f9de40472ec29a7f70c992' |

A bit suspicious I looked at the warnings of the query execution plan again:

show warnings;
+---------+------+---------------------------------------------------------------------------------------------+
| Level   | Code | Message                                                                                     |
+---------+------+---------------------------------------------------------------------------------------------+
| Warning | 1739 | Cannot use ref access on index 'data' due to type or collation conversion on field 'data'   |
| Warning | 1739 | Cannot use range access on index 'data' due to type or collation conversion on field 'data' |
+---------+------+---------------------------------------------------------------------------------------------+

I thought this was fixed, but it seems not. The following releases behave like this: MySQL 5.0.96, 5.1.73, 5.5.38, 5.6.25, 5.7.12 and MariaDB 5.5.41, 10.0.21 and 10.1.9

The other way around it seems to work in both cases:

SELECT * FROM test WHERE id = 42;
+----+----------------------------------+---------------------+
| id | data                             | ts                  |
+----+----------------------------------+---------------------+
| 42 | 81d74057d7be8f20563da404bb1b3ab0 | 2016-05-25 10:26:56 |
+----+----------------------------------+---------------------+

SELECT * FROM test WHERE id = '42';
+----+----------------------------------+---------------------+
| id | data                             | ts                  |
+----+----------------------------------+---------------------+
| 42 | 81d74057d7be8f20563da404bb1b3ab0 | 2016-05-25 10:26:56 |
+----+----------------------------------+---------------------+

EXPLAIN SELECT * FROM test WHERE id = 42\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: test
   partitions: NULL
         type: const
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: const
         rows: 1
     filtered: 100.00
        Extra: NULL

Taxonomy upgrade extras:

↧

MySQL spatial functionality - points of interest around me

June 1, 2016, 1:13 am

≫ Next: Temporary tables and MySQL STATUS information

≪ Previous: Why you should take care of MySQL data types

This week I was preparing the exercises for our MySQL/MariaDB for Beginners training. One of the exercises of the training is about MySQL spatial (GIS) features. I always tell customers: "With these features you can answer questions like: Give me all points of interest around me!"

Now I wanted to try out how it really works and if it is that easy at all...

To get myself an idea of what I want to do I did a little sketch first:

	My position
	Shops
	Restaurants
	Cafes

To do this I needed a table and some data:

CREATE TABLE poi (
  id INT UNSIGNED NOT NULL AUTO_INCREMENT
, name VARCHAR(40)
, type VARCHAR(20)
, sub_type VARCHAR(20)
, pt POINT NOT NULL
, PRIMARY KEY (id)
, SPATIAL INDEX(pt)
) ENGINE=InnoDB;

INSERT INTO poi (name, type, sub_type, pt) VALUES
  ('Shop 1', 'Shop', 'Cloth', Point(2,2))
, ('Cafe 1', 'Cafe', '',  Point(11,2))
, ('Shop 2', 'Shop', 'Cloth',  Point(5,4))
, ('Restaurant 1', 'Restaurant', 'Portugies',  Point(8,7))
, ('Cafe 2', 'Cafe', '',  Point(3,9))
, ('Shop 3', 'Shop', 'Hardware',  Point(11,9))
;

This looks as follows:

SELECT id, CONCAT(ST_X(pt), '/', ST_Y(pt)) AS "X/Y", name, type, sub_type
  FROM poi;
+----+-----------+--------------+------------+-----------+
| id | X/Y       | name         | type       | sub_type  |
+----+-----------+--------------+------------+-----------+
|  1 | 2/2       | Shop 1       | Shop       | Cloth     |
|  2 | 11/2      | Cafe 1       | Cafe       |           |
|  3 | 5/4       | Shop 2       | Shop       | Cloth     |
|  4 | 8/7       | Restaurant 1 | Restaurant | Portugies |
|  5 | 3/9       | Cafe 2       | Cafe       |           |
|  6 | 11/9      | Shop 3       | Shop       | Hardware  |
+----+-----------+--------------+------------+-----------+

Now the question: "Give me all shops in a distance of 4.5 units around me":

SET @hereami = POINT(9,4);

SELECT id, ST_AsText(pt) AS point, name, ROUND(ST_Distance(@hereami, pt), 2) AS distance
  FROM poi
 WHERE ST_Distance(@hereami, pt) < 4.5
   AND type = 'Shop'
 ORDER BY distance ASC
;
+----+------------+--------+----------+
| id | point      | name   | distance |
+----+------------+--------+----------+
|  3 | POINT(5 4) | Shop 2 |     4.00 |
+----+------------+--------+----------+
1 row in set (0.37 sec)

The query execution plan looks like this:

           id: 1
  select_type: SIMPLE
        table: poi
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 650361
     filtered: 10.00
        Extra: Using where; Using filesort

So no use of the spatial index yet. :-(

Reading the MySQL documentation Using Spatial Indexes provides some more information:

The optimizer investigates whether available spatial indexes can be involved in the search for queries that use a function such as MBRContains() or MBRWithin() in the WHERE clause.

So it looks like the optimizer CAN evaluate function covered fields in this specific case. But not with the function ST_Distance I have chosen.

So my WHERE clause must look like: "Give me all points within a polygon spanned 4.5 units around my position..."

I did not find any such function in the short run. So I created a hexagon which is not too far from a circle...

With this hexagon I tried again:

SET @hereami = POINT(9,4);
SET @hexagon = 'POLYGON((9 8.5, 12.897 6.25, 12.897 1.75, 9 -0.5, 5.103 1.75, 5.103 6.25, 9 8.5))';

SELECT id, ST_AsText(pt) AS point, name, ROUND(ST_Distance(@hereami, pt), 2) AS distance
  FROM poi
 WHERE MBRContains(ST_GeomFromText(@hexagon), pt)
   AND ST_Distance(@hereami, pt) < 4.5
   AND type = 'Shop'
 ORDER BY distance ASC
;
Empty set (0.03 sec)

And tadaaah: Damned fast, but the result is not the same! :-( When you look at the graph above it is obvious why: The missing shop is 0.103 units outside of our hexagon search range but within our circle range. So an octagon would have been the better approach...

At least the index is considered now! :-)

           id: 1
  select_type: SIMPLE
        table: poi
   partitions: NULL
         type: range
possible_keys: pt
          key: pt
      key_len: 34
          ref: NULL
         rows: 31356
     filtered: 10.00
        Extra: Using where; Using filesort

For specifying a an "outer" hexagon I was too lazy. So I was specifying a square:

SET @hereami = POINT(9,4);
SET @square = 'POLYGON((4.5 8.5, 13.5 8.5, 13.5 -0.5, 4.5 -0.5, 4.5 8.5))';

SELECT id, ST_AsText(pt) AS point, name, ROUND(ST_Distance(@hereami, pt), 2) AS distance
  FROM poi
 WHERE MBRContains(ST_GeomFromText(@square), pt)
   AND ST_Distance(@hereami, pt) < 4.5
   AND type = 'Shop'
 ORDER BY distance ASC
;
+----+------------+--------+----------+
| id | point      | name   | distance |
+----+------------+--------+----------+
|  3 | POINT(5 4) | Shop 2 |     4.00 |
+----+------------+--------+----------+
1 row in set (0.02 sec)

So, my shop is in the result again now. And even a bit faster!

Now I wanted to find out if this results are any faster than the conventional method with an index on (x) and (y) or (x, y):

SELECT id, ST_AsText(pt) AS point, name, ROUND(ST_Distance(@hereami, pt), 2) AS distance
  FROM poi
 WHERE x >=  4.5 AND x <= 13.5
   AND y >= -0.5 AND y <=  8.5
   AND ST_Distance(@hereami, pt) < 4.5
   AND type = 'Shop'
 ORDER BY distance ASC
;
1 row in set (0.15 sec)

Here the optimizer chooses the index on x. But I think he could do better. So I forced to optimizer to use the index on (x, y):

SELECT id, ST_AsText(pt) AS point, name, ROUND(ST_Distance(@hereami, pt), 2) AS distance
  FROM poi FORCE INDEX (xy)
 WHERE x >=  4.5 AND x <= 13.5
   AND y >= -0.5 AND y <=  8.5
   AND ST_Distance(@hereami, pt) < 4.5
   AND type = 'Shop'
 ORDER BY distance ASC
;
1 row in set (0.03 sec)

           id: 1
  select_type: SIMPLE
        table: poi
   partitions: NULL
         type: range
possible_keys: xy
          key: xy
      key_len: 10
          ref: NULL
         rows: 115592
     filtered: 1.11
        Extra: Using index condition; Using where; Using filesort

Same performance than with the spatial index. So it looks like for this simple task with my data distribution conventional methods do well enough.

No I wanted to try a polygon which comes as close as possible to a circle. This I solved with a MySQL stored function which returns a polygon:/p>

DROP FUNCTION polygon_circle;

delimiter //

CREATE FUNCTION polygon_circle(pX DOUBLE, pY DOUBLE, pDiameter DOUBLE, pPoints SMALLINT UNSIGNED)
-- RETURNS VARCHAR(4096) DETERMINISTIC
RETURNS POLYGON DETERMINISTIC
BEGIN

  DECLARE i SMALLINT UNSIGNED DEFAULT 0;
  DECLARE vSteps SMALLINT UNSIGNED;
  DECLARE vPolygon VARCHAR(4096) DEFAULT '';

  -- Input validation

  IF pPoints < 3 THEN
    RETURN NULL;
  END IF;
  IF pPoints > 360 THEN
    RETURN NULL;
  END IF;
  IF pPoints > 90 THEN
    RETURN NULL;
  END IF;
  if (360 % pPoints) != 0 THEN
    RETURN NULL;
  END IF;

  -- Start

  SET vSteps = 360 / pPoints;

  WHILE i < 360 DO
    SET vPolygon = CONCAT(vPolygon, (pX + (SIN(i * 2 * PI() / 360) * pDiameter)), '', (pY + (COS(i * 2 * PI() / 360) * pDiameter)), ', ');
    SET i = i + vSteps;
  END WHILE;

  -- Add first point again
  SET vPolygon = CONCAT("POLYGON((", vPolygon, (pX + (SIN(0 * 2 * PI() / 360) * pDiameter)), "",  (pY + (COS(0 * 2 * PI() / 360) * pDiameter)), "))");

  -- RETURN vPolygon;
  RETURN ST_GeomFromText(vPolygon);
END;
//

delimiter ;

SELECT ST_AsText(polygon_circle(9, 4, 4.5, 6));
-- SELECT polygon_circle(9, 4, 4.5, 8);

Then calling the query in the same way:

SET @hereami = POINT(9,4);
SELECT id, ST_AsText(pt) AS point, name, ROUND(ST_Distance(@hereami, pt), 2) AS distance
  FROM poi
 WHERE MBRContains(polygon_circle(9, 4, 4.5, 90), pt)
   AND ST_Distance(@hereami, pt) < 4.5
   AND type = 'Shop'
 ORDER BY distance ASC
;
+----+------------+--------+----------+
| id | point      | name   | distance |
+----+------------+--------+----------+
|  3 | POINT(5 4) | Shop 2 |     4.00 |
+----+------------+--------+----------+
1 row in set (0.03 sec)

This seems not to have any significant negative impact on performance.

Results

Test	#rows	operation	latency
Total	655360	FTS	1300 ms
Spatial exact Circle	4128	FTS	520 ms
Spatial inner Hexagon	3916	range (pt)	20 ms
Spatial outer Square	4128	range (pt)	30 ms
Conventional outer Square on (x)	4128	range (x) or (y)	150 ms
Conventional outer Square on (xy)	4128	range (x,y)	30 ms
Spatial good Polygon	4128	range (pt)	30 ms

Taxonomy upgrade extras:

spatial

gis

↧

Temporary tables and MySQL STATUS information

July 8, 2016, 9:42 am

≫ Next: MySQL Environment MyEnv 1.3.1 has been released

≪ Previous: MySQL spatial functionality - points of interest around me

When analysing MySQL configuration and status information at customers it is always interesting to see how the applications behave. This can partially be seen by the output of the SHOW GLOBAL STATUS command. See also Reading MySQL fingerprints.

Today we wanted to know where the high Com_create_table and the twice as high Com_drop_table is coming from. One suspect was TEMPORARY TABLES. But are real temporary tables counted as Com_create_table and Com_drop_table at all? This is what we want to find out today. The tested MySQL version is 5.7.11.

Caution: Different MySQL or MariaDB versions might behave differently!

Session 1	Global	Session 2
`CREATE TABLE t1 (id INT); Query OK, 0 rows affected`
`Com_create_table +1 Opened_table_definitions +1`	`Com_create_table +1 Opened_table_definitions +1`

`CREATE TABLE t1 (id INT); ERROR 1050 (42S01): Table 't1' already exists`
`Com_create_table +1 Open_table_definitions +1 Open_tables +1 Opened_table_definitions +1 Opened_tables +1`	`Com_create_table + 1 Open_table_definitions +1 Open_tables +1 Opened_table_definitions +1 Opened_tables +1`

`CREATE TABLE t1 (id INT); ERROR 1050 (42S01): Table 't1' already exists`
`Com_create_table + 1`	`Com_create_table + 1`

`DROP TABLE t1; Query OK, 0 rows affected`
`Com_drop_table +1 Open_table_definitions -1 Open_tables -1`	`Com_drop_table +1 Open_table_definitions -1 Open_tables -1`

`DROP TABLE t1; ERROR 1051 (42S02): Unknown table 'test.t1'`
`Com_drop_table -1`	`Com_drop_table -1`

`CREATE TEMPORARY TABLE ttemp (id INT); Query OK, 0 rows affected`
`Com_create_table +1 Opened_table_definitions +2 Opened_tables +1`	`Com_create_table +1 Opened_table_definitions +2 Opened_tables +1`

`CREATE TEMPORARY TABLE ttemp (id INT); ERROR 1050 (42S01): Table 'ttemp' already exists`
`Com_create_table +1`	`Com_create_table +1`

`DROP TABLE ttemp; Query OK, 0 rows affected`
`Com_drop_table +1`	`Com_drop_table +1`

`CREATE TEMPORARY TABLE ttemp (id int); Query OK, 0 rows affected`		`CREATE TEMPORARY TABLE ttemp (id int); Query OK, 0 rows affected`
`Com_create_table +1 Opened_table_definitions +2 Opened_tables +1`	`Com_create_table +2 Opened_table_definitions +4 Opened_tables +2`	`Com_create_table +1 Opened_table_definitions +2 Opened_tables +1`

`DROP TABLE ttemp; Query OK, 0 rows affected`		`DROP TABLE ttemp; Query OK, 0 rows affected`
`Com_drop_table +1`	`Com_drop_table +2`	`Com_drop_table +1`

Conclusion

A successful CREATE TABLE command opens and closes a table definition.
A non successful CREATE TABLE command opens the table definition and the file handle of the previous table. So a faulty application can be quite expensive.
A further non successful CREATE TABLE command has no other impact.
A DROP TABLE command closes a table definition and the file handle.
A CREATE TEMPORARY TABLE opens 2 table definitions and the file handle. Thus behaves different than CREATE TABLE
But a faulty CREATE TEMPORARY TABLE seems to be much less intrusive.
Open_table_definitions and Open_tables is always global, also in session context.

Taxonomy upgrade extras:

status

temporary table

↧

MySQL Environment MyEnv 1.3.1 has been released

August 2, 2016, 11:27 pm

≫ Next: FromDual Performance Monitor for MySQL and MariaDB 0.10.6 has been released

≪ Previous: Temporary tables and MySQL STATUS information

FromDual has the pleasure to announce the release of the new version 1.3.1 of its popular MySQL, Galera Cluster, MariaDB and Percona Server multi-instance environment MyEnv.

The new MyEnv can be downloaded here.

In the inconceivable case that you find a bug in the MyEnv please report it to our bug tracker.

Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

Upgrade from 1.1.x or higher to 1.3.1

# cd ${HOME}/product
# tar xf /download/myenv-1.3.1.tar.gz
# rm -f myenv
# ln -s myenv-1.3.1 myenv

If you are using plug-ins for showMyEnvStatus create all the links in the new directory structure:

cd ${HOME}/product/myenv
ln -s ../../utl/oem_agent.php plg/showMyEnvStatus/

Changes in MyEnv 1.3.1

MyEnv

Bash function bootstrap added.
Galera options --bootstrap--new-cluster and start method bootstrap was implemented. Typo fixed.
New 5.7 variables added and 5.6 variables to avoid nasty warnings in the error log added to the my.cnf template. Further new file system structure was prepared.
MySQL 5.7 variables for error log behaviour added.
Comment for log_bin added to my.cnf template.
ulimit problem fixed rudely in MyEnv init script.
wsrep_provider for CentOS added in my.cnf template.
Cgroup template improved.
Cgroup how-to improved and configuration example added.

MyEnv Installer

default as instance name set to blacklist.
Typo fixed in help of installMyEnv.

MyEnv Utilities

Test table prepared for explicit_defaults_for_timestamp configuration.
insert_test.sh now has optional parameters for user, host etc.

For subscriptions of commercial use of MyEnv please get in contact with us.

Taxonomy upgrade extras:

↧

FromDual Performance Monitor for MySQL and MariaDB 0.10.6 has been released

August 3, 2016, 10:40 am

≫ Next: Beware of large MySQL max_sort_length parameter

≪ Previous: MySQL Environment MyEnv 1.3.1 has been released

FromDual has the pleasure to announce the release of the new version 0.10.6 of its popular Database Performance Monitor for MySQL, MariaDB, Galera Cluster and Percona Server fpmmm.

You can download fpmmm from here.

In the inconceivable case that you find a bug in fpmmm please report it to our Bug-tracker.

Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

This release contains various bug fixes and improvements. The previous release had some major bugs so we recommend to upgrade...

Changes in fpmmm v0.10.6

fpmmm agent

Do not connect to server bug fixed.
Special case when lock file was removed when it was read is fixed.
Added ORDER BY to all GROUP BY to be compliant for the future.
Zabbix 3.0 templates added.
MaaS: Function curl_file_create implemented for php < 5.5
MaaS: Debug message fixed.
Maas: Curl upload fixed.
MaaS: InnoDB: Deadlock and Foreign Key errors are only escaped with xxx when used in MaaS. Otherwise they are sent normally. Foreign Key errors with MaaS is now also escaped with xxx.

Process module

Wrong substitution in process vm calculation fixed.

Galera module

Template: Galera items changed from normal to delta.

InnoDB module

Template: Fixed InnoDB template to work with Zabbix v3.0.
Template: InnoDB locking graph improved.

For subscriptions of commercial use of fpmmm please get in contact with us.

Taxonomy upgrade extras:

↧

Beware of large MySQL max_sort_length parameter

August 24, 2016, 2:40 pm

≫ Next: How to Install MySQL Enterprise Server 5.7 on Red Hat Enterprise Linux 7

≪ Previous: FromDual Performance Monitor for MySQL and MariaDB 0.10.6 has been released

Today we had a very interesting phenomena at a customer. He complained that MySQL always get some errors of the following type:

[ERROR] mysqld: Sort aborted: Error writing file '/tmp/MYGbBrpA' (Errcode: 28 - No space left on device)

After a first investigation we found that df -h /tmp shows from time to time a full disk but we could not see any file with ls -la /tmp/MY*.

After some more investigation we found even the query from the Slow Query Log which was producing the same problem. It looked similar to this query:

SELECT * FROM test ORDER BY field5, field4, field3, field2, field1;

Now we were capable to simulate the problem at will with the following table:

CREATE TABLE `test` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `data` varchar(64) DEFAULT NULL,
  `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `field1` varchar(16) DEFAULT NULL,
  `field2` varchar(16) DEFAULT NULL,
  `field3` varchar(255) DEFAULT NULL,
  `field4` varchar(255) DEFAULT NULL,
  `field5` varchar(32) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=8912746 DEFAULT CHARSET=utf8
;

An we have seen the query in SHOW PROCESSLIST:

| Query   |   26 | Creating sort index | select * from test order by field5, field4, field3, field2, field1 |

But we were still not capable to see who or better how the hell mysqld is filling our disk!

I remembered further that I have seen some strange settings in the my.cnf before when we did the review of the database configuration. But I ignored them somehow.

[mysqld]
max_sort_length  = 8M
sort_buffer_size = 20M

Now I remembered again these settings. We changed max_sort_length back to default 1k and suddenly our space problems disappeared!

We played a bit around with different values of max_sort_length and got the following execution times for our query:

`max_sort_length`	execution time [s]	comment
64	8.8 s
128	8.2 s
256	9.3 s
512	11.8 s
1k	14.9 s
2k	20.0 s
8k	129.0 s
8M	75.0 s	disk full (50 G)

Conclusion

We set the values of max_sort_length back to the defaults. Our problems disappeared and we got working and much faster SELECT queries.

Do not needlessly change default values of MySQL without proving the impact. It can become worse than before!!!

The default value of max_sort_length is a good compromise between performance and an appropriate sort length.

Addendum

What I really did not like on this solution was, that I did not understand the way the problem occurred. So I did some more investigation in this. We were discussing forth and back if this could be because of XFS, because of sparse files or some kind of memory mapped files (see also man mmap).

At the end I had the idea to look at the lsof command during my running query:

mysql> SELECT * FROM test ORDER BY field5, field4, field3, field2, field1;
ERROR 3 (HY000): Error writing file '/tmp/MYBuWcXP' (Errcode: 28 - No space left on device)

shell> lsof -p 14733

COMMAND   PID  USER   FD   TYPE             DEVICE   SIZE/OFF     NODE NAME
mysqld  14733 mysql   32u   REG               8,18 9705619456 30147474 /tmp/MYck8vf4 (deleted)
mysqld  14733 mysql   49u   REG               8,18  749797376 30147596 /tmp/MYBuWcXP (deleted)

So it looks like that there were some deleted files which were growing!

Further information from the IRC channel led me to the libctemporary files (see also man 3 tmpfile).

And some hints from MadMerlin|work pointed me to:

shell> ls /proc//fd

Where you can also see those temporary files.

Thanks to MadMerlin|work for the hints!

Taxonomy upgrade extras:

sort

file

order by

↧

How to Install MySQL Enterprise Server 5.7 on Red Hat Enterprise Linux 7

October 24, 2016, 1:03 pm

≫ Next: How to build your own RPM repository for MySQL Enterprise Server 5.7 on RHEL 7

≪ Previous: Beware of large MySQL max_sort_length parameter

If you have already Red Hat Enterprise Linux 7 (RHEL 7) or CentOS 7 in use you probably found out, that it is not that easy to install MySQL Enterprise Server because there are already pre-installed MariaDB 5.5 libraries:

shell> yum localinstall mysql-commercial-client-5.7.16-1.1.el7.x86_64.rpm mysql-commercial-libs-5.7.16-1.1.el7.x86_64.rpm mysql-commercial-server-5.7.16-1.1.el7.x86_64.rpm mysql-commercial-common-5.7.16-1.1.el7.x86_64.rpm
Loaded plugins: fastestmirror
Examining mysql-commercial-client-5.7.16-1.1.el7.x86_64.rpm: mysql-commercial-client-5.7.16-1.1.el7.x86_64
Marking mysql-commercial-client-5.7.16-1.1.el7.x86_64.rpm to be installed
Examining mysql-commercial-libs-5.7.16-1.1.el7.x86_64.rpm: mysql-commercial-libs-5.7.16-1.1.el7.x86_64
Marking mysql-commercial-libs-5.7.16-1.1.el7.x86_64.rpm to be installed
Examining mysql-commercial-server-5.7.16-1.1.el7.x86_64.rpm: mysql-commercial-server-5.7.16-1.1.el7.x86_64
Marking mysql-commercial-server-5.7.16-1.1.el7.x86_64.rpm to be installed
Examining mysql-commercial-common-5.7.16-1.1.el7.x86_64.rpm: mysql-commercial-common-5.7.16-1.1.el7.x86_64
Marking mysql-commercial-common-5.7.16-1.1.el7.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package mariadb-libs.x86_64 1:5.5.50-1.el7_2 will be obsoleted
--> Processing Dependency: libmysqlclient.so.18()(64bit) for package: 2:postfix-2.10.1-6.el7.x86_64
Loading mirror speeds from cached hostfile
 * base: wftp.tu-chemnitz.de
 * extras: wftp.tu-chemnitz.de
 * updates: mirror.rackspeed.de
--> Processing Dependency: libmysqlclient.so.18(libmysqlclient_18)(64bit) for package: 2:postfix-2.10.1-6.el7.x86_64
---> Package mysql-commercial-client.x86_64 0:5.7.16-1.1.el7 will be installed
---> Package mysql-commercial-common.x86_64 0:5.7.16-1.1.el7 will be installed
---> Package mysql-commercial-libs.x86_64 0:5.7.16-1.1.el7 will be obsoleting
---> Package mysql-commercial-server.x86_64 0:5.7.16-1.1.el7 will be installed
--> Processing Dependency: /usr/bin/perl for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: libaio.so.1(LIBAIO_0.1)(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: libaio.so.1(LIBAIO_0.4)(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: net-tools for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: perl(Getopt::Long) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: perl(strict) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: libaio.so.1()(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Running transaction check
---> Package libaio.x86_64 0:0.3.109-13.el7 will be installed
---> Package mariadb-libs.x86_64 1:5.5.50-1.el7_2 will be obsoleted
--> Processing Dependency: libmysqlclient.so.18()(64bit) for package: 2:postfix-2.10.1-6.el7.x86_64
--> Processing Dependency: libmysqlclient.so.18(libmysqlclient_18)(64bit) for package: 2:postfix-2.10.1-6.el7.x86_64
---> Package net-tools.x86_64 0:2.0-0.17.20131004git.el7 will be installed
---> Package perl.x86_64 4:5.16.3-286.el7 will be installed
--> Processing Dependency: perl-libs = 4:5.16.3-286.el7 for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Socket) >= 1.3 for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Scalar::Util) >= 1.10 for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl-macros for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl-libs for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(threads::shared) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(threads) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(constant) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Time::Local) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Time::HiRes) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Storable) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Socket) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Scalar::Util) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Pod::Simple::XHTML) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Pod::Simple::Search) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Filter::Util::Call) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Temp) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Spec::Unix) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Spec::Functions) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Spec) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Path) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Exporter) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Cwd) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Carp) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: libperl.so()(64bit) for package: 4:perl-5.16.3-286.el7.x86_64
---> Package perl-Getopt-Long.noarch 0:2.40-2.el7 will be installed
--> Processing Dependency: perl(Pod::Usage) >= 1.14 for package: perl-Getopt-Long-2.40-2.el7.noarch
--> Processing Dependency: perl(Text::ParseWords) for package: perl-Getopt-Long-2.40-2.el7.noarch
--> Running transaction check
---> Package mariadb-libs.x86_64 1:5.5.50-1.el7_2 will be obsoleted
--> Processing Dependency: libmysqlclient.so.18()(64bit) for package: 2:postfix-2.10.1-6.el7.x86_64
--> Processing Dependency: libmysqlclient.so.18(libmysqlclient_18)(64bit) for package: 2:postfix-2.10.1-6.el7.x86_64
---> Package perl-Carp.noarch 0:1.26-244.el7 will be installed
---> Package perl-Exporter.noarch 0:5.68-3.el7 will be installed
---> Package perl-File-Path.noarch 0:2.09-2.el7 will be installed
---> Package perl-File-Temp.noarch 0:0.23.01-3.el7 will be installed
---> Package perl-Filter.x86_64 0:1.49-3.el7 will be installed
---> Package perl-PathTools.x86_64 0:3.40-5.el7 will be installed
---> Package perl-Pod-Simple.noarch 1:3.28-4.el7 will be installed
--> Processing Dependency: perl(Pod::Escapes) >= 1.04 for package: 1:perl-Pod-Simple-3.28-4.el7.noarch
--> Processing Dependency: perl(Encode) for package: 1:perl-Pod-Simple-3.28-4.el7.noarch
---> Package perl-Pod-Usage.noarch 0:1.63-3.el7 will be installed
--> Processing Dependency: perl(Pod::Text) >= 3.15 for package: perl-Pod-Usage-1.63-3.el7.noarch
--> Processing Dependency: perl-Pod-Perldoc for package: perl-Pod-Usage-1.63-3.el7.noarch
---> Package perl-Scalar-List-Utils.x86_64 0:1.27-248.el7 will be installed
---> Package perl-Socket.x86_64 0:2.010-3.el7 will be installed
---> Package perl-Storable.x86_64 0:2.45-3.el7 will be installed
---> Package perl-Text-ParseWords.noarch 0:3.29-4.el7 will be installed
---> Package perl-Time-HiRes.x86_64 4:1.9725-3.el7 will be installed
---> Package perl-Time-Local.noarch 0:1.2300-2.el7 will be installed
---> Package perl-constant.noarch 0:1.27-2.el7 will be installed
---> Package perl-libs.x86_64 4:5.16.3-286.el7 will be installed
---> Package perl-macros.x86_64 4:5.16.3-286.el7 will be installed
---> Package perl-threads.x86_64 0:1.87-4.el7 will be installed
---> Package perl-threads-shared.x86_64 0:1.43-6.el7 will be installed
--> Running transaction check
---> Package mariadb-libs.x86_64 1:5.5.50-1.el7_2 will be obsoleted
--> Processing Dependency: libmysqlclient.so.18()(64bit) for package: 2:postfix-2.10.1-6.el7.x86_64
--> Processing Dependency: libmysqlclient.so.18(libmysqlclient_18)(64bit) for package: 2:postfix-2.10.1-6.el7.x86_64
---> Package perl-Encode.x86_64 0:2.51-7.el7 will be installed
---> Package perl-Pod-Escapes.noarch 1:1.04-286.el7 will be installed
---> Package perl-Pod-Perldoc.noarch 0:3.20-4.el7 will be installed
--> Processing Dependency: perl(parent) for package: perl-Pod-Perldoc-3.20-4.el7.noarch
--> Processing Dependency: perl(HTTP::Tiny) for package: perl-Pod-Perldoc-3.20-4.el7.noarch
---> Package perl-podlators.noarch 0:2.5.1-3.el7 will be installed
--> Running transaction check
---> Package mariadb-libs.x86_64 1:5.5.50-1.el7_2 will be obsoleted
--> Processing Dependency: libmysqlclient.so.18()(64bit) for package: 2:postfix-2.10.1-6.el7.x86_64
--> Processing Dependency: libmysqlclient.so.18(libmysqlclient_18)(64bit) for package: 2:postfix-2.10.1-6.el7.x86_64
---> Package perl-HTTP-Tiny.noarch 0:0.033-3.el7 will be installed
---> Package perl-parent.noarch 1:0.225-244.el7 will be installed
--> Finished Dependency Resolution
Error: Package: 2:postfix-2.10.1-6.el7.x86_64 (@anaconda)
           Requires: libmysqlclient.so.18(libmysqlclient_18)(64bit)
           Removing: 1:mariadb-libs-5.5.50-1.el7_2.x86_64 (@updates)
               libmysqlclient.so.18(libmysqlclient_18)(64bit)
           Obsoleted By: mysql-commercial-libs-5.7.16-1.1.el7.x86_64 (/mysql-commercial-libs-5.7.16-1.1.el7.x86_64)
               Not found
           Available: 1:mariadb-libs-5.5.44-2.el7.centos.x86_64 (base)
               libmysqlclient.so.18(libmysqlclient_18)(64bit)
           Available: 1:mariadb-libs-5.5.47-1.el7_2.x86_64 (updates)
               libmysqlclient.so.18(libmysqlclient_18)(64bit)
Error: Package: 2:postfix-2.10.1-6.el7.x86_64 (@anaconda)
           Requires: libmysqlclient.so.18()(64bit)
           Removing: 1:mariadb-libs-5.5.50-1.el7_2.x86_64 (@updates)
               libmysqlclient.so.18()(64bit)
           Obsoleted By: mysql-commercial-libs-5.7.16-1.1.el7.x86_64 (/mysql-commercial-libs-5.7.16-1.1.el7.x86_64)
              ~libmysqlclient.so.20()(64bit)
           Available: 1:mariadb-libs-5.5.44-2.el7.centos.x86_64 (base)
               libmysqlclient.so.18()(64bit)
           Available: 1:mariadb-libs-5.5.47-1.el7_2.x86_64 (updates)
               libmysqlclient.so.18()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

You can remove postfix and mariadb-libs but this will most probably cause you troubles sooner or later:

shell> yum remove postfix mariadb-libs
Loaded plugins: fastestmirror
Resolving Dependencies
--> Running transaction check
---> Package mariadb-libs.x86_64 1:5.5.50-1.el7_2 will be erased
---> Package postfix.x86_64 2:2.10.1-6.el7 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

==========================================================================================================================================================================================
 Package                                       Arch                                    Version                                           Repository                                  Size
==========================================================================================================================================================================================
Removing:
 mariadb-libs                                  x86_64                                  1:5.5.50-1.el7_2                                  @updates                                   4.4 M
 postfix                                       x86_64                                  2:2.10.1-6.el7                                    @anaconda                                   12 M

Transaction Summary
==========================================================================================================================================================================================
Remove  2 Packages

Installed size: 17 M
Is this ok [y/N]: n

If you look at the MySQL Installation Guide: Installing MySQL on Linux Using RPM Packages from Oracle it is unfortunately not really very well documented how to install MySQL Enterprise Server: "using rpm -Uvh instead makes the installation process more prone to failure, due to potential dependency issues the installation process might run into".

So the correct way to install MySQL Enterprise Server 5.7 on Red Hat Enterprise Linux 7 (RHEL7) or CentOS 7 is as follows:

shell> rpm --upgrade -vh mysql-commercial-libs-compat-5.7.16-1.1.el7.x86_64.rpm mysql-commercial-libs-5.7.16-1.1.el7.x86_64.rpm mysql-commercial-common-5.7.16-1.1.el7.x86_64.rpmshell> yum localinstall mysql-commercial-server-5.7.16-1.1.el7.x86_64.rpm mysql-commercial-client-5.7.16-1.1.el7.x86_64.rpm
Loaded plugins: fastestmirror
Examining mysql-commercial-server-5.7.16-1.1.el7.x86_64.rpm: mysql-commercial-server-5.7.16-1.1.el7.x86_64
Marking mysql-commercial-server-5.7.16-1.1.el7.x86_64.rpm to be installed
Examining mysql-commercial-client-5.7.16-1.1.el7.x86_64.rpm: mysql-commercial-client-5.7.16-1.1.el7.x86_64
Marking mysql-commercial-client-5.7.16-1.1.el7.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package mysql-commercial-client.x86_64 0:5.7.16-1.1.el7 will be installed
---> Package mysql-commercial-server.x86_64 0:5.7.16-1.1.el7 will be installed
--> Processing Dependency: /usr/bin/perl for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
Loading mirror speeds from cached hostfile
 * base: wftp.tu-chemnitz.de
 * extras: wftp.tu-chemnitz.de
 * updates: mirror.rackspeed.de
--> Processing Dependency: libaio.so.1(LIBAIO_0.1)(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: libaio.so.1(LIBAIO_0.4)(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: net-tools for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: perl(Getopt::Long) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: perl(strict) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: libaio.so.1()(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Running transaction check
---> Package libaio.x86_64 0:0.3.109-13.el7 will be installed
---> Package net-tools.x86_64 0:2.0-0.17.20131004git.el7 will be installed
---> Package perl.x86_64 4:5.16.3-286.el7 will be installed
--> Processing Dependency: perl-libs = 4:5.16.3-286.el7 for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Socket) >= 1.3 for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Scalar::Util) >= 1.10 for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl-macros for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl-libs for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(threads::shared) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(threads) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(constant) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Time::Local) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Time::HiRes) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Storable) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Socket) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Scalar::Util) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Pod::Simple::XHTML) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Pod::Simple::Search) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Filter::Util::Call) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Temp) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Spec::Unix) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Spec::Functions) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Spec) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Path) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Exporter) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Cwd) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Carp) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: libperl.so()(64bit) for package: 4:perl-5.16.3-286.el7.x86_64
---> Package perl-Getopt-Long.noarch 0:2.40-2.el7 will be installed
--> Processing Dependency: perl(Pod::Usage) >= 1.14 for package: perl-Getopt-Long-2.40-2.el7.noarch
--> Processing Dependency: perl(Text::ParseWords) for package: perl-Getopt-Long-2.40-2.el7.noarch
--> Running transaction check
---> Package perl-Carp.noarch 0:1.26-244.el7 will be installed
---> Package perl-Exporter.noarch 0:5.68-3.el7 will be installed
---> Package perl-File-Path.noarch 0:2.09-2.el7 will be installed
---> Package perl-File-Temp.noarch 0:0.23.01-3.el7 will be installed
---> Package perl-Filter.x86_64 0:1.49-3.el7 will be installed
---> Package perl-PathTools.x86_64 0:3.40-5.el7 will be installed
---> Package perl-Pod-Simple.noarch 1:3.28-4.el7 will be installed
--> Processing Dependency: perl(Pod::Escapes) >= 1.04 for package: 1:perl-Pod-Simple-3.28-4.el7.noarch
--> Processing Dependency: perl(Encode) for package: 1:perl-Pod-Simple-3.28-4.el7.noarch
---> Package perl-Pod-Usage.noarch 0:1.63-3.el7 will be installed
--> Processing Dependency: perl(Pod::Text) >= 3.15 for package: perl-Pod-Usage-1.63-3.el7.noarch
--> Processing Dependency: perl-Pod-Perldoc for package: perl-Pod-Usage-1.63-3.el7.noarch
---> Package perl-Scalar-List-Utils.x86_64 0:1.27-248.el7 will be installed
---> Package perl-Socket.x86_64 0:2.010-3.el7 will be installed
---> Package perl-Storable.x86_64 0:2.45-3.el7 will be installed
---> Package perl-Text-ParseWords.noarch 0:3.29-4.el7 will be installed
---> Package perl-Time-HiRes.x86_64 4:1.9725-3.el7 will be installed
---> Package perl-Time-Local.noarch 0:1.2300-2.el7 will be installed
---> Package perl-constant.noarch 0:1.27-2.el7 will be installed
---> Package perl-libs.x86_64 4:5.16.3-286.el7 will be installed
---> Package perl-macros.x86_64 4:5.16.3-286.el7 will be installed
---> Package perl-threads.x86_64 0:1.87-4.el7 will be installed
---> Package perl-threads-shared.x86_64 0:1.43-6.el7 will be installed
--> Running transaction check
---> Package perl-Encode.x86_64 0:2.51-7.el7 will be installed
---> Package perl-Pod-Escapes.noarch 1:1.04-286.el7 will be installed
---> Package perl-Pod-Perldoc.noarch 0:3.20-4.el7 will be installed
--> Processing Dependency: perl(parent) for package: perl-Pod-Perldoc-3.20-4.el7.noarch
--> Processing Dependency: perl(HTTP::Tiny) for package: perl-Pod-Perldoc-3.20-4.el7.noarch
---> Package perl-podlators.noarch 0:2.5.1-3.el7 will be installed
--> Running transaction check
---> Package perl-HTTP-Tiny.noarch 0:0.033-3.el7 will be installed
---> Package perl-parent.noarch 1:0.225-244.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

==========================================================================================================================================================================================
 Package                                    Arch                      Version                                     Repository                                                         Size
==========================================================================================================================================================================================
Installing:
 mysql-commercial-client                    x86_64                    5.7.16-1.1.el7                              /mysql-commercial-client-5.7.16-1.1.el7.x86_64                     94 M
 mysql-commercial-server                    x86_64                    5.7.16-1.1.el7                              /mysql-commercial-server-5.7.16-1.1.el7.x86_64                    721 M
Installing for dependencies:
 libaio                                     x86_64                    0.3.109-13.el7                              base                                                               24 k
 net-tools                                  x86_64                    2.0-0.17.20131004git.el7                    base                                                              304 k
 perl                                       x86_64                    4:5.16.3-286.el7                            base                                                              8.0 M
 perl-Carp                                  noarch                    1.26-244.el7                                base                                                               19 k
 perl-Encode                                x86_64                    2.51-7.el7                                  base                                                              1.5 M
 perl-Exporter                              noarch                    5.68-3.el7                                  base                                                               28 k
 perl-File-Path                             noarch                    2.09-2.el7                                  base                                                               26 k
 perl-File-Temp                             noarch                    0.23.01-3.el7                               base                                                               56 k
 perl-Filter                                x86_64                    1.49-3.el7                                  base                                                               76 k
 perl-Getopt-Long                           noarch                    2.40-2.el7                                  base                                                               56 k
 perl-HTTP-Tiny                             noarch                    0.033-3.el7                                 base                                                               38 k
 perl-PathTools                             x86_64                    3.40-5.el7                                  base                                                               82 k
 perl-Pod-Escapes                           noarch                    1:1.04-286.el7                              base                                                               50 k
 perl-Pod-Perldoc                           noarch                    3.20-4.el7                                  base                                                               87 k
 perl-Pod-Simple                            noarch                    1:3.28-4.el7                                base                                                              216 k
 perl-Pod-Usage                             noarch                    1.63-3.el7                                  base                                                               27 k
 perl-Scalar-List-Utils                     x86_64                    1.27-248.el7                                base                                                               36 k
 perl-Socket                                x86_64                    2.010-3.el7                                 base                                                               49 k
 perl-Storable                              x86_64                    2.45-3.el7                                  base                                                               77 k
 perl-Text-ParseWords                       noarch                    3.29-4.el7                                  base                                                               14 k
 perl-Time-HiRes                            x86_64                    4:1.9725-3.el7                              base                                                               45 k
 perl-Time-Local                            noarch                    1.2300-2.el7                                base                                                               24 k
 perl-constant                              noarch                    1.27-2.el7                                  base                                                               19 k
 perl-libs                                  x86_64                    4:5.16.3-286.el7                            base                                                              687 k
 perl-macros                                x86_64                    4:5.16.3-286.el7                            base                                                               43 k
 perl-parent                                noarch                    1:0.225-244.el7                             base                                                               12 k
 perl-podlators                             noarch                    2.5.1-3.el7                                 base                                                              112 k
 perl-threads                               x86_64                    1.87-4.el7                                  base                                                               49 k
 perl-threads-shared                        x86_64                    1.43-6.el7                                  base                                                               39 k

Transaction Summary
==========================================================================================================================================================================================
Install  2 Packages (+29 Dependent packages)

Total size: 826 M
Total download size: 12 M
Installed size: 852 M
Is this ok [y/d/N]: y

Further information you can find in the slides of my colleague Jörg Brühe: MySQL selection also against the distirbution he presented at FrOSCon 2016.

Taxonomy upgrade extras:

↧

How to build your own RPM repository for MySQL Enterprise Server 5.7 on RHEL 7

October 24, 2016, 2:01 pm

≫ Next: What are the differences between MySQL Community and MySQL Enterprise Server 5.7

≪ Previous: How to Install MySQL Enterprise Server 5.7 on Red Hat Enterprise Linux 7

Prepare the RPM repository server

Install the software to create a RPM repository server (on an Ubuntu web server):

shell> sudo apt-get install createrepo

Create the directory structures and initialize the repositories:

shell> sudo mkdir -p /var/www/html/repos/centos/7/os/x86_64
shell> sudo createrepo /var/www/html/repos/centos/7/os/x86_64/

Copy the MySQL Enterprise RPM packages to the repository:

shell> sudo cd /var/www/html/repos/centos/7/os/x86_64/
shell> sudo unzip -v /download/V790254-01.zip   # MySQL Enterprise Server 5.7.16
Archive:  /download/V790254-01.zip
   Length  Method      Size Cmpr    Date    Time   CRC-32   Name
---------  ------  -------- ---- ---------- ----- --------  ----
 23979568  Stored  23979568   0% 2016-09-29 16:56 ae6693b1  mysql-commercial-client-5.7.16-1.1.el7.x86_64.rpm
 45327096  Stored  45327096   0% 2016-09-29 16:56 bb83c965  mysql-commercial-embedded-5.7.16-1.1.el7.x86_64.rpm
   271300  Stored    271300   0% 2016-09-29 16:56 b4eebc96  mysql-commercial-common-5.7.16-1.1.el7.x86_64.rpm
  2041404  Stored   2041404   0% 2016-09-29 16:57 cfc63d84  mysql-commercial-libs-compat-5.7.16-1.1.el7.x86_64.rpm
 23747244  Stored  23747244   0% 2016-09-29 16:56 7b4d36fa  mysql-commercial-embedded-compat-5.7.16-1.1.el7.x86_64.rpm
  3644756  Stored   3644756   0% 2016-09-29 16:56 613af6a3  mysql-commercial-devel-5.7.16-1.1.el7.x86_64.rpm
170697184  Stored 170697184   0% 2016-09-29 16:57 ce26e84a  mysql-commercial-server-5.7.16-1.1.el7.x86_64.rpm
116778644  Stored 116778644   0% 2016-09-29 16:58 8ca7f0f0  mysql-commercial-test-5.7.16-1.1.el7.x86_64.rpm
125679224  Stored 125679224   0% 2016-09-29 16:57 e74a416d  mysql-commercial-embedded-devel-5.7.16-1.1.el7.x86_64.rpm
  2172140  Stored   2172140   0% 2016-09-29 16:57 e2a1c2f9  mysql-commercial-libs-5.7.16-1.1.el7.x86_64.rpm
     3018  Stored      3018   0% 2016-10-11 13:00 6d6efc1e  README.txt
---------         --------- ----                            -------
514341578         514341578   0%                            11 files

Update the RPM repository meta data:

shell> sudo createrepo --update /var/www/html/repos/centos/7/os/x86_64/

Now the RPM repository server is finished.

Prepare the RPM client

Create the MySQL Enterprise Server repository file for the client. The IP address represents the IP address of your RPM repository server:

#
# /etc/yum.repos.d/mysql-enterprise.repo
#

[mysql57-enterprise]

name=MySQL 5.7 Enterprise Server
baseurl=http://192.168.56.1/repos/centos/$releasever/os/$basearch/
gpgcheck=1
enabled=1
gpgkey=http://192.168.56.1/repos/centos/RPM-GPG-KEY-CentOS-7

Clean up the yum cache:

shell> yum clean all
Loaded plugins: fastestmirror
Cleaning repos: base extras mysql57-enterprise updates
Cleaning up everything

Show all know RPM repositories:

shell> yum repolist
Loaded plugins: fastestmirror
base                                                                                                                                                               | 3.6 kB  00:00:00     
extras                                                                                                                                                             | 3.4 kB  00:00:00     
mysql57-enterprise                                                                                                                                                 | 2.9 kB  00:00:00     
updates                                                                                                                                                            | 3.4 kB  00:00:00     
(1/5): mysql57-enterprise/7/x86_64/primary_db                                                                                                                      |  12 kB  00:00:00     
(2/5): base/7/x86_64/group_gz                                                                                                                                      | 155 kB  00:00:00     
(3/5): extras/7/x86_64/primary_db                                                                                                                                  | 166 kB  00:00:00     
(4/5): base/7/x86_64/primary_db                                                                                                                                    | 5.3 MB  00:00:06     
(5/5): updates/7/x86_64/primary_db                                                                                                                                 | 8.4 MB  00:00:11     
Determining fastest mirrors
 * base: mirror.imt-systems.com
 * extras: mirror.eu.oneandone.net
 * updates: mirror.rackspeed.de
repo id                                                                                   repo name                                                                                 status
base/7/x86_64                                                                             CentOS-7 - Base                                                                           9'007
extras/7/x86_64                                                                           CentOS-7 - Extras                                                                           393
mysql57-enterprise/7/x86_64                                                               MySQL 5.7 Enterprise Server                                                                  10
updates/7/x86_64                                                                          CentOS-7 - Updates                                                                        2'548
repolist: 11'958

Search what MySQL Enterprise Server packages are available:

shell> yum search mysql-commercial
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.imt-systems.com
 * extras: mirror.eu.oneandone.net
 * updates: mirror.rackspeed.de
============================================================================= N/S matched: mysql-commercial ==============================================================================
mysql-commercial-client.x86_64 : MySQL database client applications and tools
mysql-commercial-common.x86_64 : MySQL database common files for server and client libs
mysql-commercial-devel.x86_64 : Development header files and libraries for MySQL database client applications
mysql-commercial-embedded.x86_64 : MySQL embedded library
mysql-commercial-embedded-compat.x86_64 : MySQL embedded compat library
mysql-commercial-embedded-devel.x86_64 : Development header files and libraries for MySQL as an embeddable library
mysql-commercial-libs.x86_64 : Shared libraries for MySQL database client applications
mysql-commercial-libs-compat.x86_64 : Shared compat libraries for MySQL 5.6.31 database client applications
mysql-commercial-server.x86_64 : A very fast and reliable SQL database server
mysql-commercial-test.x86_64 : Test suite for the MySQL database server

  Name and summary matches only, use "search all" for everything.

Now you are ready to install your MySQL Enterprise Server RPM packages:

shell> yum install mysql-commercial-server
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.imt-systems.com
 * extras: mirror.eu.oneandone.net
 * updates: mirror.rackspeed.de
Resolving Dependencies
--> Running transaction check
---> Package mysql-commercial-server.x86_64 0:5.7.16-1.1.el7 will be installed
--> Processing Dependency: mysql-commercial-client(x86-64) >= 5.7.9 for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: libaio.so.1(LIBAIO_0.4)(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: perl(Getopt::Long) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: /usr/bin/perl for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: perl(strict) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: net-tools for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: libaio.so.1(LIBAIO_0.1)(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Processing Dependency: libaio.so.1()(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64
--> Running transaction check
---> Package libaio.x86_64 0:0.3.109-13.el7 will be installed
---> Package mysql-commercial-client.x86_64 0:5.7.16-1.1.el7 will be installed
---> Package net-tools.x86_64 0:2.0-0.17.20131004git.el7 will be installed
---> Package perl.x86_64 4:5.16.3-286.el7 will be installed
--> Processing Dependency: perl-libs = 4:5.16.3-286.el7 for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Socket) >= 1.3 for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Scalar::Util) >= 1.10 for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl-macros for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl-libs for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(threads::shared) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(threads) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(constant) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Time::Local) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Time::HiRes) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Storable) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Socket) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Scalar::Util) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Pod::Simple::XHTML) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Pod::Simple::Search) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Filter::Util::Call) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Temp) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Spec::Unix) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Spec::Functions) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Spec) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(File::Path) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Exporter) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Cwd) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: perl(Carp) for package: 4:perl-5.16.3-286.el7.x86_64
--> Processing Dependency: libperl.so()(64bit) for package: 4:perl-5.16.3-286.el7.x86_64
---> Package perl-Getopt-Long.noarch 0:2.40-2.el7 will be installed
--> Processing Dependency: perl(Pod::Usage) >= 1.14 for package: perl-Getopt-Long-2.40-2.el7.noarch
--> Processing Dependency: perl(Text::ParseWords) for package: perl-Getopt-Long-2.40-2.el7.noarch
--> Running transaction check
---> Package perl-Carp.noarch 0:1.26-244.el7 will be installed
---> Package perl-Exporter.noarch 0:5.68-3.el7 will be installed
---> Package perl-File-Path.noarch 0:2.09-2.el7 will be installed
---> Package perl-File-Temp.noarch 0:0.23.01-3.el7 will be installed
---> Package perl-Filter.x86_64 0:1.49-3.el7 will be installed
---> Package perl-PathTools.x86_64 0:3.40-5.el7 will be installed
---> Package perl-Pod-Simple.noarch 1:3.28-4.el7 will be installed
--> Processing Dependency: perl(Pod::Escapes) >= 1.04 for package: 1:perl-Pod-Simple-3.28-4.el7.noarch
--> Processing Dependency: perl(Encode) for package: 1:perl-Pod-Simple-3.28-4.el7.noarch
---> Package perl-Pod-Usage.noarch 0:1.63-3.el7 will be installed
--> Processing Dependency: perl(Pod::Text) >= 3.15 for package: perl-Pod-Usage-1.63-3.el7.noarch
--> Processing Dependency: perl-Pod-Perldoc for package: perl-Pod-Usage-1.63-3.el7.noarch
---> Package perl-Scalar-List-Utils.x86_64 0:1.27-248.el7 will be installed
---> Package perl-Socket.x86_64 0:2.010-3.el7 will be installed
---> Package perl-Storable.x86_64 0:2.45-3.el7 will be installed
---> Package perl-Text-ParseWords.noarch 0:3.29-4.el7 will be installed
---> Package perl-Time-HiRes.x86_64 4:1.9725-3.el7 will be installed
---> Package perl-Time-Local.noarch 0:1.2300-2.el7 will be installed
---> Package perl-constant.noarch 0:1.27-2.el7 will be installed
---> Package perl-libs.x86_64 4:5.16.3-286.el7 will be installed
---> Package perl-macros.x86_64 4:5.16.3-286.el7 will be installed
---> Package perl-threads.x86_64 0:1.87-4.el7 will be installed
---> Package perl-threads-shared.x86_64 0:1.43-6.el7 will be installed
--> Running transaction check
---> Package perl-Encode.x86_64 0:2.51-7.el7 will be installed
---> Package perl-Pod-Escapes.noarch 1:1.04-286.el7 will be installed
---> Package perl-Pod-Perldoc.noarch 0:3.20-4.el7 will be installed
--> Processing Dependency: perl(parent) for package: perl-Pod-Perldoc-3.20-4.el7.noarch
--> Processing Dependency: perl(HTTP::Tiny) for package: perl-Pod-Perldoc-3.20-4.el7.noarch
---> Package perl-podlators.noarch 0:2.5.1-3.el7 will be installed
--> Running transaction check
---> Package perl-HTTP-Tiny.noarch 0:0.033-3.el7 will be installed
---> Package perl-parent.noarch 1:0.225-244.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

==========================================================================================================================================================================================
 Package                                           Arch                             Version                                            Repository                                    Size
==========================================================================================================================================================================================
Installing:
 mysql-commercial-server                           x86_64                           5.7.16-1.1.el7                                     mysql57-enterprise                           163 M
Installing for dependencies:
 libaio                                            x86_64                           0.3.109-13.el7                                     base                                          24 k
 mysql-commercial-client                           x86_64                           5.7.16-1.1.el7                                     mysql57-enterprise                            23 M
 net-tools                                         x86_64                           2.0-0.17.20131004git.el7                           base                                         304 k
 perl                                              x86_64                           4:5.16.3-286.el7                                   base                                         8.0 M
 perl-Carp                                         noarch                           1.26-244.el7                                       base                                          19 k
 perl-Encode                                       x86_64                           2.51-7.el7                                         base                                         1.5 M
 perl-Exporter                                     noarch                           5.68-3.el7                                         base                                          28 k
 perl-File-Path                                    noarch                           2.09-2.el7                                         base                                          26 k
 perl-File-Temp                                    noarch                           0.23.01-3.el7                                      base                                          56 k
 perl-Filter                                       x86_64                           1.49-3.el7                                         base                                          76 k
 perl-Getopt-Long                                  noarch                           2.40-2.el7                                         base                                          56 k
 perl-HTTP-Tiny                                    noarch                           0.033-3.el7                                        base                                          38 k
 perl-PathTools                                    x86_64                           3.40-5.el7                                         base                                          82 k
 perl-Pod-Escapes                                  noarch                           1:1.04-286.el7                                     base                                          50 k
 perl-Pod-Perldoc                                  noarch                           3.20-4.el7                                         base                                          87 k
 perl-Pod-Simple                                   noarch                           1:3.28-4.el7                                       base                                         216 k
 perl-Pod-Usage                                    noarch                           1.63-3.el7                                         base                                          27 k
 perl-Scalar-List-Utils                            x86_64                           1.27-248.el7                                       base                                          36 k
 perl-Socket                                       x86_64                           2.010-3.el7                                        base                                          49 k
 perl-Storable                                     x86_64                           2.45-3.el7                                         base                                          77 k
 perl-Text-ParseWords                              noarch                           3.29-4.el7                                         base                                          14 k
 perl-Time-HiRes                                   x86_64                           4:1.9725-3.el7                                     base                                          45 k
 perl-Time-Local                                   noarch                           1.2300-2.el7                                       base                                          24 k
 perl-constant                                     noarch                           1.27-2.el7                                         base                                          19 k
 perl-libs                                         x86_64                           4:5.16.3-286.el7                                   base                                         687 k
 perl-macros                                       x86_64                           4:5.16.3-286.el7                                   base                                          43 k
 perl-parent                                       noarch                           1:0.225-244.el7                                    base                                          12 k
 perl-podlators                                    noarch                           2.5.1-3.el7                                        base                                         112 k
 perl-threads                                      x86_64                           1.87-4.el7                                         base                                          49 k
 perl-threads-shared                               x86_64                           1.43-6.el7                                         base                                          39 k

Transaction Summary
==========================================================================================================================================================================================
Install  1 Package (+30 Dependent packages)

Total download size: 197 M
Installed size: 852 M
Is this ok [y/d/N]: y

Further sources of information:

Taxonomy upgrade extras:

rpm

repository

mysql

mysql enterprise server

enterprise

rhel

red hat

↧

What are the differences between MySQL Community and MySQL Enterprise Server 5.7

October 25, 2016, 1:26 pm

≫ Next: Multi-Instance set-up with MySQL Enterprise Server 5.7 on RHEL 7 with SystemD

≪ Previous: How to build your own RPM repository for MySQL Enterprise Server 5.7 on RHEL 7

The MySQL Server itself

The differences between the MySQL Community Server and the MySQL Enterprise Server 5.7 are as follows as claimed by Oracle:

The license of the MySQL Server itself.
Only MySQL Enterprise Edition has the Enterprise plug-ins (Thread Pool, PAM, Audit, etc.)
Certifications and Indemnification support for the MySQL Enterprise Server.
The MySQL Community Server statically links against yaSSL~~and readline~~ vs MySQL Enterprise Server against OpenSSL~~and libedit~~.

The license of the MySQL Server

The MySQL Community Server is licensed under the GNU General Public License version 2 whereas the MySQL Enterprise Server is under an Oracle proprietary license as you can see from the following diffs of 2 random files:

shell> diff mysql-5.7.16-linux-glibc2.5-x86_64/share/charsets/latin1.xml mysql-advanced-5.7.16-linux-glibc2.5-x86_64/share/charsets/latin1.xml
6,7c6,7
<  Copyright (c) 2003, 2005 MySQL AB
<    Use is subject to license terms
---
>    Copyright (c) 2003, 2005 MySQL AB
>    Use is subject to license terms.
9,20c9,20
<   This program is free software; you can redistribute it and/or modify
<   it under the terms of the GNU General Public License as published by
<   the Free Software Foundation; version 2 of the License.
< 
<   This program is distributed in the hope that it will be useful,
<   but WITHOUT ANY WARRANTY; without even the implied warranty of
<   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
<   GNU General Public License for more details.
< 
<   You should have received a copy of the GNU General Public License
<   along with this program; if not, write to the Free Software
<   Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
---
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>    The lines above are intentionally left blank

This information can also be found in the following files:

mysql-5.7.16-linux-glibc2.5-x86_64/COPYING

                    GNU GENERAL PUBLIC LICENSE
                       Version 2, June 1991

 Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

...


mysql-5.7.16-linux-glibc2.5-x86_64/README

MySQL Server 5.7

This is a release of MySQL, a dual-license SQL database server.
For the avoidance of doubt, this particular copy of the software
is released under the version 2 of the GNU General Public License.
MySQL is brought to you by Oracle.

...


mysql-advanced-5.7.16-linux-glibc2.5-x86_64/LICENSE.mysql

MySQL Server

Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license
agreement containing restrictions on use and disclosure and are protected by
intellectual property laws. Except as expressly permitted in your license
agreement or allowed by law, you may not use, copy, reproduce, translate,
broadcast, modify, license, transmit, distribute, exhibit, perform, publish,
or display any part, in any form, or by any means. Reverse engineering,
disassembly, or decompilation of this software, unless required by law for
interoperability, is prohibited.

...


mysql-advanced-5.7.16-linux-glibc2.5-x86_64/README

MySQL Server 5.x

This is a release of MySQL, a dual-license SQL database server.
For the avoidance of doubt, this particular copy of the software
is released under a commercial license and the GNU General Public
License does not apply. MySQL is brought to you by Oracle.

...

Enterprise plug-ins of the MySQL Enterprise Server

Oracle/MySQL follows the open core business model with the MySQL Server. This means: The MySQL Community Server is the same as the MySQL Enterprise Server but the MySQL Enterprise Server has some additional modules and programs compared to the MySQL Community Server:

MySQL Enterprise Backup
MySQL Enterprise Monitor
MySQL Enterprise Security
MySQL Enterprise Audit

MySQL Enterprise Server Certification and Indemnification support

This is legal stuff. I only care about technical problems... If you have Open Source legal questions please get in contact with us and we will direct you to lawyers which are specialised in the Open Source field.

Different libraries

The MySQL Community Server statically links against yaSSL~~and readline~~ vs MySQL Enterprise Server against OpenSSL~~and libedit~~.

This is on one side a legal problem GPL vs BSD license. On the other side it is a political problem. Unfortunately the OpenSSL used in the MySQL Enterprise Server is actually a bit more feature reach than yaSSL.

We can also see the differences between the different SSL libraries when we search for the symbols:

shell> grep -ic yassl *.mysqld
community.mysqld:1118
enterprise.mysqld:0

shell> grep -ic openssl *.mysqld
community.mysqld:3
enterprise.mysqld:38

shell]> grep -i openssl community.mysql
yaOpenSSL_add_all_algorithms
_ZL16Sys_have_openssl
_ZN8TaoCrypt18RSA_Public_Decoder17ReadHeaderOpenSSLEv

Other technical comparisons

Beside of the described findings above I am a very curious child...

It seems like we can find here some build info:

shell> ll mysql-5.7.16-linux-glibc2.5-x86_64/docs/INFO_BIN mysql-advanced-5.7.16-linux-glibc2.5-x86_64/docs/INFO_BIN    
-rw-r--r-- 1 mysql mysql 5672 Sep 28 20:14 mysql-5.7.16-linux-glibc2.5-x86_64/docs/INFO_BIN
-rw-r--r-- 1 mysql mysql 5969 Sep 28 19:45 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/docs/INFO_BIN

shell> diff mysql-5.7.16-linux-glibc2.5-x86_64/docs/INFO_BIN mysql-advanced-5.7.16-linux-glibc2.5-x86_64/docs/INFO_BIN    
10,13c10,13
< C_FLAGS =  -fPIC -Wall -Wextra -Wformat-security -Wvla -Wwrite-strings -Wdeclaration-after-statement -O3 -g -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing -DDBUG_OFF -I/export/home/somepath/release/include -I/export/home/somepath/mysql-5.7.16/extra/rapidjson/include -I/export/home/somepath/release/libbinlogevents/include -I/export/home/somepath/mysql-5.7.16/libbinlogevents/export -I/export/home/somepath/mysql-5.7.16/include -I/export/home/somepath/mysql-5.7.16/sql/conn_handler -I/export/home/somepath/mysql-5.7.16/libbinlogevents/include -I/export/home/somepath/mysql-5.7.16/sql -I/export/home/somepath/mysql-5.7.16/sql/auth -I/export/home/somepath/mysql-5.7.16/regex -I/export/home/somepath/mysql-5.7.16/zlib -I/export/home/somepath/mysql-5.7.16/extra/yassl/include -I/export/home/somepath/mysql-5.7.16/extra/yassl/taocrypt/include -I/export/home/somepath/release/sql -I/export/home/somepath/mysql-5.7.16/extra/lz4    -DHAVE_YASSL -DYASSL_PREFIX -DHAVE_OPENSSL -DMULTI_THREADED< C_DEFINES = -DHAVE_CONFIG_H -DHAVE_LIBEVENT1 -DHAVE_REPLICATION -DMYSQL_SERVER -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
< CXX_FLAGS =  -fPIC -Wall -Wextra -Wformat-security -Wvla -Woverloaded-virtual -Wno-unused-parameter -O3 -g -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing -DDBUG_OFF -I/export/home/somepath/release/include -I/export/home/somepath/mysql-5.7.16/extra/rapidjson/include -I/export/home/somepath/release/libbinlogevents/include -I/export/home/somepath/mysql-5.7.16/libbinlogevents/export -I/export/home/somepath/mysql-5.7.16/include -I/export/home/somepath/mysql-5.7.16/sql/conn_handler -I/export/home/somepath/mysql-5.7.16/libbinlogevents/include -I/export/home/somepath/mysql-5.7.16/sql -I/export/home/somepath/mysql-5.7.16/sql/auth -I/export/home/somepath/mysql-5.7.16/regex -I/export/home/somepath/mysql-5.7.16/zlib -I/export/home/somepath/mysql-5.7.16/extra/yassl/include -I/export/home/somepath/mysql-5.7.16/extra/yassl/taocrypt/include -I/export/home/somepath/release/sql -I/export/home/somepath/mysql-5.7.16/extra/lz4    -DHAVE_YASSL -DYASSL_PREFIX -DHAVE_OPENSSL -DMULTI_THREADED< CXX_DEFINES = -DHAVE_CONFIG_H -DHAVE_LIBEVENT1 -DHAVE_REPLICATION -DMYSQL_SERVER -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
---
> C_FLAGS =  -fPIC -Wall -Wextra -Wformat-security -Wvla -Wwrite-strings -Wdeclaration-after-statement -O3 -g -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing -DDBUG_OFF -I/export/home/somepath/release/include -I/export/home/somepath/mysqlcom-pro-5.7.16/extra/rapidjson/include -I/export/home/somepath/release/libbinlogevents/include -I/export/home/somepath/mysqlcom-pro-5.7.16/libbinlogevents/export -I/export/home/somepath/mysqlcom-pro-5.7.16/include -I/export/home/somepath/mysqlcom-pro-5.7.16/sql/conn_handler -I/export/home/somepath/mysqlcom-pro-5.7.16/libbinlogevents/include -I/export/home/somepath/mysqlcom-pro-5.7.16/sql -I/export/home/somepath/mysqlcom-pro-5.7.16/sql/auth -I/export/home/somepath/mysqlcom-pro-5.7.16/regex -I/export/home/somepath/mysqlcom-pro-5.7.16/zlib -I/export/home/somepath/dep4/include -I/export/home/somepath/release/sql -I/export/home/somepath/mysqlcom-pro-5.7.16/extra/lz4   
> C_DEFINES = -DHAVE_CONFIG_H -DHAVE_LIBEVENT1 -DHAVE_OPENSSL -DHAVE_REPLICATION -DMYSQL_SERVER -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
> CXX_FLAGS =  -fPIC -Wall -Wextra -Wformat-security -Wvla -Woverloaded-virtual -Wno-unused-parameter -O3 -g -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing -DDBUG_OFF -I/export/home/somepath/release/include -I/export/home/somepath/mysqlcom-pro-5.7.16/extra/rapidjson/include -I/export/home/somepath/release/libbinlogevents/include -I/export/home/somepath/mysqlcom-pro-5.7.16/libbinlogevents/export -I/export/home/somepath/mysqlcom-pro-5.7.16/include -I/export/home/somepath/mysqlcom-pro-5.7.16/sql/conn_handler -I/export/home/somepath/mysqlcom-pro-5.7.16/libbinlogevents/include -I/export/home/somepath/mysqlcom-pro-5.7.16/sql -I/export/home/somepath/mysqlcom-pro-5.7.16/sql/auth -I/export/home/somepath/mysqlcom-pro-5.7.16/regex -I/export/home/somepath/mysqlcom-pro-5.7.16/zlib -I/export/home/somepath/dep4/include -I/export/home/somepath/release/sql -I/export/home/somepath/mysqlcom-pro-5.7.16/extra/lz4   
> CXX_DEFINES = -DHAVE_CONFIG_H -DHAVE_LIBEVENT1 -DHAVE_OPENSSL -DHAVE_REPLICATION -DMYSQL_SERVER -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
23a24
> CRYPTO_LIBRARY:FILEPATH=/export/home/somepath/dep4/lib/libcrypto.a
34c35
< FEATURE_SET:STRING=community
---
> FEATURE_SET:STRING=xlarge
44a46,48
> OPENSSL_INCLUDE_DIR:PATH=/export/home/somepath/dep4/include
> OPENSSL_LIBRARY:FILEPATH=/export/home/somepath/dep4/lib/libssl.a
> OPENSSL_ROOT_DIR:PATH=/export/home/somepath/dep4
73c77,78
< WITH_SSL:STRING=bundled
---
> WITH_SSL:STRING=/export/home/somepath/dep4
> WITH_SSL_PATH:PATH=/export/home/somepath/dep4

The size of the contents is more or less the same (22 Mbyte difference):

shell> du -ksc mysql*5.7.16-linux*/*

1355480 mysql-5.7.16-linux-glibc2.5-x86_64/bin
20      mysql-5.7.16-linux-glibc2.5-x86_64/COPYING
20      mysql-5.7.16-linux-glibc2.5-x86_64/docs
1220    mysql-5.7.16-linux-glibc2.5-x86_64/include
1217880 mysql-5.7.16-linux-glibc2.5-x86_64/lib
836     mysql-5.7.16-linux-glibc2.5-x86_64/man
4       mysql-5.7.16-linux-glibc2.5-x86_64/README
4144    mysql-5.7.16-linux-glibc2.5-x86_64/share
32      mysql-5.7.16-linux-glibc2.5-x86_64/support-files
2579636 mysql-5.7.16-linux-glibc2.5-x86_64

1345864 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin
4       mysql-advanced-5.7.16-linux-glibc2.5-x86_64/LICENSE.mysql
15664   mysql-advanced-5.7.16-linux-glibc2.5-x86_64/docs
1188    mysql-advanced-5.7.16-linux-glibc2.5-x86_64/include
1233168 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/lib
988     mysql-advanced-5.7.16-linux-glibc2.5-x86_64/man
4       mysql-advanced-5.7.16-linux-glibc2.5-x86_64/README
4144    mysql-advanced-5.7.16-linux-glibc2.5-x86_64/share
32      mysql-advanced-5.7.16-linux-glibc2.5-x86_64/support-files
2601060 mysql-advanced-5.7.16-linux-glibc2.5-x86_64

The biggest difference we see in the docs folder where the mysql.info file is located (left over from clean-up?):

shell> ll mysql-advanced-5.7.16-linux-glibc2.5-x86_64/docs
-rw-r--r-- 1 mysql mysql     1789 Sep 28 19:06 ChangeLog
-rw-r--r-- 1 mysql mysql     5969 Sep 28 19:45 INFO_BIN
-rw-r--r-- 1 mysql mysql      185 Sep 28 19:34 INFO_SRC
-rw-r--r-- 1 mysql mysql 16017476 Sep 28 19:06 mysql.info

If we want to see the different number of files:

for i in $(find mysql*5.7.16-linux* -maxdepth 1 -type d) ; do 
  echo -n $i": " ; 
  ( find $i -type f | wc -l ) ; 
done

mysql-5.7.16-linux-glibc2.5-x86_64/support-files: 5
mysql-5.7.16-linux-glibc2.5-x86_64/share: 62
mysql-5.7.16-linux-glibc2.5-x86_64/man: 41
mysql-5.7.16-linux-glibc2.5-x86_64/bin: 38
mysql-5.7.16-linux-glibc2.5-x86_64/lib: 116
mysql-5.7.16-linux-glibc2.5-x86_64/docs: 3
mysql-5.7.16-linux-glibc2.5-x86_64/include: 107
mysql-5.7.16-linux-glibc2.5-x86_64: 374

mysql-advanced-5.7.16-linux-glibc2.5-x86_64/support-files: 5
mysql-advanced-5.7.16-linux-glibc2.5-x86_64/share: 66
mysql-advanced-5.7.16-linux-glibc2.5-x86_64/man: 41
mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin: 38
mysql-advanced-5.7.16-linux-glibc2.5-x86_64/lib: 128
mysql-advanced-5.7.16-linux-glibc2.5-x86_64/docs: 4
mysql-advanced-5.7.16-linux-glibc2.5-x86_64/include: 107
mysql-advanced-5.7.16-linux-glibc2.5-x86_64: 391

Those are the important differences:

-rw-r--r-- 1 mysql mysql     1046 Sep 28 19:02 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/share/audit_log_filter_linux_install.sql
-rw-r--r-- 1 mysql mysql     1052 Sep 28 19:02 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/share/audit_log_filter_win_install.sql
-rw-r--r-- 1 mysql mysql      239 Sep 28 19:33 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/share/uninstall_rewriter.sql
-rw-r--r-- 1 mysql mysql     2207 Sep 28 19:02 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/share/win_install_firewall.sql

-rw-r--r-- 1 mysql mysql 16017476 Sep 28 19:06 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/docs/mysql.info

-rwxr-xr-x 1 mysql mysql  3556085 Sep 28 19:35 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/lib/plugin/audit_log.so
-rwxr-xr-x 1 mysql mysql    73855 Sep 28 19:35 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/lib/plugin/authentication_pam.so
-rwxr-xr-x 1 mysql mysql  1595720 Sep 28 19:35 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/lib/plugin/firewall.so
-rwxr-xr-x 1 mysql mysql  3748543 Sep 28 19:35 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/lib/plugin/keyring_okv.so
-rwxr-xr-x 1 mysql mysql  2283844 Sep 28 19:35 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/lib/plugin/openssl_udf.so
-rwxr-xr-x 1 mysql mysql   567032 Sep 28 19:34 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/lib/plugin/thread_pool.so

So basically all MySQL Enterprise Server feature files.

The most imporant MySQL binaries

Let us have a look at the most important MySQL binaries:

shell> ll mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql
shell> ll mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqlbinlog mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqlbinlog
shell> ll mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqld mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqld
shell> ll mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqldump mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqldump
shell> ll mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql_install_db mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql_install_db
shell> ll mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql_upgrade mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql_upgrade

-rwxr-xr-x 1 mysql mysql  10884339 Sep 28 20:04 mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql
-rwxr-xr-x 1 mysql mysql   9815101 Sep 28 19:38 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql
-rwxr-xr-x 1 mysql mysql  11780342 Sep 28 20:06 mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqlbinlog
-rwxr-xr-x 1 mysql mysql  10711774 Sep 28 19:39 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqlbinlog
-rwxr-xr-x 1 mysql mysql 253303409 Sep 28 20:11 mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqld
-rwxr-xr-x 1 mysql mysql 253876847 Sep 28 19:42 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqld
-rwxr-xr-x 1 mysql mysql   9989115 Sep 28 20:06 mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqldump
-rwxr-xr-x 1 mysql mysql   8921087 Sep 28 19:39 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqldump
-rwxr-xr-x 1 mysql mysql  10711017 Sep 28 20:04 mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql_install_db
-rwxr-xr-x 1 mysql mysql   8883445 Sep 28 19:38 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql_install_db
-rwxr-xr-x 1 mysql mysql  13025173 Sep 28 20:07 mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql_upgrade
-rwxr-xr-x 1 mysql mysql  11961246 Sep 28 19:40 mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql_upgrade

Here you can see some differences I cannot explain. Possibly they come from the use of the different SSL ~~and libedit/readline~~ libraries?

The files are basicaly of the same type/style:

shell> file mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql
shell> file mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqlbinlog mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqlbinlog
shell> file mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqld mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqld
shell> file mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqldump mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqldump
shell> file mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql_install_db mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql_install_db
shell> file mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql_upgrade mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql_upgrade

mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql:          ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqlbinlog:          ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqlbinlog: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqld:          ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqld: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqldump:          ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqldump: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql_install_db:          ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql_install_db: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql_upgrade:          ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql_upgrade: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

When we look into the symbol tables of those 6 binaries we can see some differences which IMHO are mostly caused because of the 2 different set of libraries:

nm mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql | cut -b20- >community.mysql
nm mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql | cut -b20- >enterprise.mysql
diff community.mysql enterprise.mysql | less

nm mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqlbinlog | cut -b20- >community.mysqlbinlog
nm mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqlbinlog | cut -b20- >enterprise.mysqlbinlog
diff community.mysqlbinlog enterprise.mysqlbinlog | less

nm mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqld | cut -b20- >community.mysqld
nm mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqld | cut -b20- >enterprise.mysqld
diff community.mysqld enterprise.mysqld | less

nm mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysqldump | cut -b20- >community.mysqldump
nm mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysqldump | cut -b20- >enterprise.mysqldump
diff community.mysqldump enterprise.mysqldump | less

nm mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql_install_db | cut -b20- >community.mysql_install_db
nm mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql_install_db | cut -b20- >enterprise.mysql_install_db
diff community.mysql_install_db enterprise.mysql_install_db | less

nm mysql-5.7.16-linux-glibc2.5-x86_64/bin/mysql_upgrade | cut -b20- >community.mysql_upgrade
nm mysql-advanced-5.7.16-linux-glibc2.5-x86_64/bin/mysql_upgrade | cut -b20- >enterprise.mysql_upgrade
diff community.mysql_upgrade enterprise.mysql_upgrade | less

Here are the files for your own research: mysql_community_and_enterprise_symbols.tar.gz

Some more details:

shell> grep zlib community.mysql enterprise.mysql
community.mysql:zlibCompileFlags
community.mysql:zlibVersion
enterprise.mysql:COMP_zlib
enterprise.mysql:COMP_zlib_cleanup
enterprise.mysql:zlibCompileFlags
enterprise.mysql:zlib_method_nozlib
enterprise.mysql:zlibVersion

shell> diff community.mysqld enterprise.mysqld  | grep -i partit
no differences

shell> diff community.mysqld enterprise.mysqld  | grep -i err_                 
< err_helper
> ERR_add_error_data
> ERR_add_error_vdata
> ERR_clear_error
> err_defaults
> ERR_error_string
> ERR_error_string_n
> err_fns
> ERR_free_strings
> ERR_func_error_string
> ERR_get_error
> ERR_get_error_line
> ERR_get_error_line_data
> ERR_get_err_state_table
> ERR_get_implementation
> ERR_get_next_error_library
> ERR_get_state
> ERR_get_string_table
> ERR_lib_error_string
> ERR_load_ASN1_strings
> ERR_load_BIO_strings
> ERR_load_BN_strings
> ERR_load_BUF_strings
> ERR_load_CMS_strings
> ERR_load_COMP_strings
> ERR_load_CONF_strings
> ERR_load_crypto_strings
> ERR_load_CRYPTO_strings
> ERR_load_DH_strings
> ERR_load_DSA_strings
> ERR_load_DSO_strings
> ERR_load_ECDH_strings
> ERR_load_ECDSA_strings
> ERR_load_EC_strings
> ERR_load_ENGINE_strings
> ERR_load_ERR_strings
> ERR_load_EVP_strings
> ERR_load_OBJ_strings
> ERR_load_OCSP_strings
> ERR_load_PEM_strings
> ERR_load_PKCS12_strings
> ERR_load_PKCS7_strings
> ERR_load_RAND_strings
> ERR_load_RSA_strings
> ERR_load_SSL_strings
> ERR_load_strings
> ERR_load_TS_strings
> ERR_load_UI_strings
> ERR_load_X509_strings
> ERR_load_X509V3_strings
> ERR_peek_error
> ERR_peek_error_line
> ERR_peek_error_line_data
> ERR_peek_last_error
> ERR_peek_last_error_line
> ERR_peek_last_error_line_data
> ERR_pop_to_mark
> ERR_print_errors
> ERR_print_errors_cb
> ERR_print_errors_fp
> ERR_put_error
> ERR_reason_error_string
> ERR_release_err_state_table
> ERR_remove_state
> ERR_remove_thread_state
> ERR_set_error_data
> ERR_set_implementation
> ERR_set_mark
> err_state_LHASH_COMP
> err_state_LHASH_HASH
> ERR_str_functs
> err_string_data_LHASH_COMP
> err_string_data_LHASH_HASH
> ERR_str_libraries
> ERR_str_reasons
> ERR_unload_strings
> int_err_del
> int_err_del_item
> int_err_get
> int_err_get_item
> int_err_get_next_lib
> int_err_library_number
> int_err_set_item
< yaERR_error_string
< yaERR_error_string_n
< yaERR_free_strings
< yaERR_get_error
< yaERR_get_error_line_data
< yaERR_GET_REASON
< yaERR_peek_error
< yaERR_print_errors_fp
< yaERR_remove_state
< _ZZ18yaERR_error_stringE3msg

MySQL Enterprise Server and MySQL Community Server packages

This is not directly MySQL Server related but it affects operation as well: We found today that the MySQL Enterprise Server RPM package and the MySQL Community Server packages were not prepared the same. The MySQL Enterprise Server for MySQL 5.7.15 package was still using sysV init scripts whereas the MySQL 5.7.15 Community Server package seems to use already SystermD unit files (since MySQL 5.7.6: Managing MySQL Server with systemd). This has change from MySQL 5.7.15 to MySQL 5.7.16 Enterprise Server. So if you side-grade from MySQL Community to MySQL Enterprise Server you might experience some surprises...

Taxonomy upgrade extras:

mysql server

mysql community server

mysql enterprise server

enterprise

↧

Multi-Instance set-up with MySQL Enterprise Server 5.7 on RHEL 7 with SystemD

October 26, 2016, 1:15 pm

≫ Next: New Features in MySQL and MariaDB

≪ Previous: What are the differences between MySQL Community and MySQL Enterprise Server 5.7

In our current project the customer wants to install and run multiple MySQL Enterprise Server 5.7 Instances on the same machine (yes, I know about virtualization (we run on kvm), containers, Docker, etc.). He wants to use Red Hat Enterprise Linux (RHEL) 7 which brings the additional challenge of SystemD. So mysqld_multi is NOT an option any more.

We studied the MySQL documentation about the topic: Configuring Multiple MySQL Instances Using systemd. But to be honest: It was not really clear to me how to do the job...

So we started to work out our own cook-book which I want to share here.

The requirements are as follows:

Only ONE version of MySQL Enterprise Server binaries at a time is available. If you want to have more complicated set-ups (multi version) consider our MyEnv.
Because Segregation of Duties is an issue for this customer from the financial industries we are not allowed to use the operating system root user or have sudo privileges.
We have to work with the operating system user mysql as non privileged user.

Preparation work for the operating system administrator

This is the only work which has to be done under a privileged account (root):

shell> sudo yum install libaio
shell> sudo groupadd mysql
shell> sudo useradd -r -g mysql -s /bin/bash mysql
shell> sudo cp mysqld@.service /etc/systemd/system/

Installation of MySQL Enterprise Server binaries as non privileged user

To perform this task we need the generic MySQL Binary Tar Balls which you can get from the Oracle Software Delivery Cloud:

shell> mkdir /home/mysql/product
shell> cd /home/mysql/product
shell> tar xf /download/mysql-<version>.tar.gz
shell> ln -s mysql-<version> mysql-5.7.x
shell> ln -s mysql-5.7.x mysql
shell> echo 'export PATH=$PATH:/home/mysql/product/mysql/bin'>> ~/.bashrc
shell> . ~/.bashrc

Creating, Starting and Stopping several MySQL Enterprise Server Instances

shell> export INSTANCE_NAME=TMYSQL01   # and TMYSQL02 and TMYSQL03
shell> mkdir -p /mysql/${INSTANCE_NAME}/etc /mysql/${INSTANCE_NAME}/log /mysql/${INSTANCE_NAME}/data /mysql/${INSTANCE_NAME}/binlog
shell> cat /mysql/${INSTANCE_NAME}/etc/my.cnf
#
# /mysql/${INSTANCE_NAME}/etc/my.cnf
#
[mysqld]
datadir   = /mysql/${INSTANCE_NAME}/data
pid_file  = /var/run/mysqld/mysqld_${INSTANCE_NAME}.pid
log_error = /mysql/${INSTANCE_NAME}/log/error_${INSTANCE_NAME}.log
port      = 3306   # and 3307 and 3308
socket    = /var/run/mysqld/mysqld_${INSTANCE_NAME}.sock
_EOF
shell> cd /home/mysql/product/mysql
shell> bin/mysqld --defaults-file=/mysql/${INSTANCE_NAME}/etc/my.cnf --initialize --user=mysql --basedir=/home/mysql/product/mysql
shell> bin/mysqld --defaults-file=/mysql/${INSTANCE_NAME}/etc/my.cnf --daemonize >/dev/null 2>&1 &
shell> mysqladmin --user=root --socket=/var/run/mysqld/mysqld_${INSTANCE_NAME}.sock --password shutdown

So far so good. We can do everything with the database without root privileges. One thing is missing: The MySQL Database Instances should be started automatically at system reboot. For this we need a SystemD unit file:

#
# /etc/systemd/system/mysqld@.service
#

[Unit]

Description=Multi-Instance MySQL Enterprise Server
After=network.target syslog.target


[Install]

WantedBy=multi-user.target
 

[Service]

User=mysql
Group=mysql
Type=forking
PIDFile=/var/run/mysqld/mysqld_%i.pid
TimeoutStartSec=3
TimeoutStopSec=3
# true is needed for the ExecStartPre
PermissionsStartOnly=true
ExecStartPre=/bin/mkdir -p /var/run/mysqld
ExecStartPre=/bin/chown mysql: /var/run/mysqld
ExecStart=/home/mysql/product/mysql/bin/mysqld --defaults-file=/mysql/%i/etc/my.cnf --daemonize
LimitNOFILE=8192
Restart=on-failure
RestartPreventExitStatus=1
PrivateTmp=false

This file must be copied as root to:

shell> cp mysqld@.service /etc/systemd/system/

Now you can check if SystemD behaves correctly as follows:

shell> sudo systemctl daemon-reload
shell> sudo systemctl enable mysqld@TMYSQL01   # also TMYSQL02 and TMYSQL03
shell> sudo systemctl start mysqld@TMYSQL01
shell> sudo systemctl status 'mysqld@TMYSQL*'
shell> sudo systemctl start mysqld@TMYSQL01

How to go even further

If you need a more convenient or a more flexible solution you can go with our MySQL Enterprise Environment MyEnv.

Taxonomy upgrade extras:

multi instance

mysqld_multi

mysql enterprise server

↧

New Features in MySQL and MariaDB

November 22, 2016, 6:45 am

≫ Next: MySQL and MariaDB variables inflation

≪ Previous: Multi-Instance set-up with MySQL Enterprise Server 5.7 on RHEL 7 with SystemD

As you probably know MySQL is an Open Source product licensed under the GPL v2. The GPL grants you the right to not just read and understand the code of the product but also to use, modify AND redistribute the code as long as you follow the GPL rules.

This redistribution has happened in the past various times. But in the western hemisphere only 3 of these branches/forks of MySQL are of relevance for the majority of the MySQL users: Galera Cluster for MySQL, MariaDB (Server and Galera Cluster) and Percona Server (and XtraDB Cluster).

Now it happened what has to happen in nature: The different branches/forks start to diverge (following the marketing rule: differentiate yourself from your competitors). The biggest an most important divergence happens now between MySQL and MariaDB.

Recently a customer of FromDual claimed that there is no more progress in the MySQL Server development whereas the MariaDB Server does significant progress. I was wondering a bit how this statement could have been made. So I try to summarize the New Features which have been added since the beginning of the separation starting with MySQL 5.1.

It is important to know, that some parts of MySQL code are directly or in modified form ported to MariaDB whereas some MariaDB features were implemented in MySQL as well. So missing features in MariaDB or improvements in MySQL can possibly make it sooner or later also into MariaDB and vice versa. Further both forks were profiting significantly from old MySQL 6.0 code which was never really announced broadly.

Further to consider: Sun Microsystems acquired MySQL in January 2008 (MySQL 5.1.23 was out then and MySQL 5.2, 5.4 and 6.0 were in the queue) and Sun was acquired by Oracle in January 2010 (MySQL 5.1.43, MySQL 5.5.1 were out, MySQL 5.2, 5.4 and 6.0 were abandoned and MySQL 5.6 was in the queue).

MySQL 5.1	MariaDB 5.1 (link), 5.2 (link) and 5.3 (link)
Partitioning Row-based replication Plug-in API Event scheduler. Server log tables. Upgrade program `mysql_upgrade`. Improvements to `INFORMATION_SCHEMA`. XML functions with `Xpath` support.	MariaDB 5.1 Storage Engines Aria (Crash-safe MyISAM) XtraDB plug-in (Branch of InnoDB) PBXT (transactional Storage Engine) Federated-X (replacement for Federated). Performance Faster `CHECKSUM TABLE`. Character Set conversion improvement/elimination. Speed-up of complex queries using Aria SE for temporary tables. Optimizer: Table elimination. Upgrade from MySQL 5.0 improved. Better testing. Microseconds precision in `PROCESSLIST`. MariaDB 5.2 Storage Engines OQGRAPH (Graph SE) SphinxSE (Full-text search engine) Performance Segmented MyISAM key cache (instances) Group Commit for Aria SE Security Pluggable Authentication Virtual columns Extended user statistics Storage Engine specific `CREATE TABLE` Enhancements to `INFORMATION_SCHEMA.PLUGINS` table MariaDB 5.3 Performance Subquery Optimization Semi-join subquery optimizations Non-semi-join optimizations Subquery Cache Subquery is not materialized any more in `EXPLAIN` Optimization for derived tables and views No early materialization of derived tables Derived Table Merge optimization Derived Table with Keys optimization Fields of mergeable views and derived tables are involved in optimization Disk access optimization Index Condition Pushdown (ICP) Multi-Range-Read optimization (MRR) Join optimizations Block-based Join Algorithms: Block Nested Loop (BNL) for outer joins, Block Hash Joins, Block Index Joins (Batched Key Access (BKA) Joins) Index Merge improvements Replication Group Commit for Binary Log Annotation of row-based replication events with the original SQL statement Checksum for binlog events Enhancements for `START TRANSACTION WITH CONSISTENT SNAPSHOT` Performance improvement for row-based replication for tables with no primary key Handler Socket Interface included. `HANDLER READ` works with prepared statements Dynamic Column support for Handler Interface Microsecond support `CAST` extended Windows performance improvements New status variables Progress reports for some operations Enhanced `KILL` command
MySQL 5.5 (link)	MariaDB 5.5 (link)
InnoDB InnoDB Version 5.5 Default storage engine switched to InnoDB. InnoDB fast `INDEX DROP/CREATE` feature added. Multi-core scalability. Focus on InnoDB, especially locking and memory management. Optimizing InnoDB I/O subsystem to more effective use of available I/O capacity. Performance MySQL Thread Pool plug-in (Enterprise) Security MySQL Audit plug-in (Enterprise) MySQL pluggable authentication (Enterprise) for LDAP, Kerberos, PAM and Windows login Replication Semi-synchronous replication. Partitioning 2 new partition types (`RANGE COLUMNS, LIST COLUMNS`). `TRUNCATE PARTITION`. Proxy Users Diagnostic improvements to better access execution an performance information including `PERFORMANCE_SCHEMA`, expanded `SHOW ENGINE INNODB STATUS` output and new status variables. Supplementary Unicode characters (`utf16, utf32, utf8mb4`). `CACHE INDEX` and `LOAD INDEX INTO CACHE` for partitioned MyISAM tables. Condition Handling: `SIGNAL` and `RESIGNAL`. Introduction of Metadata locking to prevent DDL statements from compromising transactions serializability. IPv6 Support XML enhancement `LOAD_XML_INFILE`. Build chain switched to CMake to ease build on other platforms including Windows. Deprecation and remove of features.	Storage Engines SphinxSE updated to 2.0.4 PBXT Storage Engine is deprecated. XtraDB MariaDB uses XtraDB 5.5 as compiled in SE and InnoDB 5.5 as plug-in. Extended Keys support for XtraDB Performance Thread pool plug-in Non-blocking client API Library Replication Updates on P_S tables are not logged to binary log. `replicate_*` variables are dynamically. `Skip_replication` option `LIMIT ROWS EXAMINED` New status variables for features. New plug-in to log SQL level errors.
MySQL 5.6 (link)	MariaDB 10.0 (link)
InnoDB InnoDB Version 5.6 InnoDB full-text search. InnoDB transportable tablespace support Different InnoDB pages size implementation (4k, 8k, 16k) Improvement of InnoDB adaptive flushing algorithm to make I/O more efficient. NoSQL style Memcached API to access InnoDB data. InnoDB optimizer persistent statistics. InnoDB read-only transactions. Separating InnoDB UNDO tablespace from system tablespace. Maximum InnoDB transaction log size increased from 4G to 512G. InnoDB read-only capability for read-only media (CD, DVD, etc.) InnoDB table compression. New InnoDB meta data table in `INFORMATION_SCHEMA`. InnoDB internal performance performance enhancements. Better InnoDB deadlock detection algorithm. Deadlock can be written to MySQL error log. InnoDB buffer pool state saving and restoring capabilities. InnoDB Monitor dynamially disable/enable. Online and inplace DDL operations for normal and partitioned InnoDB Tables to reduce application downtime. Optimizer `ORDER BY` non-index-column for simple queries and subqueries Disk-Sweep Multi-Range Read (MRR) optimization for secondary index/table access to reduce I/O Index Condition Pushdown (ICP) optimization by pushing down the `WHERE` filter to the storage engine. `EXPLAIN` also works for DML statemetns. Optimizing of subqueries in derived tables (`FROM (...)`) by postponing or indexing deived tables. Implementation of semi-join and materialization strategies to optimize subquery execution. Batched Key Access (BKA) join algorithm to improve join performance during table scanning. Optimizer trace capabilities. Performance Schema (P_S) Instrumentation for Statements and stages Configuration of consumers at server startup Summary tables for table and index I/O and for table locks Event filtering by table Various new instrumentation. Security Encrypted authentication credentials Stronger encryption for passwords (SHA-256 authentication plugin) MySQL User password expiration. Password validation plugin to check password strength mysql_install_db can create secure root password by default cleartext password is not written to any log file any more. MySQL Firewall (Enterprise) Replication Transaction based replication using global transaction identifiers (GTID) Row Image Control to reduce binary log volume. Crash-safe replication with checksumming and verfiying. IO and SQL thread information can be stored in an transactional table inside the DB. MySQL binlog streaming with mysqlbinlog possible. Delayes replication Parallel replication on schema level. Partitioning Number of partitions including subpartitions increased to 8192. Exchange partition with a normal table. Explicit selection of specific partiton is possible. Partition lock prunining for DML and DDL statements. Condition handling: `GET DIAGNOSTICS` and `SET DIAGNOSTICS` Server defaults changes. Data types `TIME`, `DATETIME` and `TIMESTAMP` with microseconds Host cache exposure and connection errors status infromation for finding connection problems. Improvement in GIS functions. Deprecation and remove of features.	Storage Engine Cassandra Storage Engine Conncect Storage Engine Squence Storage Engine Better table discovery (Federated-X) Spider Storage Engine TokuDB Storage Engine Mroonga fulltext search Storage Engine XtraDB XtraDB Version 5.6 Async commit checkpoint in XtraDB and InnoDB Support for atomic writes on FusionIO DirectFS Replication Parallel Replication Global Transaction ID (GTID) Multi Source Replication Performance Subquery Optimization (`EXISTS` to `IN`) Faster `UNIQUE KEY` generation Shutdown performance improvment for MyISAM/Aria table (adjustable hash size) Security Roles MariaDB Audit Plugin Optimizer `EXPLAIN` for DML Statements Engine independent table statistics Histogram based statistics `QUERY_RESPONSE_TIME` plugin `SHOW EXPLAIN` for running connections `EXPLAIN` in the Slow Query Log Per thread memory usage statistics `SHOW PLUGINS SONAME` `SHUTDOWN` command Killing a query by query id not thread id. Return result set of delete rows with `DELETE ... RETURNING` `ALTER TABLE IF (NOT) EXISTS` `CREATE OR REPLACE TABLE` Dynamic columns referenced by name Multiple use locks (`GET_LOCK`) in one connection Better error messages New regular expressions (PCRE) `REGEXP_REPLACE`, `REGEXP_INSTR`, `REGEXP_SUBSTR` Metadata lock information in `INFORMATION_SCHEMA` Priority queue optimzation visibility `FLUSH TABLE ... FOR EXPORT` flushes changes to disk for binary copy `CURRENT_TIMESTAMP` as `DEFAULT` for `DATETIME` Various features backported from MySQL 5.6
MySQL 5.7 (link)	MariaDB 10.1 (link)
InnoDB InnoDB Version 5.7 `VARCHAR` size increase can be in-place in some cases. DDL performance improvements for temporary InnoDB tables (`CREATE DROP TRUNCATE, ALTER`) Active InnoDB temporary table metadata are exposed in table `INNODB_TEMP_TABLE_INFO`. InnoDB support spatial data type (GIS, `DATA_GEOMETRY`) Separate tablespace for temporary InnoDB tables. Support for InnoDB Full-text parser plugins was added. Multiple page cleaner threads were added. Regular an paritioned InnoDB tables can be rebuilt using online inplace DDL commands (`OPTIMZE, ALTER TABLE FORCE`) Automatic detection, support and optimization for Fusion-io NVM file system to support atomic writes. Better support for Transportable Tablespaces to ease backup process. InnoDB Buffer Pool size can be configured dynamically. Multi-threaded page cleaner support for shutdown and recovery phase. InnoDB spatial index support for online in place operation (`ADD SPATIAL INDEX`) InnoDB sorted index builds to improve bulk loads. Identification of modified tablespaces to increase crash recovery performance. InnoDB UNDO log truncation. InnoDB native partion support. InnoDB general tablespace support for databases with a huge amount of tables. InnoDB data at rest encryption for file-per-table tablespaces. Performance `EXPLAIN` for running connections (`FOR CONNECTIONS`) Finer Control of optimizer hints. Security Old password support has been removed. Autmomatic password expiry policies. Lock and unlock of accounts. SSL and RSA certificate and key file generation. SSL enabled automatically if available. MySQL will be initialized secure by default (= hardened) `STRICT_TRANS_TABLES sql_mode` is now enabled by default. `ONLY_FULL_GROUP_BY sql_mode` made more sophisticated to only prohibit non deterministic query. Replication Master dump thread was refactored to improve throughput. Replication Master change without `STOP SLAVE`. Multi-source replication introduced. Partitioning `HANDLER` statment works now on partitioned tables. Index Condition Pushdown (ICP) works for partitioned InnoDB and MyISAM tables. `ALTER TABLE EXCHANGE PARTITION WITHOU VALIDATION` is possible to improve performance of exchnage. Native JSON support Data type JSON. JSON functions: `JSON_ARRAY, JSON_MERGE, JSON_OBJECT, JSON_CONTAINS, JSON_CONTAINS_PATH, JSON_EXTRACT, JSON_KEYS, JSON_SEARCH, JSON_APPEND, JSON_ARRAY_APPEND, JSON_ARRAY_INSERT, JSON_INSERT, JSON_QUOTE, JSON_REMOVE, JSON_REPLACE, JSON_SET, JSON_UNQUOTE, JSON_DEPTH, JSON_LENGTH, JSON_TYPE, JSON_VALID` System and status variables moved from `INFORMATION_SCHEMA` to `PERFORMANCE_SCHEMA`. Sys Schema created by default. Condition handling: `GET STACKED DIAGNOSTICS` Multiple triggers per event are possible now. Native logging to syslog possible. Generated Column support. Database rewriting in mysqlbinlog. Control+C in mysql client does not exit any more but interrupts query only. New China National Standard GB18030 character set. `RENAME INDEX` is online inplace without a table copy. Chinese, Japanese and Korean (CJK) full-text parser implemented (ngram MeCab full-test parser plugins). Deprecation and remove of features. Literature Complete list of new features in MySQL 5.7	XtraDB Allow up to 64K pages in InnoDB (old limit was 16K). Defragmenting InnoDB Tablespaces improved which uses `OPTIMIZE TABLE` to defragment InnoDB tablespaces. XtraDB page compression Performance Page compression for FusionIO Do not create `.frm` files for temporary tables. `UNION ALL` works without usage of a temporary table. Scalability fixes for Power8. Performance improvementes on simple queries. Performance Schema tables no longer use .frm files. xid cache scalability was significantly improved. Replication Optimistic mode of in-order parallel replication `domain_id` based replication filters Enhanced semisync replication: Wait for at least one slave to acknowledge transaction before committing. Triggers can now be run on the slave for row-based events. Dump Thread Enhancements: Makes multiple slave setups faster by allowing concurrent reading of binary log. Throughput improvements in parallel replication. `RESET_MASTER` is extended with `TO`. Optimizer `ANALYZE` statement provides output for how many rows were actually read, etc. `EXPLAIN FORMAT=JSON` `ORDER BY` optimization is improved. `MAX_STATEMENT_TIME` can be used to automatically abort long running queries. Security Password validation plug-in API. Simple password check password validation plugin. Cracklib_password_check password validation plugin. Table, Tablespace and Log at-rest encryption (TDE) `SET DEFAULT ROLE` New columns for the `INFORMATION_SCHEMA.APPLICABLE_ROLES` table. Galera Cluster plug-in becomes standard in MariaDB. Wsrep information in `INFORMATION_SCHEMA: WSREP_MEMBERSHIP` and `WSREP_STATUS` Consistent support for `IF EXISTS` and `IF NOT EXISTS` and `OR REPLACE` for: `CREATE DATABASE, CREATE FUNCTION UDF, CREATE ROLE, CREATE SERVER, CREATE USER, CREATE VIEW, DROP ROLE, DROP USER, CREATE EVENT, DROP EVENT, CREATE INDEX, DROP INDEX, CREATE TRIGGER, DROP TRIGGER` Information Schema plugins can now support `SHOW` and `FLUSH` statements. `GET_LOCK()` now supports microseconds in the timeout. The number of rows affected by a slow `UPDATE` or `DELETE` is now recorded in the slow query log. Anonymous Compount Statents blocks are supported. SQL standards-compliant behavior when dealing with Primary Keys with Nullable Columns. Automatic discovery of `PERFORMANCE_SCHEMA` tables. `INFORMATION_SCHEMA.SYSTEM_VARIABLES, enforce_storage_engine, default-tmp-storage-engine, mysql56-temporal-format, Slave_skipped_errors, silent-startup` New status variables to show the number of grants on different object. Set variables per statement: `SET STATEMENT` Support for Spatial Reference systems for the GIS data. More functions from the OGC standard added: `ST_Boundary, ST_ConvexHull, ST_IsRing, ST_PointOnSurface, ST_Relate` GIS `INFORMATION_SCHEMA` tables: `GEOMETRY_COLUMNS`, `SPATIAL_REF_SYS`
MySQL 8.0 (link)	MariaDB 10.2 (link)
InnoDB InnoDB Version 8.0 `AUTO_INCREMENT` values are persisted accross server restarts. Index corruption and in-memory corruption detection written persistently to the transaction log. InnoDB Memcached plug-in supports multiple get operations. Deadlock detection can be disabled and leads to a lock timeout to increase performance. Index pages cached in buffer pool are listed in `INNODB_CACHED_INDEXES`. All InnoDB temporary tables are created in InnoDB shared temporary tablespace. JSON Inline path operator ->> added. Column paht operator -> improved. JSON aggregation functions `JSON_ARRAYAGG()` and `JSON_OBJECTAGG()` added. Security Account management supports roles. Aromicity in User Management DDLs. Transactional data dictionary (DD). Common Table Expressions (CTE, recursive SQL, Series creation) Descending Indexes Scaling and Performance of `INFORMATION_SCHEMA` (1 Mio table problem) Deprecation and remove of features. MySQL 8.0 is currently in a very early stage (DMR) so this list will increase over time!	XtraDB XtraDB Version 5.6 Security `SHOW CREATE USER` `CREATE USER` and `ALTER USER` extended for limiting resources and TLS/SSL support. Performance Connection creation speed-up by separate thread. Optimizer `EXPLAIN FORMAT=JSON` improved. Partition Catchall partion for `LIST` partions. Introduction of Window functions: `CUME_DIST, DENSE_RANK, NTILE, PERCENT_RANK, RANK, ROW_NUMBER` `WITH` clause for recursive queries. `CHECK CONSTRAINT` support. Support for `DEFAULT` with expression. `BLOB` and `TEXT` can now have default values. Virtual computed columns restrictions lifted. Supported decimals in `DECIMAL` increased from 30 to 38. Multiple triggers for the same event. Oracle style `EXECUTE IMMEDIATE`. `PREPARE STATEMENT` understand most expressions. `I_S.USER_VARIABLES` introduced as plug-in. New status information: `com_alter_user, com_multi, com_show_create_user`. New variables: `innodb_tmpdir, read_binlog_speed_limit`. To come soon MariaDB Column store (ex. InfiniDB) MyRocks? MariaDB 10.2 is currently in a early stage (beta release) so this list will increase over time...
MySQL 9.0	MariaDB 10.3 (link) and 10.4
No details are known yet. ~~MySQL developer meetingt took place in November 2016~~.	Literature: MariaDB.org Launchpad Suggested features Hidden columns Long unique constraints SQL based `CREATE AGGREGATE FUNCTION` New data types: `IPv6`, `UUID`, pluggable data-type API Better support for CJK (Chinese, Japanese, and Korean) languages. Include the ngram full-text parser and MeCab full-text parser . Improvement of Spider SE. Support for `SEQUENCES` Additional PL/SQL parser Support for `INTERSECT` Support for `EXCEPT` MariaDB 10.3 is currently in a very early stage so this list will increase over time!

Please let me know if I got something wrong or forgot any significant feature for theses 2 MySQL branches.

Taxonomy upgrade extras:

↧

MySQL and MariaDB variables inflation

December 12, 2016, 12:43 pm

≫ Next: MySQL replication with filtering is dangerous

≪ Previous: New Features in MySQL and MariaDB

MySQL is well known and widely spread because of its philosophy of Keep it Simple (KISS).

We recently had the discussion that with newer releases also MySQL and MariaDB relational databases becomes more and more complicated.

One indication for this trend is the number of MySQL server system variables and status variables.

In the following tables and graphs we compare the different releases since MySQL version 4.0:

mysql> SHOW GLOBAL VARIABLES;
mysql> SHOW GLOBAL VARIABLES LIKE 'innodb%';
mysql> SHOW GLOBAL STATUS;
mysql> SHOW GLOBAL STATUS LIKE 'innodb%';

Version	System	IB Sys.	Status	IB Stat.
MySQL 4.0.30	143	22	*133	**0
MySQL 4.1.25	189	26	*164	**0
MySQL 5.0.96	239	36	252	42
MySQL 5.1.73	277	36	291	42
MySQL 5.5.51	317	60	312	47
MySQL 5.6.31	438	120	341	51
MySQL 5.7.15	491	131	353	51
MySQL 8.0.0	488	124	363	51

* Use SHOW STATUS instead.
** Use SHOW ENGINE INNODB STATUS\G instead.

Version	System	IB Sys.	Status	IB Stat.
MariaDB 5.1.44	354	72	301	44
MariaDB 5.2.10	397	86	324	46
MariaDB 5.5.41	419	103	413	99
MariaDB 10.0.21	537	147	455	95
MariaDB 10.1.18***	589	178	517	127
MariaDB 10.2.2****	586	164	481	96

*** XtraDB 5.6
****InnoDB 5.7.14???

Taxonomy upgrade extras:

↧

MySQL replication with filtering is dangerous

January 12, 2017, 7:47 am

≫ Next: Is your MySQL software Cluster ready?

≪ Previous: MySQL and MariaDB variables inflation

From time to time we see in customer engagements that MySQL Master/Slave replication is set-up doing schema or table level replication filtering. This can be done either on Master or on Slave. If filtering is done on the Master (by the binlog_{do|ignore}_db settings), the binary log becomes incomplete and cannot be used for a proper Point-in-Time-Recovery. Therefore FromDual recommends AGAINST this approach.

The replication filtering rules vary depending on the binary log format (ROW and STATEMENT) See also: How Servers Evaluate Replication Filtering Rules.

For reasons of data consistency between Master and Slave FromDual recommends to use only the binary log format ROW. This is also stated in the MySQL documentation: All changes can be replicated. This is the safest form of replication. Especially dangerous is binary log filtering with binary log format MIXED. This binary log format FromDual strongly discourages users to use.

The binary log format ROW affects only DML statements (UPDATE, INSERT, DELETE, etc.) but NOT DDL statements (CREATE, ALTER, DROP, etc.) and NOT DCL statements (CREATE, GRANT, REVOKE, DROP, etc.). So how are those statements replicated? They are replicated in STATEMENT binary log format even though binlog_format is set to ROW. This has the consequences that the binary log filtering rules of STATEMENT based replication and not the ones of ROW based replication apply when running one of those DDL or DCL statements.

This can easily cause problems. If you are lucky, they will cause the replication to break sooner or later, which you can detect and fix - but they may also cause inconsistencies between Master and Slave which may remain undetected for a long time.

Let us show what happens in 2 similar scenarios:

Scenario A: Filtering on `mysql` schema

On Slave we set the binary log filter as follows:

replicate_ignore_db = mysql

and verify it:

mysql> SHOW SLAVE STATUS\G
...
          Replicate_Ignore_DB: mysql
...

The intention of this filter setting is to not replicate user creations or modifications from Master to the Slave.

We verify on the Master, that binlog_format is set to the wanted value:

mysql> SHOW GLOBAL VARIABLES LIKE 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+

Now we do the following on the Master:

mysql> use mysql
mysql> CREATE USER 'inmysql'@'%';
mysql> use test
mysql> CREATE USER 'intest'@'%';

and verify the result on the Master:

mysql> SELECT user, host FROM mysql.user;
+-------------+-----------+
| user        | host      |
+-------------+-----------+
| inmysql     | %         |
| intest      | %         |
| mysql.sys   | localhost |
| root        | localhost |
+-------------+-----------+

and on the Slave:

mysql> SELECT user, host FROM mysql.user;
+-------------+-----------+
| user        | host      |
+-------------+-----------+
| intest      | %         |
| mysql.sys   | localhost |
| root        | localhost |
+-------------+-----------+

We see, that the user intest was replicated and the user inmysql was not. And we have clearly an unwanted data inconsistency between Master and Slave.

If we want to drop the inmysql user some time later on the Master:

mysql> use myapp;
mysql> DROP USER 'inmysql'@'%';

we get the following error message on the Slave and are wondering, why this user or the query appears on the Slave:

mysql> SHOW SLAVE STATUS\G
...
               Last_SQL_Errno: 1396
               Last_SQL_Error: Error 'Operation DROP USER failed for 'inmysql'@'%'' on query. Default database: 'test'. Query: 'DROP USER 'inmysql'@'%''
...

A similar problem happens when we connect to NO database on the Master as follows and change the users password:

shell> mysql -uroot
mysql> SELECT DATABASE();
+------------+
| database() |
+------------+
| NULL       |
+------------+
mysql> ALTER USER 'innone'@'%' IDENTIFIED BY 'secret';

This works perfectly on the Master. But what happens on the Slave:

mysql> SHOW SLAVE STATUS\G
...
               Last_SQL_Errno: 1396
               Last_SQL_Error: Error 'Operation ALTER USER failed for 'innone'@'%'' on query. Default database: ''. Query: 'ALTER USER 'innone'@'%' IDENTIFIED WITH 'mysql_native_password' AS '*14E65567ABDB5135D0CFD9A70B3032C179A49EE7''
...

The Slave wants to tell us in a complicated way, that the user innone does not exist on the Slave...

Scenario B: Filtering on `tmp` or similar schema

An other scenario we have seen recently is that the customer is filtering out tables with temporary data located in the tmp schema. Similar scenarios are cache, session or log tables. He did it as follows on the Master:

mysql> use tmp;
mysql> TRUNCATE TABLE tmp.test;

As he has learned in FromDual trainings he emptied the table with the TRUNCATE TABLE command instead of a DELETE FROM tmp.test command which is much less efficient than the TRUNCATE TABLE command. What he did not consider is, that the TRUNCATE TABLE command is a DDL command and not a DML command and thus the STATEMENT based replication filtering rules apply. His filtering rules on the Slave were as follows:

mysql> SHOW SLAVE STATUS\G
...
          Replicate_Ignore_DB: tmp
...

When we do the check on the Master we get an empty set as expected:

mysql> SELECT * FROM tmp.test;
Empty set (0.00 sec)

When we add new data on the Master:

mysql> INSERT INTO tmp.test VALUES (NULL, 'new data', CURRENT_TIMESTAMP());
mysql> SELECT * FROM tmp.test;
+----+-----------+---------------------+
| id | data      | ts                  |
+----+-----------+---------------------+
|  1 | new data  | 2017-01-11 18:00:11 |
+----+-----------+---------------------+

we get a different result set on the Slave:

mysql> SELECT * FROM tmp.test;
+----+-----------+---------------------+
| id | data      | ts                  |
+----+-----------+---------------------+
|  1 | old data  | 2017-01-11 17:58:55 |
+----+-----------+---------------------+

and in addition the replication stops working with the following error:

mysql> SHOW SLAVE STATUS\G
...
                   Last_Errno: 1062
                   Last_Error: Could not execute Write_rows event on table tmp.test; Duplicate entry '1' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log laptop4_qa57master_binlog.000042, end_log_pos 1572
...

See also our earlier bug report of a similar topic: Option "replicate_do_db" does not cause "create table" to replicate ('row' log)

Conclusion

Binary log filtering is extremely dangerous when you care about data consistency and thus FromDual recommends to avoid binary log filtering by all means. If you really have to do binary log filtering you should exactly know what you are doing, carefully test your set-up, check your application and your maintenance jobs and also review your future code changes regularly. Otherwise you risk data inconsistencies in your MySQL Master/Slave replication.

Taxonomy upgrade extras:

↧

Is your MySQL software Cluster ready?

January 27, 2017, 9:19 am

≫ Next: MySQL and MariaDB authentication against pam_unix

≪ Previous: MySQL replication with filtering is dangerous

When we do Galera Cluster consulting we always discuss with the customer if his software is Galera Cluster ready. This basically means: Can the software cope with the Galera Cluster specifics?

If it is a software product developed outside of the company we recommend to ask the software vendor if the software supports Galera Cluster or not.

We typically see 3 different answers:

We do not know. Then they are at least honest.
Yes we do support Galera Cluster. Then they hopefully know what they are talking about but you cannot be sure and should test carefully.
No we do not. Then they most probably know what they are talking about.

If the software is developed in-house it becomes a bit more tricky because the responsibility for this statement has to be taken by you or some of your colleagues.

Thus it is good to know what are the characteristics and the limitations of a Cluster like Galera Cluster for MySQL.

Most of the Galera restrictions an limitation you can find here.

DDL statements cause TOI operations

DDL and DCL statements (like CREATE, ALTER, TRUNCATE, OPTIMIZE, DROP, GRANT, REVOKE, etc.) are executed by default in Total Order Isolation (TOI) by the Online Schema Upgrade (OSU) method. To achieve this schema upgrade consistently Galera does a global Cluster lock.

It is obvious that those DDL operations should be short and not very frequent to not always block your Galera Cluster. So changing your table structure must be planned and done carefully to not impact your daily business operation.

But there are also some not so obvious DDL statements causing TOI operations (and Cluster locks).

TRUNCATE TABLE ... This operation is NOT a DML statement (like DELETE) but a DDL statement and thus does a TOI operation with a Cluster lock.
CREATE TABLE IF NOT EXISTS ... This operation is clearly a DDL statement but one might think that it does NOT a TOI operation if the table already exists. This is wrong. This statement causes always a TOI operation if the table is there or not does not matter. If you run this statement very frequent this potentially causes troubles to your Galera Cluster.
CREATE TABLE younameit_tmp ... The intention is clear: The developer wants to create a temporary table. But this is NOT a temporary table but just a normal table called _tmp. So it causes as TOI operation as well. What you should do in this case is to create a real temporary table like this: CREATE TEMPORARY TABLE yournameit_tmp ... This DDL statement is only executed locally and will not cause a TOI operation.

How to check?

You can check the impact of this problem with the following sequence of statements:

mysql> SHOW GLOBAL STATUS LIKE 'Com_create_table%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Com_create_table | 4     |
+------------------+-------+

mysql> CREATE TABLE t1_tmp (id INT);

mysql> SHOW GLOBAL STATUS LIKE 'Com_create_table%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Com_create_table | 5     | --> Also changes on the Slave nodes!
+------------------+-------+

mysql> CREATE TEMPORARY TABLE t2_tmp (id INT);

mysql> SHOW GLOBAL STATUS LIKE 'Com_create_table%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Com_create_table | 6     | --> Does NOT change on the Slave nodes!
+------------------+-------+

mysql> CREATE TABLE IF NOT EXISTS t1_tmp (id INT);
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Com_create_table | 7     | --> Also changes on the Slave nodes!
+------------------+-------+

Find out in advance

If you want to find out before migrating to Galera Cluster if you are hit by this problem or not you can either run:

mysql> SHOW GLOBAL STATUS
WHERE variable_name LIKE 'Com_create%'
   OR variable_name LIKE 'Com_alter%'
   OR variable_name LIKE 'Com_drop%'
   OR variable_name LIKE 'Com_truncate%'
   OR variable_name LIKE 'Com_grant%'
   OR variable_name LIKE 'Com_revoke%'
   OR variable_name LIKE 'Com_optimize%'
   OR variable_name LIKE 'Com_rename%'
   OR variable_name LIKE 'Uptime'
;
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Com_create_db        | 2     |
| Com_create_table     | 6     |
| Com_optimize         | 1     |
| Uptime               | 6060  |
+----------------------+-------+

Or if you want to know exactly who was running the query from the PERFORMANCE_SCHEMA:

SELECT user, host, SUBSTR(event_name, 15) AS event_name, count_star
  FROM performance_schema.events_statements_summary_by_account_by_event_name
 WHERE count_star > 0 AND
     ( event_name LIKE 'statement/sql/create%'
    OR event_name LIKE 'statement/sql/alter%'
    OR event_name LIKE 'statement/sql/drop%'
    OR event_name LIKE 'statement/sql/rename%'
    OR event_name LIKE 'statement/sql/grant%'
    OR event_name LIKE 'statement/sql/revoke%'
    OR event_name LIKE 'statement/sql/optimize%'
    OR event_name LIKE 'statement/sql/truncate%'
    OR event_name LIKE 'statement/sql/repair%'
    OR event_name LIKE 'statement/sql/check%'
     )
;
+------+-----------+--------------+------------+
| user | host      | event_name   | count_star |
+------+-----------+--------------+------------+
| root | localhost | create_table |          4 |
| root | localhost | create_db    |          2 |
| root | localhost | optimize     |          1 |
+------+-----------+--------------+------------+

If you need help to make your application Galera Cluster ready we will be glad to assist you.

Taxonomy upgrade extras:

↧

MySQL and MariaDB authentication against pam_unix

February 13, 2017, 9:02 am

≫ Next: MySQL Enterprise Backup Incremental Cumulative and Differential Backup

≪ Previous: Is your MySQL software Cluster ready?

The PAM authentication plug-in is an extension included in MySQL Enterprise Edition (since 5.5) and in MariaDB (since 5.2).

MySQL authentication against `pam_unix`

The PAM Authentication Plugin

Check if plug-in is available:

# ll lib/plugin/auth*so
-rwxr-xr-x 1 mysql mysql 42937 Sep 18  2015 lib/plugin/authentication_pam.so
-rwxr-xr-x 1 mysql mysql 25643 Sep 18  2015 lib/plugin/auth.so
-rwxr-xr-x 1 mysql mysql 12388 Sep 18  2015 lib/plugin/auth_socket.so
-rwxr-xr-x 1 mysql mysql 25112 Sep 18  2015 lib/plugin/auth_test_plugin.so

Install PAM plug-in:

mysql> INSTALL PLUGIN authentication_pam SONAME 'authentication_pam.so';

Check plug-in information:

mysql> SELECT * FROM information_schema.plugins WHERE plugin_name = 'authentication_pam'\G
*************************** 1. row ***************************
           PLUGIN_NAME: authentication_pam
        PLUGIN_VERSION: 1.1
         PLUGIN_STATUS: ACTIVE
           PLUGIN_TYPE: AUTHENTICATION
   PLUGIN_TYPE_VERSION: 1.1
        PLUGIN_LIBRARY: authentication_pam.so
PLUGIN_LIBRARY_VERSION: 1.7
         PLUGIN_AUTHOR: Georgi Kodinov
    PLUGIN_DESCRIPTION: PAM authentication plugin
        PLUGIN_LICENSE: PROPRIETARY
           LOAD_OPTION: ON

It seems like this set-up is persisted and survives a database restart because of the mysql schema table:

mysql> SELECT * FROM mysql.plugin;
+--------------------+-----------------------+
| name               | dl                    |
+--------------------+-----------------------+
| authentication_pam | authentication_pam.so |
+--------------------+-----------------------+

Configuring PAM on Ubuntu/Debian:

#%PAM-1.0
#
# /etc/pam.d/mysql
#
@include common-auth
@include common-account
@include common-session-noninteractive

Create the database user matching to the O/S user:

mysql> CREATE USER 'oli'@'localhost'
IDENTIFIED WITH authentication_pam AS 'mysql'
;
mysql> GRANT ALL PRIVILEGES ON test.* TO 'oli'@'localhost';

Verifying user in the database:

mysql> SELECT user, host, authentication_string FROM mysql.user WHERE user = 'oli';
+-----------+-----------+-------------------------------------------+
| user      | host      | authentication_string                     |
+-----------+-----------+-------------------------------------------+
| oli       | localhost | mysql                                     |
+-----------+-----------+-------------------------------------------+

mysql> SHOW CREATE USER 'oli'@'localhost';
+-----------------------------------------------------------------------------------------------------------------------------------+
| CREATE USER for oli@localhost                                                                                                     |
+-----------------------------------------------------------------------------------------------------------------------------------+
| CREATE USER 'oli'@'localhost' IDENTIFIED WITH 'authentication_pam' AS 'mysql' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK |
+-----------------------------------------------------------------------------------------------------------------------------------+

Connection tests:

# mysql --user=oli --host=localhost
ERROR 2059 (HY000): Authentication plugin 'mysql_clear_password' cannot be loaded: plugin not enabled

# mysql --user=oli --host=localhost --enable-cleartext-plugin --password=wrong
ERROR 1045 (28000): Access denied for user 'oli'@'localhost' (using password: YES)

# tail /var/log/auth.log
Feb 13 15:15:14 chef unix_chkpwd[31600]: check pass; user unknown
Feb 13 15:15:14 chef unix_chkpwd[31600]: password check failed for user (oli)

# mysql --user=oli --host=localhost --enable-cleartext-plugin --password=rigth
ERROR 1045 (28000): Access denied for user 'oli'@'localhost' (using password: YES)

# tail /var/log/auth.log
Feb 13 15:15:40 chef unix_chkpwd[31968]: check pass; user unknown
Feb 13 15:15:40 chef unix_chkpwd[31968]: password check failed for user (oli)

Some research led to the following result: The non privileged mysql user is not allowed to access the file /etc/shadow thus it should be added to the group shadow to make it work:

# ll /sbin/unix_chkpwd
-rwxr-sr-x 1 root shadow 35536 Mar 16  2016 /sbin/unix_chkpwd

# usermod -a -G shadow mysql

Connection tests:

# mysql --user=oli --host=localhost --enable-cleartext-plugin --password=rigth

mysql> SELECT USER(), CURRENT_USER(), @@proxy_user;
+---------------+----------------+--------------+
| USER()        | CURRENT_USER() | @@proxy_user |
+---------------+----------------+--------------+
| oli@localhost | oli@localhost  | NULL         |
+---------------+----------------+--------------+

MariaDB authentication against `pam_unix`

PAM Authentication Plugin

Check if plug-in is available:

# ll lib/plugin/auth*so
-rwxr-xr-x 1 mysql mysql 12462 Nov  4 14:37 lib/plugin/auth_0x0100.so
-rwxr-xr-x 1 mysql mysql 33039 Nov  4 14:37 lib/plugin/auth_gssapi_client.so
-rwxr-xr-x 1 mysql mysql 80814 Nov  4 14:37 lib/plugin/auth_gssapi.so
-rwxr-xr-x 1 mysql mysql 19015 Nov  4 14:37 lib/plugin/auth_pam.so
-rwxr-xr-x 1 mysql mysql 13028 Nov  4 14:37 lib/plugin/auth_socket.so
-rwxr-xr-x 1 mysql mysql 23521 Nov  4 14:37 lib/plugin/auth_test_plugin.so

Install PAM plug-in:

mysql> INSTALL SONAME 'auth_pam';

Check plug-in information:

mysql> SELECT * FROM information_schema.plugins WHERE plugin_name = 'pam'\G
*************************** 1. row ***************************
           PLUGIN_NAME: pam
        PLUGIN_VERSION: 1.0
         PLUGIN_STATUS: ACTIVE
           PLUGIN_TYPE: AUTHENTICATION
   PLUGIN_TYPE_VERSION: 2.0
        PLUGIN_LIBRARY: auth_pam.so
PLUGIN_LIBRARY_VERSION: 1.11
         PLUGIN_AUTHOR: Sergei Golubchik
    PLUGIN_DESCRIPTION: PAM based authentication
        PLUGIN_LICENSE: GPL
           LOAD_OPTION: ON
       PLUGIN_MATURITY: Stable
   PLUGIN_AUTH_VERSION: 1.0

Configuring PAM on Ubuntu/Debian:

#%PAM-1.0
#
# /etc/pam.d/mysql
#
@include common-auth
@include common-account
@include common-session-noninteractive

Create the database user matching to the O/S user:

mysql> CREATE USER 'oli'@'localhost'
IDENTIFIED VIA pam USING 'mariadb'
;
mysql> GRANT ALL PRIVILEGES ON test.* TO 'oli'@'localhost';

Verifying user in the database:

mysql> SELECT user, host, authentication_string FROM mysql.user WHERE user = 'oli';
+------+-----------+-----------------------+
| user | host      | authentication_string |
+------+-----------+-----------------------+
| oli  | localhost | mariadb               |
+------+-----------+-----------------------+

Connection tests:

# mysql --user=oli --host=localhost --password=wrong
ERROR 2059 (HY000): Authentication plugin 'dialog' cannot be loaded: /usr/local/mysql/lib/plugin/dialog.so: cannot open shared object file: No such file or directory

# tail /var/log/auth.log
Feb 13 17:11:16 chef mysqld: pam_unix(mariadb:auth): unexpected response from failed conversation function
Feb 13 17:11:16 chef mysqld: pam_unix(mariadb:auth): conversation failed
Feb 13 17:11:16 chef mysqld: pam_unix(mariadb:auth): auth could not identify password for [oli]
Feb 13 17:11:16 chef mysqld: pam_winbind(mariadb:auth): getting password (0x00000388)
Feb 13 17:11:16 chef mysqld: pam_winbind(mariadb:auth): Could not retrieve user's password

# mysql --user=oli --host=localhost --password=wrong --plugin-dir=$PWD/lib/plugin
ERROR 1045 (28000): Access denied for user 'oli'@'localhost' (using password: NO)
Feb 13 17:11:30 chef mysqld: pam_unix(mariadb:auth): authentication failure; logname= uid=1001 euid=1001 tty= ruser= rhost=  user=oli
Feb 13 17:11:30 chef mysqld: pam_winbind(mariadb:auth): getting password (0x00000388)
Feb 13 17:11:30 chef mysqld: pam_winbind(mariadb:auth): pam_get_item returned a password
Feb 13 17:11:30 chef mysqld: pam_winbind(mariadb:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_USER_UNKNOWN (10), NTSTATUS: NT_STATUS_NO_SUCH_USER, Error message was: No such user

Add mysql user to the shadow group:

# ll /sbin/unix_chkpwd
-rwxr-sr-x 1 root shadow 35536 Mar 16  2016 /sbin/unix_chkpwd

# usermod -a -G shadow mysql

Connection tests:

# mysql --user=oli --host=localhost --password=right --plugin-dir=$PWD/lib/plugin

mysql> SELECT USER(), CURRENT_USER(), @@proxy_user;
+---------------+----------------+--------------+
| USER()        | CURRENT_USER() | @@proxy_user |
+---------------+----------------+--------------+
| oli@localhost | oli@localhost  | NULL         |
+---------------+----------------+--------------+

Taxonomy upgrade extras:

↧

MySQL Enterprise Backup Incremental Cumulative and Differential Backup

May 11, 2017, 8:20 am

≫ Next: Storing BLOBs in the database

≪ Previous: MySQL and MariaDB authentication against pam_unix

Preparing the MySQL Enterprise Administrator Training I found that the MySQL Enterprise Backup Incremental Backup is not described very well. Thus I tried it out and wrote down this how-to:

Incremental Differential Backup

Full Backup

mysqlbackup --user=root --backup-dir=/tape/full backup-and-apply-log
grep end_lsn /tape/full/meta/backup_variables.txt
end_lsn=2583666

Incremental Backups

mysqlbackup --user=root --incremental-backup-dir=/tape/inc1 --start-lsn=2583666 --incremental backup
grep end_lsn /tape/inc1/meta/backup_variables.txt
end_lsn=2586138

mysqlbackup --user=root --incremental-backup-dir=/tape/inc2 --start-lsn=2586138 --incremental backup
grep end_lsn /tape/inc2/meta/backup_variables.txt
end_lsn=2589328

mysqlbackup --user=root --incremental-backup-dir=/tape/inc3 --start-lsn=2589328 --incremental backup
grep end_lsn /tape/inc3/meta/backup_variables.txt
end_lsn=2592519

Binary Log Backups

cp /var/lib/binlog/binlog.* /tape/binlog/

Restore

This step will modify the original full backup!

mysqlbackup --incremental-backup-dir=/tape/inc1 --backup-dir=/tape/full apply-incremental-backup

mysqlbackup --incremental-backup-dir=/tape/inc2 --backup-dir=/tape/full apply-incremental-backup

mysqlbackup --incremental-backup-dir=/tape/inc3 --backup-dir=/tape/full apply-incremental-backup

mysqlbackup --user=root --datadir=/var/lib/mysql --backup-dir=/tape/full copy-back

Point-in-Time-Recovery

grep binlog_position /tape/inc3/meta/backup_variables.txt
/tape/inc3/meta/backup_variables.txt:binlog_position=binlog.000001:7731

cd /tape/binlog
mysqlbinlog --disable-log-bin --start-position=7731 binlog.000001 | mysql -uroot

Incremental Cumulative Backup

Full Backup

mysqlbackup --user=root --backup-dir=/tape/full backup-and-apply-log
grep end_lsn /tape/full/meta/backup_variables.txt
end_lsn=2602954

Incremental Backups

mysqlbackup --user=root --incremental-backup-dir=/tape/inc1 --start-lsn=2602954 --incremental backup

mysqlbackup --user=root --incremental-backup-dir=/tape/inc2 --start-lsn=2602954 --incremental backup

mysqlbackup --user=root --incremental-backup-dir=/tape/inc3 --start-lsn=2602954 --incremental backup

Binary Log Backups

cp /home/mysql/database/mysql-5.7/binlog/binlog.* /tape/binlog/

Restore

This step will modify the original full backup!

mysqlbackup --incremental-backup-dir=/tape/inc3 --backup-dir=/tape/full apply-incremental-backup

mysqlbackup --user=root --datadir=/var/lib/mysql --backup-dir=/tape/full copy-back

Point-in-Time-Recovery

grep binlog_position /tape/*/meta/backup_variables.txt
/tape/inc3/meta/backup_variables.txt:binlog_position=binlog.000001:7731

cd /tape/binlog
mysqlbinlog --disable-log-bin --start-position=7731 binlog.000001 | mysql -uroot

I very much dislike that during my restore the backup is modified. So if I do a mistake during restore my backup is gone and I am doomed.

Taxonomy upgrade extras:

Backup

Restore

MySQL Enterprise Backup

↧

Storing BLOBs in the database

June 30, 2017, 5:18 am

≫ Next: Find evil developer habits with log_queries_not_using_indexes

≪ Previous: MySQL Enterprise Backup Incremental Cumulative and Differential Backup

We have sometimes discussions with our customers whether to store LOBs (Large Objects) in the database or not. To not rephrase the arguments again and again I have summarized them in the following lines.

The following items are more or less valid for all large data types (BLOB, TEXT and theoretically also for JSON and GIS columns) stored in a MySQL or MariaDB (or any other relational) database.

The idea of a relational table based data-store is to store structured data (numbers, data and short character strings) to have a quick write and read access to them.

And yes, you can also store other things like videos, huge texts (PDF, emails) or similar in a RDBMS but they are principally not designed for such a job and thus non optimal for the task. Software vendors implement such features not mainly because it makes sense but because users want it and the vendors want to attract users (or their managers) with such features (USP, Unique Selling Proposition). Here also one of my Mantras: Use the right tool for the right task:

The main topics to discuss related to LOBs are: Operations, performance, economical reasons and technical limitations.

Disadvantages of storing LOBs in the database

The database will grow fast. Operations will become more costly and complicated.
Backup and restore will become more costly and complicated for the admin because of the increased size caused by LOBs.
Backup and restore will take longer because of the same reason.
Database and table management functions (OPTIMIZE, ALTER, etc.) will take longer on big LOB tables.
Smaller databases need less RAM/disk space and are thus cheaper.
Smaller databases fit better into your RAM and are thus potentially faster (RAM vs disk access).
RDBMS are a relatively slow technology (compared to others). Reading LOBs from the database is significantly slower than reading LOBs from a filer for example.
LOBs stored in the database will spoil your database cache (InnoDB Buffer Pool) and thus possibly slow down other queries (does not necessarily happen with more sophisticated RBDMS).
LOB size limitation of 1 Gbyte in reality (max_allowed_packet, theoretically limit is at 4 Gbyte) for MySQL/MariaDB.
Expensive, fast database store (RAID-10, SSD) is wasted for something which can be stored better on a cheap slow file store (RAID-5, HDD).
It is programmatically often more complicated to get LOBs from a database than from a filer (depends on your libraries).

Advantages of storing LOBs in the database

Atomicity between data and LOB is guaranteed by transactions (is it really in MySQL/MariaDB?).
There are no dangling links (reference from data to LOB) between data and LOB.
Data and LOB are from the same point in time and can be included in the same backup.
Data and LOB can be transferred simultaneously to other machines, by database replication or dump/restore.
Applications can use the same mechanism to get the data and the LOB. Remote access needs no separate file transfer for the LOB.

Conclusion

So basically you have to balance the advantages vs. the disadvantages of storing LOBs in the database and decided what arguments are more important in your case.

If you have some more good arguments pro or contra storing LOBs in the database please let me know.

Literature

Check also various articles on Google.

Nim: Repeat after me: MySQL is not a filesystem

Taxonomy upgrade extras:

↧

Find evil developer habits with log_queries_not_using_indexes

September 20, 2017, 7:00 am

≫ Next: Galera Load Balancer the underestimated wallflower

≪ Previous: Storing BLOBs in the database

Recently I switched on the MariaDB slow query logging flag log_queries_not_using_indexes just for curiosity on one of our customers systems:

mariadb> SHOW GLOBAL VARIABLES LIKE 'log_quer%';
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| log_queries_not_using_indexes | OFF   |
+-------------------------------+-------+

mariadb> SET GLOBAL log_queries_not_using_indexes = ON;

A tail -f on the MariaDB Slow Query Log caused a huge flickering on my screen.
I got to see about 5 times per second the following statement sequence in the Slow Query Log:

# User@Host: app_admin[app_admin] @  [192.168.1.42]  Id: 580195
# Query_time: 0.091731  Lock_time: 0.000028 Rows_sent: 273185 Rows_examined: 273185
SELECT LAST_INSERT_ID() FROM `placeholder`;
# Query_time: 0.002858  Lock_time: 0.000043 Rows_sent: 6856 Rows_examined: 6856
SELECT LAST_INSERT_ID() FROM `data`;

So at least 5 times 95 ms (5 x (92 + 3) = 475 ms) per 1000 ms (48%) where spent in these 2 statements which are running quite fast but do not use an index (long_query_time was set to 2 seconds).

So I estimate, that this load job can be speed up at least by factor 2 when using the LAST_INSERT_ID() function correctly not considering the possible reduction of network traffic (throughput and response time).

To show the problem I made a little test case:

mariadb> INSERT INTO test VALUES (NULL, 'Some data', NULL);

mariadb> SELECT LAST_INSERT_ID() from test;

+------------------+
| LAST_INSERT_ID() |
+------------------+
|          1376221 |
...
|          1376221 |
+------------------+
1048577 rows in set (0.27 sec)

The response time of this query will linearly grow with the amount of data as long as they fit into memory and the response time will explode as soon as the table does not fit into memory any more. In addition the network traffic would be reduced by about 8 Mbyte (1 Mio rows x BIGINT UNSIGNED (64-bit) + some header per row?) per second (6-8% of the network bandwidth of a 1 Gbit network link).

shell> ifconfig lo | grep bytes
          RX bytes:2001930826 (2.0 GB)  TX bytes:2001930826 (2.0 GB)
shell> ifconfig lo | grep bytes
          RX bytes:2027289745 (2.0 GB)  TX bytes:2027289745 (2.0 GB)

The correct way of doing the query would be:

mariadb> SELECT LAST_INSERT_ID();
+------------------+
| last_insert_id() |
+------------------+
|          1376221 |
+------------------+
1 row in set (0.00 sec)

The response time is below 10 ms.

So why is the first query taking so long an consuming so many resources? To get an answer to this question the MariaDB Optimizer can tell us more with the Query Execution Plan (QEP):

mariadb> EXPLAIN SELECT LAST_INSERT_ID() FROM test;
+------+-------------+-------+-------+---------------+---------+---------+------+---------+-------------+
| id   | select_type | table | type  | possible_keys | key     | key_len | ref  | rows    | Extra       |
+------+-------------+-------+-------+---------------+---------+---------+------+---------+-------------+
|    1 | SIMPLE      | test  | index | NULL          | PRIMARY | 4       | NULL | 1048577 | Using index |
+------+-------------+-------+-------+---------------+---------+---------+------+---------+-------------+

mariadb> EXPLAIN FORMAT=JSON SELECT LAST_INSERT_ID() FROM test;
{
  "query_block": {
    "select_id": 1,
    "table": {
      "table_name": "test",
      "access_type": "index",
      "key": "PRIMARY",
      "key_length": "4",
      "used_key_parts": ["id"],
      "rows": 1048577,
      "filtered": 100,
      "using_index": true
    }
  }
}

The database does a Full Index Scan (FIS, other call it a Index Fast Full Scan (IFFS)) on the Primary Key (column id).

The Query Execution Plan of the second query looks as follows:

mariadb> EXPLAIN SELECT LAST_INSERT_ID();
+------+-------------+-------+------+---------------+------+---------+------+------+----------------+
| id   | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra          |
+------+-------------+-------+------+---------------+------+---------+------+------+----------------+
|    1 | SIMPLE      | NULL  | NULL | NULL          | NULL | NULL    | NULL | NULL | No tables used |
+------+-------------+-------+------+---------------+------+---------+------+------+----------------+

mariadb> EXPLAIN FORMAT=JSON SELECT LAST_INSERT_ID();
{
  "query_block": {
    "select_id": 1,
    "table": {
      "message": "No tables used"
    }
  }
}

Taxonomy upgrade extras:

↧

Galera Load Balancer the underestimated wallflower

September 21, 2017, 6:25 am

≫ Next: MariaDB master/master GTID based replication with keepalived VIP

≪ Previous: Find evil developer habits with log_queries_not_using_indexes

There are some pretty sophisticated Load Balancers for Galera Clusters setups out in the market (ProxySQL, MaxScale, HAproxy, ...). They have many different exotic features. You can nearly do everything with them. But this comes at the cost of complexity. Non of them is simple any more.

A widely underestimated Load Balancer solution for Galera Cluster setups is the Galera Load Balancer from Codership. It is an simple Load Balancer solution which serves all of our daily needs when it comes to Galera Cluster. Unfortunately this product is not much promoted by the software vendor himself.

Installation of Galera Load Balancer

This starts with the installation. There are no packages ready to install. You have to compile Galera Load Balancer yourself. FromDual provides some compiled packages or can help you building and installing it.

You can get the Galera Load Balancer sources from Github. The binaries are built straight forward:

shell> git clone https://github.com/codership/glb
shell> cd glb/
shell> ./bootstrap.sh
shell> ./configure
shell> make
shell> make install

If you prefer a binary tar ball as I do, you can run the following commands instead of make install:

shell> TARGET=glb-1.0.1-linux-$(uname -m)
shell> mkdir -p ${TARGET}/sbin ${TARGET}/lib ${TARGET}/share/glb
shell> cp src/glbd ${TARGET}/sbin/
shell> cp src/.libs/libglb.a src/.libs/libglb.so* ${TARGET}/lib/
shell> cp files/* ${TARGET}/share/glb/
shell> cp README NEWS COPYING CONTRIBUTORS.txt CONTRIBUTOR_AGREEMENT.txt ChangeLog BUGS AUTHORS
shell> tar czf ${TARGET}.tar.gz ${TARGET}
shell> rm -rf ${TARGET}

Configuration of Galera Load Balancer

The Galera Load Balancer is configured in a file called glbd which must be located under /etc/sysconfig/gldb (Red Hat and its derivatives) or /etc/default/glbd (Debian and its derivatives). I did not find any option to tell Galera Load Balancer where to search for a configuration file.

The Galera Load Balancer parameters are documented here.

Starting and Stopping Galera Load Balancer

This means for me I have to specify all my parameters on the command line:

product/glb/sbin/glbd --threads 8 --max_conn 500 \
  --round --fifo /home/mysql/run/glbd.fifo --control 127.0.0.1:3333 \
  127.0.0.1:3306 \
  192.168.1.1:3306:1 192.168.1.2:3306:2 192.168.1.3:3306:1

An equivalent configuration file would look as follows:

#
# /etc/sysconfig/glbd.cfg
#
LISTEN_ADDR="127.0.0.1:3306"
CONTROL_ADDR="127.0.0.1:3333"
CONTROL_FIFO="/home/mysql/run/glbd.fifo"
THREADS="8"
MAX_CONN="500"
DEFAULT_TARGETS="192.168.1.1:3306:1 192.168.1.2:3306:2 192.168.1.3:3306:1"
OTHER_OPTIONS="--round"

Stopping Galera Load Balancer is simple:

killall glbd

Galera Load Balancer operations

Beside starting and stopping Galera Load Balancer you also want to look into it. This can be done with the following 2 commands:

echo getinfo | nc -q 1 127.0.0.1 3333
echo getstats | nc -q 1 127.0.0.1 3333

Or if you want to have it in a more top/vmstat like style:

watch -n 1 "echo getstats | nc -q 1 127.0.0.1 3333"

watch -n 1 -d "echo getinfo | nc -q 1 127.0.0.1 3333"

More interesting are operations like draining and undraining a Galera Cluster node from the Galera Load Balancer. To drain a Galera Cluster node for example for maintenance (kernel upgrade?) you can run the following command:

echo "192.168.1.2:3306:0" | nc 127.0.0.1 3333

To undrain the node again it works like this:

echo "192.168.1.2:3306:2" | nc 127.0.0.1 3333

Unfortunately Galera Load Balancer does not memorize the weight (:2).

If you want to remove or add a node from/to the Galera Load Balancer this works as follows:

echo "192.168.1.2:3306:-1" | nc 127.0.0.1 3333

echo "192.168.1.2:3306:1" | nc 127.0.0.1 3333

Further Galera Load Balancer operation tasks you can find in the documentation.

Taxonomy upgrade extras:

↧

MariaDB master/master GTID based replication with keepalived VIP

November 11, 2017, 2:29 am

≫ Next: First Docker steps with MySQL and MariaDB

≪ Previous: Galera Load Balancer the underestimated wallflower

Some of our customers still want to have old-style MariaDB master/master replication clusters. Time goes by, new technologies appear but some old stuff still remains.

The main problem in a master/master replication set-up is to make the service highly available for the application (applications typically cannot deal with more than one point-of-contact). This can be achieved with a load balancer (HAproxy, Galera Load Balancer (GLB), ProxySQL or MaxScale) in front of the MariaDB master/master replication cluster. But the load balancer by it-self should also become highly available. And this is typically achieved by a virtual IP (VIP) in front of one of the load balancers. To make operations of the VIP more handy the VIP is controlled by a service like keepalived or corosync.

M/M with LB and keepalived

Because I like simple solutions (I am a strong believer in the KISS principle) I thought about avoiding the load balancer in the middle and attach the VIP directly to the master/master replication servers and let them to be controlled by keepalived as well.

M/M with keepalived

Important: A master/master replication set-up is vulnerable to split-brain situations. Neither keepalived nor the master/master replication helps you to avoid conflicts and in any way to prevent this situation. If you are sensitive to split-brain situations you should look for Galera Cluster. Keepalived is made for stateless services like load balancers, etc. but not databases.

Set-up a MariaDB master/master replication cluster

Because most of the Linux distributions have a bit old versions of software delivered we use the MariaDB 10.2 repository from the MariaDB website:

#
# /etc/yum.repos.d/MariaDB-10.2.repo 
#
# MariaDB 10.2 CentOS repository list - created 2017-11-08 20:32 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

Then we install the MariaDB server and start it:

shell> yum makecache
shell> yum install MariaDB-server MariaDB-client
shell> systemctl start mariadb
shell> systemctl enabled mariadb

For the MariaDB master/master replication set-up configuration we use the following parameters:

#
# /etc/my.cnf
#

[mysqld]

server_id                = 1           # 2 on the other node
log_bin                  = binlog-m1   # binlog-m2 on the other node
log_slave_updates        = 1

gtid_domain_id           = 1           # 2 on the other node
gtid_strict_mode         = On

auto_increment_increment = 2
auto_increment_offset    = 1           # 2 on the other node

read_only                = On          # super_read_only for MySQL 5.7 and newer

Then we close the master/master replication ring according to: Starting with empty server.

mariadb> SET GLOBAL gtid_slave_pos = "";
mariadb> CHANGE MASTER TO master_host="192.168.56.101", master_user="replication"
                        , master_use_gtid=current_pos;
mariadb> START SLAVE;

Installing keepalived

Literature:

The next step is to install and configure keepalived. This can be done as follows:

shell> yum install keepalived
shell> systemctl enable keepalived

Important: In my tests I got crashes and core dumps with keepalived which disappeared after a full upgrade of CentOS 7.

Configuring keepalived

The most important part is the keepalived configuration file:

#
# /etc/keepalived/keepalived.conf
#

global_defs {

  notification_email {

    root@localhost
    dba@example.com
  }

  notification_email_from root@master1   # master2 on the other node
  smtp_server localhost 25

  router_id MARIADB_MM
  enable_script_security
}


# Health checks

vrrp_script chk_mysql {

  script "/usr/sbin/pidof mysqld"
  weight 2     # Is relevant for the diff in priority
  interval 1   # every ... seconds
  timeout 3    # script considered failed after ... seconds
  fall 3       # number of failures for K.O.
  rise 1       # number of success for OK
}

vrrp_script chk_failover {

  script "/etc/keepalived/chk_failover.sh"
  weight -4    # Is relevant for the diff in priority
  interval 1   # every ... seconds
  timeout 1    # script considered failed after ... seconds
  fall 1       # number of failures for K.O.
  rise 1       # number of success for OK
}


# Main configuration

vrrp_instance VI_MM_VIP {

  state MASTER           # BACKUP on the other side

  interface enp0s9       # private heartbeat interface

  priority 100           # Higher means: elected first (BACKUP: 99)
  virtual_router_id 42   # ID for all nodes of Cluster group

  debug 0                # 0 .. 4, seems not to work?

  unicast_src_ip 192.168.56.101   # Our private IP address
  unicast_peer {
    192.168.56.102       # Peers private IP address
  }


  # For keepalived communication

  authentication {
    auth_type PASS
    auth_pass Secr3t!
  }


  # VIP to move around

  virtual_ipaddress {

    192.168.1.99/24 dev enp0s8   # public interface for VIP
  }


  # Check health of local system. See vrrp_script above.

  track_script {
    chk_mysql
    # If File /etc/keepalived/failover is touched failover is triggered
    # Similar can be reached when priority is lowered followed by a reload
    chk_failover
  }

  # When node becomes MASTER this script is triggered
  notify_master "/etc/keepalived/keepalived_master.sh --user=root --password= --wait=yes --variable=read_only"
  # When node becomes SLAVE this script is triggered
  notify_backup "/etc/keepalived/keepalived_backup.sh --user=root --password= --kill=yes --variable=read_only"
  # Possibly fault and stop should also call keepalived_backup.sh to be on the safe side...
  notify_fault "/etc/keepalived/keepalived_fault.sh arg1 arg2"
  notify_stop "/etc/keepalived/keepalived_stop.sh arg1 arg2"
  # ANY state transit is triggered
  notify /etc/keepalived/keepalived_notify.sh

  smtp_alert   # send notification during state transit
}

With the command:

shell> systemctl restart keepalived

the service is started and/or the configuration is reloaded.

The scripts we used in the configuration file are the following:

chk_failover.sh
keepalived_backup.sh
keepalived_fault.sh
keepalived_master.sh
keepalived_notify.sh
keepalived_stop.sh

#!/bin/bash
#
# /etc/keepalived/keepalived_notify.sh
#

TYPE=${1}
NAME=${2}
STATE=${3}
PRIORITY=${4}

TS=$(date '+%Y-%m-%d_%H:%M:%S')
LOG=/etc/keepalived/keepalived_notify.log

echo $TS $0 $@ >>${LOG}

#!/bin/bash
#
# /etc/keepalived/chk_failover.sh
#

/usr/bin/stat /etc/keepalived/failover 2>/dev/null 1>&2
if [ ${?} -eq 0 ] ; then
  exit 1
else
  exit 0
fi

To make MariaDB master/master replication more robust against replication problems we took the following (configurable) actions on the database side:

Getting the MASTER role:

Waiting for catch-up replication
Make the MariaDB instance read/write

Getting the BACKUP role:

Make the MariaDB instance read-only
Kill all open connections

Testing scenarios

The following scenarios where tested under load (insert_test.sh):

Intentional fail-over for maintenance:

shell> touch /etc/keepalived/failover
shell> rm -f /etc/keepalived/failover

Stopping keepalived:

shell> systemctl stop keepalived
shell> systemctl start keepalived

Stopping MariaDB node:

shell> systemctl stop mariadb
shell> systemctl start mariadb

Reboot server:
```
shell> reboot
```

Simulation of split-brain:

shell> ip link set enp0s9 down
shell> ip link set enp0s9 up

Problems

Problems we faced during set-up and testing were:

SElinux/AppArmor
Firewall

Keepalived controlling 2 virtual IPs

A second scenario we wanted to build is a MariaDB master/master GTID based replication cluster with 2 VIP addresses. This is to achieve either a read-only VIP and a read/write VIP or to have half of the load on one master and half of the load on the other master:

M/M with keepalived and 2 VIPs

For this scenario we used the same scripts but a slightly different keepalived configuration:

#
# /etc/keepalived/keepalived.conf
#

global_defs {

  notification_email {

    root@localhost
    dba@example.com
  }

  notification_email_from root@master1   # master2 on the other node
  smtp_server localhost 25

  router_id MARIADB_MM
  enable_script_security
}


# Health checks

vrrp_script chk_mysql {

  script "/usr/sbin/pidof mysqld"
  weight 2     # Is relevant for the diff in priority
  interval 1   # every ... seconds
  timeout 3    # script considered failed after ... seconds
  fall 3       # number of failures for K.O.
  rise 1       # number of success for OK
}

vrrp_script chk_failover {

  script "/etc/keepalived/chk_failover.sh"
  weight -4    # Is relevant for the diff in priority
  interval 1   # every ... seconds
  timeout 1    # script considered failed after ... seconds
  fall 1       # number of failures for K.O.
  rise 1       # number of success for OK
}


# Main configuration

vrrp_instance VI_MM_VIP1 {

  state MASTER           # BACKUP on the other side

  interface enp0s9       # private heartbeat interface

  priority 100           # Higher means: elected first (BACKUP: 99)
  virtual_router_id 42   # ID for all nodes of Cluster group

  unicast_src_ip 192.168.56.101   # Our private IP address
  unicast_peer {
    192.168.56.102       # Peers private IP address
  }


  # For keepalived communication

  authentication {
    auth_type PASS
    auth_pass Secr3t!
  }


  # VIP to move around

  virtual_ipaddress {

    192.168.1.99/24 dev enp0s8   # public interface for VIP
  }


  # Check health of local system. See vrrp_script above.

  track_script {
    chk_mysql
    chk_failover
  }

  # ANY state transit is triggered
  notify /etc/keepalived/keepalived_notify.sh

  smtp_alert   # send notification during state transit
}

vrrp_instance VI_MM_VIP2 {

  state BACKUP           # MASTER on the other side

  interface enp0s9       # private heartbeat interface

  priority 99            # Higher means: elected first (MASTER: 100)
  virtual_router_id 43   # ID for all nodes of Cluster group

  unicast_src_ip 192.168.56.101   # Our private IP address
  unicast_peer {
    192.168.56.102       # Peers private IP address
  }


  # For keepalived communication

  authentication {
    auth_type PASS
    auth_pass Secr3t!
  }


  # VIP to move around

  virtual_ipaddress {

    192.168.1.98/24 dev enp0s8   # public interface for VIP
  }


  # Check health of local system. See vrrp_script above.

  track_script {
    chk_mysql
    chk_failover
  }

  # ANY state transit is triggered
  notify /etc/keepalived/keepalived_notify.sh

  smtp_alert   # send notification during state transit
}

Taxonomy upgrade extras:

↧

Results

Conclusion

Upgrade from 1.1.x or higher to 1.3.1

Changes in MyEnv 1.3.1

MyEnv

MyEnv Installer

MyEnv Utilities

Changes in fpmmm v0.10.6

fpmmm agent

Process module

Galera module

InnoDB module

Conclusion

Addendum

Prepare the RPM repository server

Prepare the RPM client

Further sources of information:

The MySQL Server itself

The license of the MySQL Server

Enterprise plug-ins of the MySQL Enterprise Server

MySQL Enterprise Server Certification and Indemnification support

Different libraries

Other technical comparisons

The most imporant MySQL binaries

MySQL Enterprise Server and MySQL Community Server packages

Preparation work for the operating system administrator

Installation of MySQL Enterprise Server binaries as non privileged user

Creating, Starting and Stopping several MySQL Enterprise Server Instances

How to go even further

Scenario A: Filtering on mysql schema

Scenario B: Filtering on tmp or similar schema

Conclusion

DDL statements cause TOI operations

How to check?

Find out in advance

MySQL authentication against pam_unix

MariaDB authentication against pam_unix

Incremental Differential Backup

Full Backup

Incremental Backups

Binary Log Backups

Restore

Point-in-Time-Recovery

Incremental Cumulative Backup

Full Backup

Incremental Backups

Binary Log Backups

Restore

Point-in-Time-Recovery

Disadvantages of storing LOBs in the database

Advantages of storing LOBs in the database

Conclusion

Literature

Installation of Galera Load Balancer

Configuration of Galera Load Balancer

Starting and Stopping Galera Load Balancer

Stopping Galera Load Balancer is simple:

Galera Load Balancer operations

Set-up a MariaDB master/master replication cluster

Installing keepalived

Configuring keepalived

Testing scenarios

Problems

Keepalived controlling 2 virtual IPs

Scenario A: Filtering on `mysql` schema

Scenario B: Filtering on `tmp` or similar schema

MySQL authentication against `pam_unix`

MariaDB authentication against `pam_unix`