You are here

News

MariaDB master/master GTID based replication with keepalived VIP

Shinguz - Sat, 2017-11-11 11:29

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.

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.

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:

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: mariadbmaster-masterkeepalivedVIPreplicationGTID

Galera Load Balancer the underestimated wallflower

Shinguz - Thu, 2017-09-21 15:25

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: Galera Clusterglbload balancerOperations

Find evil developer habits with log_queries_not_using_indexes

Shinguz - Wed, 2017-09-20 16:00

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: query tuningOptimizerindexindex scanlast_insert_idexplainslowlog

Storing BLOBs in the database

Shinguz - Fri, 2017-06-30 14:18

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.

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.

Taxonomy upgrade extras: blobtextlobdesign

MySQL Enterprise Backup Incremental Cumulative and Differential Backup

Shinguz - Thu, 2017-05-11 17:20

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: BackupRestoreMySQL Enterprise Backupenterpriseincrementalcumulativedifferential

FromDual Backup and Recovery Manager for MySQL 1.2.5 has been released

FromDual.en - Wed, 2017-05-10 15:26

FromDual has the pleasure to announce the release of the new version 1.2.5 of the popular Backup and Recovery Manager for MySQL and MariaDB (fromdual_brman).

You can download the FromDual Backup and Recovery Manager from here.

In the inconceivable case that you find a bug in the FromDual Backup and Recovery Manager please report it to our Bugtracker or just send us an email.

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

Upgrade from 1.2.x to 1.2.5 # cd ${HOME}/product # tar xf /download/fromdual_brman-1.2.5.tar.gz # rm -f fromdual_brman # ln -s fromdual_brman-1.2.5 fromdual_brman
Changes in FromDual Backup Manager 1.2.5

This release contains mainly fixes related to the backup catalog and the backup type cleanup.

You can verify your current FromDual Backup Manager version with the following command:

shell> fromdual_bman --version
FromDual Backup Manager
  • Docker container is ready.
  • Testing infrastructure improved.
  • Better option checking to be usage compliant.
  • Option handling and checking refactored.
  • PHP variable variables_order is included into program. No more php.ini change required any more.
  • Connection error made more verbose.
  • Downstream myEnv.inc library from rev873.
  • Incompatibility change: Default --backupdir location changed from ./bck to $HOME/bck.
FromDual Backup Manager Catalog
  • Catalog creation and upgrade messages put into right order.
  • Backup catalog should be upgraded directly to newest release when created.
  • Only do catalog version check if --upgrade is not specified.
  • Incompatibility change: Catalog operation options (--create and --upgrade) made more consistent (--type=catalog). This could lead to different behaviour than earlier!
  • Backup cleanup in catalog made nicer.
  • Catalog version changed from 010 to 020.
FromDual Backup Manager Cleanup
  • Archive cleanup output empty line removed.
  • Backup cleanup in catalog made nicer.
  • Cleanup should delete only instance backups but not all backups if specified (bug #166).
FromDual Backup Manager Logical Full and Schema backup
  • Omit warning for non-transactional tables if option --blocking-backup is set.
  • Function getDumpOverview now also includes empty schemata.
  • Transactional storage engine selection made ready for MariaDB 10.1/10.2 and MySQL 8.0.
Taxonomy upgrade extras: BackupRestoreRecoverypitrfromdual_brman

How the Lack of a Primary Key May Effectively Stop the Slave

Jörg Brühe - Tue, 2017-05-02 09:50

Most (relational) DBAs and DB application developers know the concept of a primary key ("PK") and what it is good for. However, much too often one still encounters table definitions without a PK. True, the relational theory based on sets does not need a PK, and all operations (insert, select, update, delete) can also be done on tables for which no PK was defined. If performance doesn't matter (or the data volume is small, a typical situation in tests), the lack of a PK does not immediately cause negative consequences.

But recently, we had several customers who (independent of each other) had big tables without a PK in a replication setup which they wanted to delete, and they all suffered severely from that: Their replication did not progress, the slave lag grew larger and larger, and all this without reporting any error. When I say "larger and larger", I mean it: I'm not talking about minutes or even hours, I'm talking about days!

Observations

In all cases, the situation could be summarized as:

  • They were running a traditional, asynchronous replication using the "row" format.
  • They had a table without PK with many entries, say a million rows.
  • This table wasn't needed any more, and someone issued a "delete from T" statement on the master.
  • From this moment, the slave did not show any sign of progress: The output of "show slave status \G"
    - listed both the IO and the SQL slave thread as running,
    - reported the same log positions without any change,
    - did not mention any slave error,
    - but the slave lag grew in sync with the passing time.

Looking at the slave's machine load, say using "vmstat", you could see a certain amount of CPU load in user mode, possibly some "waiting for IO", and some read IO (group "io", column "bi" = "block input"). Checking with "top", you could see that the MySQL server process was the only significant CPU load, and closer inspection would reveal that it used roughly one CPU core.

(A side remark: The numbers of "vmstat" and "top" are not directly comparable: While "vmstat" reports the overall CPU usage as a percentage of the total available CPU power, "top" reports the CPU usage of the individual processes as the percentage of a single CPU core. So if you had a 4-core machine with only one active process running an infinite loop, "top" would show this process as using 100%, while "vmstat" would report the CPU as running 25% in user mode and being 75% idle. If you don't know it, look at "/proc/cpuinfo" to find the number of CPU cores.)

What was the Issue? From "top", we could tell that the MySQL server was using one CPU core at full speed. From "vmstat", we could tell that it might access some data from disk, but didn't write any significant amount. This sure looked like an infinite loop or a close relative of it, executed by only one thread.

Some of you may have heard that (under some conditions) replication may do a full table scan: This is it!

When the slave has to apply a change (for this discussion: a delete or an update) which is provided in row format, and the table has no PK (or other suitable index), the SQL thread does a full table scan searching for the matching row. Note that it doesn't stop on the first match, but rather continues the scan throughout the rest of the table.

To be honest: I don't understand why it doesn't stop after the first match. I also ran a modified test where some master rows had two matches on the slave (I had duplicated them by "insert select"): The "delete" was still replicated as before, and these additional slave rows were still present after the delete.

Until now, you may consider that "full table scan" as a claim without proof, and I agree with all demands for a more thorough check.

The Experiment For tests, I have a setup of two VMs, each running a MySQL server process, and they are configured for a traditional master-slave replication. In fact, I have it for the versions MySQL 5.5.44, 5.6.24, and 5.7.17. (Yes, I might add newer versions.)

So I designed an experiment:

  • Start both master and slave, make sure replication is running.
  • On the master, create a table without any key / index, neither primary nor secondary: CREATE TABLE for_delete ( inc_num int, # ascending numbers 1 .. 10,000 repeated for larger tables clock timestamp, # now() counted: 129 different values with 200 k rows bubble char(250) # repeat('Abcd', 60) ) DEFAULT CHARACTER SET latin1 ;
  • Insert into that table the desired number of rows (I had runs with 10 k, 20 k, 100 k, and 200 k)
  • on both master and slave, run "SELECT ... FROM information_schema.global_status WHERE ..." to get status counters,
  • Delete all rows of that table
  • sleep for a time depending on the row count (you will later see why)
  • get new status counters
  • compute the status counter differences

This experiment reliably reproduced the symptoms which the customers had reported: When the "delete" had been done on the master, the slave became busy for a long time, depending on the row count, and in this time it did not show any progress indicators. This holds for all three versions I checked.

So what did the slave do? It worked as assumed: For each row, it did a full table scan, continuing even after it had found a matching row. This can be easily seen in the status counters, which you will find in the result tables below.

In this article, I will show the results of tests with 200 k rows only, as they are the most impressive. As described above, the table was created anew for each run. Then, 10,000 rows were inserted, and this was repeated 20 times. Each such group had the value of "inc_num" go up from 1 to 10,000.

In all runs, the status counters "HANDLER_DELETE", "INNODB_ROWS_DELETED", and "INNODB_ROWS_READ" showed the value of 200,000, the table size. So the handler calls did not show any scan, it must be below that interface (= within the handler).

If the server does a table scan, it must access all data pages of the table, so there must be read requests for them to guarantee they are in the buffer pool. And yes, the status counters showed these read requests: Table 1: No Key or Index

200,000 rows, status counters on Master Slave


Version 5.5.44

INNODB_BUFFER_POOL_READ_REQUESTS 2,174,121 380,132,972 Ratio "read_requests" Slave/Master
174.8 "read_requests" per "rows_deleted" 10.9 1,900.7


Version 5.6.24

INNODB_BUFFER_POOL_READ_REQUESTS 2,318,685 379,762,583 Ratio "read_requests" Slave/Master
163.8 "read_requests" per "rows_deleted" 11.6 1,898.8


Version 5.7.17

INNODB_BUFFER_POOL_READ_REQUESTS 1,598,745 379,538,695 Ratio "read_requests" Slave/Master
237.4 "read_requests" per "rows_deleted" 8.0 1,897.7

While master and slave (from a logical point of view) do the same work (delete all rows from a 200 k rows table), the slave accesses many more pages than the master - depending on the version, the factor ranges from 164 to 237. (Note that in version 5.7 the slave didn't do worse than in earlier versions, rather the master did better. This shows clearly in the ratio of "innodb buffer pool read requests" to "rows deleted" on the master: This is about 11 in 5.5 and 5.6, but only 8 in 5.7.)

I won't bother you with the detailed results for 100 k rows. It is enough to say that for half as many rows, the master had half as many read requests, while the slave had a quarter. This means that the effort on the master grows proportional to table size, but on the slave it grows with the square of the table size. Accepting the fact that the slave always scans the full table, this is easy to understand: If the table has twice as many rows, there are twice as many pages to scan, and the number of scans also doubles.

Quadratic growth means that an increase of the table size by a factor ten lets the effort grow by a factor hundred! Now imagine I had tested with a million of rows ...

All this isn't new: In the public MySQL bug database, this is listed as bug #53375. The bug was reported on May 3, 2010, for MySQL 5.1. The bug is closed since December 15, 2011. This does not mean the full table scans were stopped - obviously, they are considered unavoidable, so the bug fix is to write an explaining message into the error log. In my tests, I encountered it only once, here it is:

[Note] The slave is applying a ROW event on behalf of a DELETE statement on table for_delete and is currently taking a considerable amount of time (61 seconds). This is due to the fact that it is scanning an index while looking up records to be processed. Consider adding a primary key (or unique key) to the table to improve performance. Avoiding the Issue

Of course, this problem is the consequence of sloppy table design: If there were a primary key, it would not occur. But this may not help those who currently have tables without a PK and dare not add one, because it would require prior testing and a maintenance window to alter the table on the master.

Luckily, there are remedies, and even more than the log message (quoted above) mentions: In my tests, I found that the slave will use any index on that table if one is available. (It even uses an index with low selectivity, which may increase the page request count.) I did 5 tests:

  • Create an index on "clock" (129 different values).
  • Create an index on "inc_num" (10,000 different values).
  • Create an index on both "clock" and "inc_num" (all combinations are distinct).
  • As before, and declare it as "unique".
  • Define the combination of "clock" and "inc_num" to be the primary key.

The "alter table" statement for this was always issued on the slave only, after the inserts, but before the delete.

In all three versions, the slave used any index available. The index on "clock" of course had many different rows per value, so it caused many even more page requests than the no-index case: between 2,800 and 3,165 per row deleted. Obviously, thios makes the problem even worse. But all other indexes were huge improvements, the primary key of course was the best choice. Here are the numbers: Table 2: With Added Key or Index

200,000 rows, status counters on Master Slave Slave Slave Slave Slave






"Alter table ..." on slave before "Delete":
Index on "clock" 129 values Index on "inc_num" 10,000 v. Index
on both
Unique I.
on both
Primary key on both Version 5.5.44





INNODB_BUFFER_POOL_READ_REQUESTS 2,174,121 633,132,032 10,197,554 4,429,243 4,421,357 1,810,734 Ratio "read_requests" Slave/Master
291.2 4.7 2.0 2.0 0.8 "read_requests" per "rows_deleted" 10.9 3,165.7 51.0 22.1 22.1 9.1






Version 5.6.24





INNODB_BUFFER_POOL_READ_REQUESTS 2,318,685 610,482,315 10,327,132 4,375,106 4,073,543 1,794,524 Ratio "read_requests" Slave/Master
342.1 5.0 2.1 2.0 0.9 "read_requests" per "rows_deleted" 11.6 3,052.4 51.6 21.9 20.4 9.0






Version 5.7.17





INNODB_BUFFER_POOL_READ_REQUESTS 1,598,745 559,398,633 9,531,444 3,859,343 3,836,390 1,720,731 Ratio "read_requests" Slave/Master
354.8 6.0 2.3 2.5 1.1 "read_requests" per "rows_deleted" 8.0 2,797.0 47.7 19.3 19.2 8.6

But one very important fact should be mentioned in addition to the numbers: The fact that it worked! By adding an index, I made the slave's schema differ from the master's. The primary key even totally changed the B-tree in which the rows are stored, and it made the slave drop the internal row ID which InnoDB had added on the master. Still, replication using the row format could handle these differences without problems.

The Way Out

So the good message is:

  • Even if you have a table without indexes or primary key, you can add these on the slave without breaking the replication.
  • If you suffer from slow replication on such a table, adding a good index or (even better) the PK will solve this problem.
  • In a replication setup, you can improve the schema on the slave and then do a failover, effectively improving it for all accesses without any maintenance window - just the short failover time.

This might help many DBAs who otherwise don't see a chance to improve a bad schema once it is used in production.

Take care!

MySQL and MariaDB authentication against pam_unix

Shinguz - Mon, 2017-02-13 18:02

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

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

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: authenticationpamsecuritypluginplug-in

FromDual Performance Monitor for MySQL and MariaDB 1.0.1 has been released

FromDual.en - Fri, 2017-02-10 15:13

FromDual has the pleasure to announce the release of the new version 1.0.1 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 the 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.

Changes in fpmmm v1.0.1 fpmmm agent
  • Fpmmm suppresses server has gone away message to stdout.
  • Fpmmm should behave correctly now when database was started after fpmmm agent.
  • MyEnv library synced from MyEnv project.
  • Added LaunchDaemon configuration for fpmmmm on Max OSX (darwin).
fpmmm agent installer
  • Added some more support for Mac OSX (darwin).

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

Taxonomy upgrade extras: mysqlperformancemonitormonitoringfpmmmmaasperformance monitormpmrelease

Is your MySQL software Cluster ready?

Shinguz - Fri, 2017-01-27 18:19

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: Galera ClusterTOIDDLcreatetemporary tableDCLdropaltertruncate

MySQL replication with filtering is dangerous

Shinguz - Thu, 2017-01-12 16:47

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: replicationbinary logfilterfilteringrow filteringstatementbinlog_formatrow

FromDual Backup and Recovery Manager for MySQL 1.2.4 has been released

FromDual.en - Thu, 2017-01-12 12:22

FromDual has the pleasure to announce the release of the new version 1.2.4 of the popular Backup and Recovery Manager for MySQL and MariaDB (fromdual_brman).

You can download the FromDual Backup and Recovery Manager from here.

In the inconceivable case that you find a bug in the Backup and Recovery Manager please report it to our Bugtracker or just send us an email.

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

Upgrade from 1.2.x to 1.2.4 # cd ${HOME}/product # tar xf /download/fromdual_brman-1.2.4.tar.gz # rm -f fromdual_brman # ln -s fromdual_brman-1.2.4 fromdual_brman
Changes in FromDual Backup Manager 1.2.4

This release contains mainly fixes related to the backup type cleanup.

You can verify your current FromDual Backup Manager version with the following command:

shell> fromdual_bman --version
FromDual Backup Manager
  • Library myEnv.inc synced from myEnv project.
FromDual Backup Manager Cleanup
  • Ignore warning for non empty backup directories in cleanup.
  • Check if directory exist before going into recursive lookup in cleanup.
  • Function rmdir is also covered by simulate option now in cleanup.
  • Backup type cleanup also considers physical backup and catalog now.
Taxonomy upgrade extras: BackupRestoreRecoverypitrfromdual_brman

Reset MySQL 5.7 password on macOS over the command line

Cédric Bruderer - Mon, 2017-01-09 13:17

This one is for all MySQL-DBA's, which are working on macOS. Since the Apple OS has a rather peculiar way of starting and stopping MySQL, compared to Linux, you can run into some issues. These problems occur especially, if you have no access to the GUI.

Preparation

Put skip-grant-tables into the mysqld section of the my.cnf. A my.cnf can be found in /usr/local/mysql/support-files. You MUST work as root for all the following steps.

shell> sudo -s shell> vi /usr/local/mysql/support-files/my-default.cnf ... [mysqld] skip-grant-tables skip-networking ...

Save the configuration file! (In vi this is "[ESC] + :x")

Continue with stopping MySQL:

launchctl unload /Library/LaunchDaemons/com.oracle.oss.mysql.mysqld.plist

Restart MySQL, so skip-grant-tables becomes active:

launchctl load /Library/LaunchDaemons/com.oracle.oss.mysql.mysqld.plist

Reset the password

After MySQL is started again, you can log into the CLI and reset the password:

shell> mysql -u root mysql> FLUSH PRIVILEGES; mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'super-secret-password';

Plan B

If you are not capable of stopping MySQL in a civilised manner, you can use the more rough way. You can send a SIGTERM to the MySQL-Server:

shell> ps -aef | grep mysql | grep -v grep 74 28017 1 0 Fri10AM ?? 5:59.50 /usr/local/mysql/bin/mysqld --user=_mysql --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --plugin-dir=/usr/local/mysql/lib/plugin --log-error=/usr/local/mysql/data/mysqld.local.err --pid-file=/usr/local/mysql/data/mysqld.local.pid

You should receive one line. The second column from the left is the process id. Use this process id to stop the MySQL-Server.

shell> kill -15 [process id]

In this example, the command would look like this:

shell> kill -15 28017

macOS will restart MySQL, since the process has not stopped correctly. The configuration will be read and the changes to the parameters will become effective. Continue with logging in to the CLI.

Conclusion

No matter how secure your MySQL-Password is, it is a lot more important to secure access to the server it self. If your server is not secured by something that prevents access from the internet, it will only take a few minutes for someone with bad intentions to take over your database or worse, the entire server.

Taxonomy upgrade extras: mysqlserver

Non-standard database set up with SELinux

Cédric Bruderer - Tue, 2016-12-13 15:26
What is SELinux?

The Security-Enhanced Linux is an extension to the Linux Kernel, made by the NSA (National Security Agency). It implements Mandatory Access Controls (MAC), which allow an administrator to define, how applications and users can access resources on a system.

There is more detail in the SELinux Wki: https://selinuxproject.org/page/FAQ
... and the CentOS documentation: https://wiki.centos.org/HowTos/SELinux

Some distributions have it installed by default, but not active, some have it installed and active and some don't have it installed.

How do I know if SELinux is active? SELinux comes with some new commands. To see the current status of SELinux, use "getenforce" or "sestatus": [root@localhost ~]# getenforce Enforcing

- OR -

[root@localhost ~]# sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 28

There are three modes available:

  • Enforcing: SELinux is active and enforcing restrictions.
  • Permissive: Restrictions are not enforced, but policy violations are reported.
  • Disabled: SELinux is turned off.

Changing modes

If you want to change the mode of SELinux, use "setenforce":

setenforce [ Enforcing | Permissive | 1 | 0 ]

Or edit the configuration file under "/etc/selinux/config".

Install semanage

If you want to change SELinux policies in an easy way, you will need the tool "semanage" it can be installed with the following command:

yum install policycoreutils-python

Create a directory MySQL/MariaDB can access

NOTE: I am going to work with MariaDB for this blog, as it can be installed from repository in CentOS.

The easy way to create a new policy, which allows to MySQL or MariDB to use a directory, is to install "semanage". It is provided with the following package:

yum install policycoreutils-python

Then proceed to create the new directory, where MySQL/MariaDB could store the binary logs, if they should not be in the datadir.

mkdir /var/lib/mysql_binlog/ chown -R mysql:mysql mysql* semanage fcontext -a -t mysqld_db_t "/var/lib/mysql_binlog(/.*)?" restorecon -Rv /var/lib/mysql_binlog

NOTE: You have to give the absolute path to the file or the directory!

If you want to use MySQL/MariaDB on a non-standard port, you also have to allow usage of that port:

semanage port -a -t mysqld_port_t -p tcp 3307

Once you have created the new directory for the binary logs and made sure it is owned by mysql, you need to change the type of the directory you created to the one that allows MySQL/MariDB to use this directory. If you do not do this, you will get a "Permission denied (13)" error.

"semanage" is used to make this change persistent, even when the entire file system relabelled.

I was although unable to change the socket. I am yet unsure what the problem was, as MariaDB did not start or return any error.

Enable MySQL to write to this directory vi /etc/my.cnf ... [mysqld] log-bin=/var/lib/mysql_binlog/binlog ... systemctl restart mariadb Taxonomy upgrade extras: mysqlmariadbcentos

MySQL and MariaDB variables inflation

Shinguz - Mon, 2016-12-12 21:43

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%';
VersionSystemIB Sys.StatusIB Stat.MySQL 4.0.3014322*133**0MySQL 4.1.2518926*164**0MySQL 5.0.962393625242MySQL 5.1.732773629142MySQL 5.5.513176031247MySQL 5.6.3143812034151MySQL 5.7.1549113135351MySQL 8.0.048812436351

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

VersionSystemIB Sys.StatusIB Stat.MariaDB 5.1.443547230144MariaDB 5.2.103978632446MariaDB 5.5.4141910341399MariaDB 10.0.2153714745595MariaDB 10.1.18***589178517127MariaDB 10.2.2****58616448196

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

Taxonomy upgrade extras: mysqlvariablesstatusmariadb

New Features in MySQL and MariaDB

Shinguz - Tue, 2016-11-22 15:45

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.
  • 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 8.1 MariaDB 10.3 (link) and 10.4

No details are known yet. MySQL developer meetingt took place in November 2016.

  • 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: featuresmariadbmysqlnew

FromDual Performance Monitor for MySQL and MariaDB 1.0.0 has been released

FromDual.en - Thu, 2016-11-03 23:03

FromDual has the pleasure to announce the release of the new version 1.0.0 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. Further significant functionality has changed and improved. So please read carefully...

Changes in fpmmm v1.0.0 fpmmm agent
  • SysV init script added to run fpmmm as daemon.
  • SystemD unit file added to run fpmmm as daemon.
  • Default location of fpmmm.conf file made unique to /etc/.
  • Requirement checks improved and made more restrictive.
  • Error Messages improved and made more understandable.
  • Library MyEnv.inc synced from MyEnv project.
  • zabbix_agentd.init and zabbix_server.init moved from bin to tpl folder.
  • fpmmm_server.init renamed to fpmmm_sysv.init.
  • PHP default timezone set to Europe/Zurich.
  • fpmmm Agent lock file is now touched at every run to show that agent is still alive.
  • Get user privileges to do checks.
  • Reconnect implemented for fpmmm daemon.
  • Angel script added: fpmmm_angel.
  • New Type = host added to fpmmm configuration template file.
  • Fpmmm daemon writes a PID file.
  • Fpmmm can be daemonized now to work as stand-alone system (without zabbix_agent).
  • Connection test added for daemon.
  • Interval for fpmmm daemon is introduced.
  • Log verbosity for some messages adjusted.
  • fpmmm daemon reacts on SIGTERM (stop) and SIGHUP (reload). Reload is not implemented yet.
  • Default file locations moved to LSB suggestions.
fpmmm agent installer
  • Error Messages improved and made more understandable.
InnoDB module
  • InnoDB variable innodb_log_file_size of 0 is not possible and thus suppressed.
  • Check for lacking PROCESS privilege added.
  • InnoDB status Innodb_max_dirty_pages_pct added.
Master module
  • Check for lacking REPLICATION CLIENT privilege added.
Memcached module
  • Error Messages improved and made more understandable.
Server module
  • Error Messages improved and made more understandable.
  • Advices to fix problems improved.
  • iostat is used to gather I/O metrics.
Mysql module
  • Gather processlist information introduced.
  • MySQL variable max_sort_length check added.
  • MySQL variable storage_engine added

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

Taxonomy upgrade extras: mysqlperformancemonitormonitoringfpmmmmaasperformance monitormpmrelease

FromDual Backup and Recovery Manager for MySQL 1.2.3 has been released

FromDual.en - Sat, 2016-10-29 14:50

FromDual has the pleasure to announce the release of the new version 1.2.3 of the popular Backup and Recovery Manager for MySQL and MariaDB (fromdual_brman).

You can download the FromDual Backup and Recovery Manager from here.

In the inconceivable case that you find a bug in the Backup and Recovery Manager please report it to our Bugtracker or just send us an email.

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

Upgrade from 1.2.x to 1.2.3 # cd ${HOME}/product # tar xf /download/fromdual_brman-1.2.3.tar.gz # rm -f fromdual_brman # ln -s fromdual_brman-1.2.3 fromdual_brman
Changes in FromDual Backup Manager 1.2.3

This release contains mainly fixes related to MySQL 5.7 and various minor fixes.

You can verify your current FromDual Backup Manager version with the following command:

shell> fromdual_bman --version
FromDual Backup Manager
  • New tests added to test-suite.
  • MyEnv library myEnv.inc merged into project.
  • Output of overview made nicer for ARCHIVE tables.
  • Specified but missing configuration file is caught correctly now (bug #163).
  • Return and error codes fixed and cleaned up.
  • 1M table creation script added to utl/create_1M_tables.php.
  • ORDER BY added to all GROUP BY statements to be also correct in future MySQL releases.
  • Added short options -h and -V for version and help to fromdual_bman.php.
  • Removed redundant error number in fromdual_bman.inc.
  • Function parseConnectString moved from fromdual_bman.inc to myEnv.inc.
FromDual Backup Manager and MySQL 5.7
  • Bugs related to MySQL 5.7 version detection fixed.
FromDual Backup Manager Privilege Backup
  • Privilege backup was fixed for new MySQL 5.7 SHOW GRANTS behaviour.
  • Semicolon (;) was added to privilege backup output.
FromDual Backup Manager and Xtrabackup
  • New behaviour of MySQL 5.7 for physical backup fixed.
  • Backup manager works with new xtrabackup v2.3.x again. Typo bug fixed.
FromDual Backup Manager and LVM Snapshot Backup
  • Started to implement LVM snapshot backup functionality.
FromDual Backup and Recovery Manager Catalog
  • Catalog version mismatch error made more clear.
FromDual Backup Manager Binary Log Backup
  • Error catch implemented for binary logs removed manually.
FromDual Recovery Manager
  • Changed wrong rc in progress_bar.php
Taxonomy upgrade extras: BackupRestoreRecoverypitrfromdual_brman

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

Shinguz - Wed, 2016-10-26 22:15

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 instancemysqld_multimysql enterprise serverrhelred hatsystemdmyenv

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

Shinguz - Tue, 2016-10-25 22:26
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
  • 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 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

See also: MySQL Enterprise Edition.

If we check this in the packages we find the following additional plug-ins in the MySQL Enterprise Server:

shell> ls -la mysql-advanced-5.7.16-linux-glibc2.5-x86_64/lib/plugin: -rwxr-xr-x 1 mysql mysql 3556085 Sep 28 19:35 audit_log.so -rwxr-xr-x 1 mysql mysql 73855 Sep 28 19:35 authentication_pam.so -rwxr-xr-x 1 mysql mysql 1595720 Sep 28 19:35 firewall.so -rwxr-xr-x 1 mysql mysql 3748543 Sep 28 19:35 keyring_okv.so -rwxr-xr-x 1 mysql mysql 2283844 Sep 28 19:35 openssl_udf.so -rwxr-xr-x 1 mysql mysql 567032 Sep 28 19:34 thread_pool.so
MySQL Enterprise Server Certifications 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 this topic.

Different libraries

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

This is one one side a legal stuff GPL vs BSD license. On the other side it is a political question. 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 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 servermysql community servermysql enterprise serverenterprise

Pages

Subscribe to FromDual Aggregator – FromDual all (en)