You are here

MySQL Tech-Feed (en)

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

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

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

Shinguz - Mon, 2016-10-24 23:01
Prepare the RPM repository server

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

shell> sudo apt-get install createrepo

Create the directory structures and initialize the repositories:

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

Copy the MySQL Enterprise RPM packages to the repository:

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

Update the RPM repository meta data:

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

Now the RPM repository server is finished.

Prepare the RPM client

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

# # /etc/yum.repos.d/mysql-enterprise.repo # [mysql57-enterprise] name=MySQL 5.7 Enterprise Server baseurl=http://192.168.56.1/repos/centos/$releasever/os/$basearch/ gpgcheck=1 enabled=1 gpgkey=http://192.168.56.1/repos/centos/RPM-GPG-KEY-CentOS-7

Clean up the yum cache:

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

Show all know RPM repositories:

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

Search what MySQL Enterprise Server packages are available:

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

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

shell> yum install mysql-commercial-server Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.imt-systems.com * extras: mirror.eu.oneandone.net * updates: mirror.rackspeed.de Resolving Dependencies --> Running transaction check ---> Package mysql-commercial-server.x86_64 0:5.7.16-1.1.el7 will be installed --> Processing Dependency: mysql-commercial-client(x86-64) >= 5.7.9 for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 --> Processing Dependency: libaio.so.1(LIBAIO_0.4)(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 --> Processing Dependency: perl(Getopt::Long) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 --> Processing Dependency: /usr/bin/perl for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 --> Processing Dependency: perl(strict) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 --> Processing Dependency: net-tools for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 --> Processing Dependency: libaio.so.1(LIBAIO_0.1)(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 --> Processing Dependency: libaio.so.1()(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 --> Running transaction check ---> Package libaio.x86_64 0:0.3.109-13.el7 will be installed ---> Package mysql-commercial-client.x86_64 0:5.7.16-1.1.el7 will be installed ---> Package net-tools.x86_64 0:2.0-0.17.20131004git.el7 will be installed ---> Package perl.x86_64 4:5.16.3-286.el7 will be installed --> Processing Dependency: perl-libs = 4:5.16.3-286.el7 for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Socket) >= 1.3 for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Scalar::Util) >= 1.10 for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl-macros for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl-libs for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(threads::shared) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(threads) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(constant) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Time::Local) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Time::HiRes) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Storable) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Socket) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Scalar::Util) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Pod::Simple::XHTML) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Pod::Simple::Search) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Filter::Util::Call) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(File::Temp) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(File::Spec::Unix) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(File::Spec::Functions) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(File::Spec) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(File::Path) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Exporter) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Cwd) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Carp) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: libperl.so()(64bit) for package: 4:perl-5.16.3-286.el7.x86_64 ---> Package perl-Getopt-Long.noarch 0:2.40-2.el7 will be installed --> Processing Dependency: perl(Pod::Usage) >= 1.14 for package: perl-Getopt-Long-2.40-2.el7.noarch --> Processing Dependency: perl(Text::ParseWords) for package: perl-Getopt-Long-2.40-2.el7.noarch --> Running transaction check ---> Package perl-Carp.noarch 0:1.26-244.el7 will be installed ---> Package perl-Exporter.noarch 0:5.68-3.el7 will be installed ---> Package perl-File-Path.noarch 0:2.09-2.el7 will be installed ---> Package perl-File-Temp.noarch 0:0.23.01-3.el7 will be installed ---> Package perl-Filter.x86_64 0:1.49-3.el7 will be installed ---> Package perl-PathTools.x86_64 0:3.40-5.el7 will be installed ---> Package perl-Pod-Simple.noarch 1:3.28-4.el7 will be installed --> Processing Dependency: perl(Pod::Escapes) >= 1.04 for package: 1:perl-Pod-Simple-3.28-4.el7.noarch --> Processing Dependency: perl(Encode) for package: 1:perl-Pod-Simple-3.28-4.el7.noarch ---> Package perl-Pod-Usage.noarch 0:1.63-3.el7 will be installed --> Processing Dependency: perl(Pod::Text) >= 3.15 for package: perl-Pod-Usage-1.63-3.el7.noarch --> Processing Dependency: perl-Pod-Perldoc for package: perl-Pod-Usage-1.63-3.el7.noarch ---> Package perl-Scalar-List-Utils.x86_64 0:1.27-248.el7 will be installed ---> Package perl-Socket.x86_64 0:2.010-3.el7 will be installed ---> Package perl-Storable.x86_64 0:2.45-3.el7 will be installed ---> Package perl-Text-ParseWords.noarch 0:3.29-4.el7 will be installed ---> Package perl-Time-HiRes.x86_64 4:1.9725-3.el7 will be installed ---> Package perl-Time-Local.noarch 0:1.2300-2.el7 will be installed ---> Package perl-constant.noarch 0:1.27-2.el7 will be installed ---> Package perl-libs.x86_64 4:5.16.3-286.el7 will be installed ---> Package perl-macros.x86_64 4:5.16.3-286.el7 will be installed ---> Package perl-threads.x86_64 0:1.87-4.el7 will be installed ---> Package perl-threads-shared.x86_64 0:1.43-6.el7 will be installed --> Running transaction check ---> Package perl-Encode.x86_64 0:2.51-7.el7 will be installed ---> Package perl-Pod-Escapes.noarch 1:1.04-286.el7 will be installed ---> Package perl-Pod-Perldoc.noarch 0:3.20-4.el7 will be installed --> Processing Dependency: perl(parent) for package: perl-Pod-Perldoc-3.20-4.el7.noarch --> Processing Dependency: perl(HTTP::Tiny) for package: perl-Pod-Perldoc-3.20-4.el7.noarch ---> Package perl-podlators.noarch 0:2.5.1-3.el7 will be installed --> Running transaction check ---> Package perl-HTTP-Tiny.noarch 0:0.033-3.el7 will be installed ---> Package perl-parent.noarch 1:0.225-244.el7 will be installed --> Finished Dependency Resolution Dependencies Resolved ========================================================================================================================================================================================== Package Arch Version Repository Size ========================================================================================================================================================================================== Installing: mysql-commercial-server x86_64 5.7.16-1.1.el7 mysql57-enterprise 163 M Installing for dependencies: libaio x86_64 0.3.109-13.el7 base 24 k mysql-commercial-client x86_64 5.7.16-1.1.el7 mysql57-enterprise 23 M net-tools x86_64 2.0-0.17.20131004git.el7 base 304 k perl x86_64 4:5.16.3-286.el7 base 8.0 M perl-Carp noarch 1.26-244.el7 base 19 k perl-Encode x86_64 2.51-7.el7 base 1.5 M perl-Exporter noarch 5.68-3.el7 base 28 k perl-File-Path noarch 2.09-2.el7 base 26 k perl-File-Temp noarch 0.23.01-3.el7 base 56 k perl-Filter x86_64 1.49-3.el7 base 76 k perl-Getopt-Long noarch 2.40-2.el7 base 56 k perl-HTTP-Tiny noarch 0.033-3.el7 base 38 k perl-PathTools x86_64 3.40-5.el7 base 82 k perl-Pod-Escapes noarch 1:1.04-286.el7 base 50 k perl-Pod-Perldoc noarch 3.20-4.el7 base 87 k perl-Pod-Simple noarch 1:3.28-4.el7 base 216 k perl-Pod-Usage noarch 1.63-3.el7 base 27 k perl-Scalar-List-Utils x86_64 1.27-248.el7 base 36 k perl-Socket x86_64 2.010-3.el7 base 49 k perl-Storable x86_64 2.45-3.el7 base 77 k perl-Text-ParseWords noarch 3.29-4.el7 base 14 k perl-Time-HiRes x86_64 4:1.9725-3.el7 base 45 k perl-Time-Local noarch 1.2300-2.el7 base 24 k perl-constant noarch 1.27-2.el7 base 19 k perl-libs x86_64 4:5.16.3-286.el7 base 687 k perl-macros x86_64 4:5.16.3-286.el7 base 43 k perl-parent noarch 1:0.225-244.el7 base 12 k perl-podlators noarch 2.5.1-3.el7 base 112 k perl-threads x86_64 1.87-4.el7 base 49 k perl-threads-shared x86_64 1.43-6.el7 base 39 k Transaction Summary ========================================================================================================================================================================================== Install 1 Package (+30 Dependent packages) Total download size: 197 M Installed size: 852 M Is this ok [y/d/N]: y
Further sources of information: Taxonomy upgrade extras: rpmrepositorymysqlmysql enterprise serverenterpriserhelred hat

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

Shinguz - Mon, 2016-10-24 22:03

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

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

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

shell> yum remove postfix mariadb-libs Loaded plugins: fastestmirror Resolving Dependencies --> Running transaction check ---> Package mariadb-libs.x86_64 1:5.5.50-1.el7_2 will be erased ---> Package postfix.x86_64 2:2.10.1-6.el7 will be erased --> Finished Dependency Resolution Dependencies Resolved ========================================================================================================================================================================================== Package Arch Version Repository Size ========================================================================================================================================================================================== Removing: mariadb-libs x86_64 1:5.5.50-1.el7_2 @updates 4.4 M postfix x86_64 2:2.10.1-6.el7 @anaconda 12 M Transaction Summary ========================================================================================================================================================================================== Remove 2 Packages Installed size: 17 M Is this ok [y/N]: n

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

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

shell> rpm --upgrade mysql-commercial-libs-compat-5.7.16-1.1.el7.x86_64.rpm mysql-commercial-libs-5.7.16-1.1.el7.x86_64.rpm mysql-commercial-common-5.7.16-1.1.el7.x86_64.rpm shell> yum localinstall mysql-commercial-server-5.7.16-1.1.el7.x86_64.rpm mysql-commercial-client-5.7.16-1.1.el7.x86_64.rpm Loaded plugins: fastestmirror Examining mysql-commercial-server-5.7.16-1.1.el7.x86_64.rpm: mysql-commercial-server-5.7.16-1.1.el7.x86_64 Marking mysql-commercial-server-5.7.16-1.1.el7.x86_64.rpm to be installed Examining mysql-commercial-client-5.7.16-1.1.el7.x86_64.rpm: mysql-commercial-client-5.7.16-1.1.el7.x86_64 Marking mysql-commercial-client-5.7.16-1.1.el7.x86_64.rpm to be installed Resolving Dependencies --> Running transaction check ---> Package mysql-commercial-client.x86_64 0:5.7.16-1.1.el7 will be installed ---> Package mysql-commercial-server.x86_64 0:5.7.16-1.1.el7 will be installed --> Processing Dependency: /usr/bin/perl for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 Loading mirror speeds from cached hostfile * base: wftp.tu-chemnitz.de * extras: wftp.tu-chemnitz.de * updates: mirror.rackspeed.de --> Processing Dependency: libaio.so.1(LIBAIO_0.1)(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 --> Processing Dependency: libaio.so.1(LIBAIO_0.4)(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 --> Processing Dependency: net-tools for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 --> Processing Dependency: perl(Getopt::Long) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 --> Processing Dependency: perl(strict) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 --> Processing Dependency: libaio.so.1()(64bit) for package: mysql-commercial-server-5.7.16-1.1.el7.x86_64 --> Running transaction check ---> Package libaio.x86_64 0:0.3.109-13.el7 will be installed ---> Package net-tools.x86_64 0:2.0-0.17.20131004git.el7 will be installed ---> Package perl.x86_64 4:5.16.3-286.el7 will be installed --> Processing Dependency: perl-libs = 4:5.16.3-286.el7 for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Socket) >= 1.3 for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Scalar::Util) >= 1.10 for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl-macros for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl-libs for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(threads::shared) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(threads) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(constant) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Time::Local) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Time::HiRes) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Storable) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Socket) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Scalar::Util) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Pod::Simple::XHTML) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Pod::Simple::Search) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Filter::Util::Call) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(File::Temp) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(File::Spec::Unix) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(File::Spec::Functions) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(File::Spec) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(File::Path) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Exporter) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Cwd) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: perl(Carp) for package: 4:perl-5.16.3-286.el7.x86_64 --> Processing Dependency: libperl.so()(64bit) for package: 4:perl-5.16.3-286.el7.x86_64 ---> Package perl-Getopt-Long.noarch 0:2.40-2.el7 will be installed --> Processing Dependency: perl(Pod::Usage) >= 1.14 for package: perl-Getopt-Long-2.40-2.el7.noarch --> Processing Dependency: perl(Text::ParseWords) for package: perl-Getopt-Long-2.40-2.el7.noarch --> Running transaction check ---> Package perl-Carp.noarch 0:1.26-244.el7 will be installed ---> Package perl-Exporter.noarch 0:5.68-3.el7 will be installed ---> Package perl-File-Path.noarch 0:2.09-2.el7 will be installed ---> Package perl-File-Temp.noarch 0:0.23.01-3.el7 will be installed ---> Package perl-Filter.x86_64 0:1.49-3.el7 will be installed ---> Package perl-PathTools.x86_64 0:3.40-5.el7 will be installed ---> Package perl-Pod-Simple.noarch 1:3.28-4.el7 will be installed --> Processing Dependency: perl(Pod::Escapes) >= 1.04 for package: 1:perl-Pod-Simple-3.28-4.el7.noarch --> Processing Dependency: perl(Encode) for package: 1:perl-Pod-Simple-3.28-4.el7.noarch ---> Package perl-Pod-Usage.noarch 0:1.63-3.el7 will be installed --> Processing Dependency: perl(Pod::Text) >= 3.15 for package: perl-Pod-Usage-1.63-3.el7.noarch --> Processing Dependency: perl-Pod-Perldoc for package: perl-Pod-Usage-1.63-3.el7.noarch ---> Package perl-Scalar-List-Utils.x86_64 0:1.27-248.el7 will be installed ---> Package perl-Socket.x86_64 0:2.010-3.el7 will be installed ---> Package perl-Storable.x86_64 0:2.45-3.el7 will be installed ---> Package perl-Text-ParseWords.noarch 0:3.29-4.el7 will be installed ---> Package perl-Time-HiRes.x86_64 4:1.9725-3.el7 will be installed ---> Package perl-Time-Local.noarch 0:1.2300-2.el7 will be installed ---> Package perl-constant.noarch 0:1.27-2.el7 will be installed ---> Package perl-libs.x86_64 4:5.16.3-286.el7 will be installed ---> Package perl-macros.x86_64 4:5.16.3-286.el7 will be installed ---> Package perl-threads.x86_64 0:1.87-4.el7 will be installed ---> Package perl-threads-shared.x86_64 0:1.43-6.el7 will be installed --> Running transaction check ---> Package perl-Encode.x86_64 0:2.51-7.el7 will be installed ---> Package perl-Pod-Escapes.noarch 1:1.04-286.el7 will be installed ---> Package perl-Pod-Perldoc.noarch 0:3.20-4.el7 will be installed --> Processing Dependency: perl(parent) for package: perl-Pod-Perldoc-3.20-4.el7.noarch --> Processing Dependency: perl(HTTP::Tiny) for package: perl-Pod-Perldoc-3.20-4.el7.noarch ---> Package perl-podlators.noarch 0:2.5.1-3.el7 will be installed --> Running transaction check ---> Package perl-HTTP-Tiny.noarch 0:0.033-3.el7 will be installed ---> Package perl-parent.noarch 1:0.225-244.el7 will be installed --> Finished Dependency Resolution Dependencies Resolved ========================================================================================================================================================================================== Package Arch Version Repository Size ========================================================================================================================================================================================== Installing: mysql-commercial-client x86_64 5.7.16-1.1.el7 /mysql-commercial-client-5.7.16-1.1.el7.x86_64 94 M mysql-commercial-server x86_64 5.7.16-1.1.el7 /mysql-commercial-server-5.7.16-1.1.el7.x86_64 721 M Installing for dependencies: libaio x86_64 0.3.109-13.el7 base 24 k net-tools x86_64 2.0-0.17.20131004git.el7 base 304 k perl x86_64 4:5.16.3-286.el7 base 8.0 M perl-Carp noarch 1.26-244.el7 base 19 k perl-Encode x86_64 2.51-7.el7 base 1.5 M perl-Exporter noarch 5.68-3.el7 base 28 k perl-File-Path noarch 2.09-2.el7 base 26 k perl-File-Temp noarch 0.23.01-3.el7 base 56 k perl-Filter x86_64 1.49-3.el7 base 76 k perl-Getopt-Long noarch 2.40-2.el7 base 56 k perl-HTTP-Tiny noarch 0.033-3.el7 base 38 k perl-PathTools x86_64 3.40-5.el7 base 82 k perl-Pod-Escapes noarch 1:1.04-286.el7 base 50 k perl-Pod-Perldoc noarch 3.20-4.el7 base 87 k perl-Pod-Simple noarch 1:3.28-4.el7 base 216 k perl-Pod-Usage noarch 1.63-3.el7 base 27 k perl-Scalar-List-Utils x86_64 1.27-248.el7 base 36 k perl-Socket x86_64 2.010-3.el7 base 49 k perl-Storable x86_64 2.45-3.el7 base 77 k perl-Text-ParseWords noarch 3.29-4.el7 base 14 k perl-Time-HiRes x86_64 4:1.9725-3.el7 base 45 k perl-Time-Local noarch 1.2300-2.el7 base 24 k perl-constant noarch 1.27-2.el7 base 19 k perl-libs x86_64 4:5.16.3-286.el7 base 687 k perl-macros x86_64 4:5.16.3-286.el7 base 43 k perl-parent noarch 1:0.225-244.el7 base 12 k perl-podlators noarch 2.5.1-3.el7 base 112 k perl-threads x86_64 1.87-4.el7 base 49 k perl-threads-shared x86_64 1.43-6.el7 base 39 k Transaction Summary ========================================================================================================================================================================================== Install 2 Packages (+29 Dependent packages) Total size: 826 M Total download size: 12 M Installed size: 852 M Is this ok [y/d/N]: y

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

Taxonomy upgrade extras: installationinstallmysqlenterpriserhelred hatcentosmariadbserver

Beware of large MySQL max_sort_length parameter

Shinguz - Wed, 2016-08-24 23:40

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

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

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

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

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

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

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

An we have seen the query in SHOW PROCESSLIST:

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

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

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

[mysqld] max_sort_length = 8M sort_buffer_size = 20M

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

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

max_sort_lengthexecution time [s]comment 64 8.8 s128 8.2 s256 9.3 s512 11.8 s 1k 14.9 s 2k 20.0 s 8k129.0 s 8M 75.0 sdisk full (50 G)
Conclusion

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

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

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

Addendum

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

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

mysql> SELECT * FROM test ORDER BY field5, field4, field3, field2, field1; ERROR 3 (HY000): Error writing file '/tmp/MYBuWcXP' (Errcode: 28 - No space left on device) shell> lsof -p 14733 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mysqld 14733 mysql 32u REG 8,18 9705619456 30147474 /tmp/MYck8vf4 (deleted) mysqld 14733 mysql 49u REG 8,18 749797376 30147596 /tmp/MYBuWcXP (deleted)

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

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

And some hints from MadMerlin|work pointed me to:

shell> ls /proc//fd

Where you can also see those temporary files.

Thanks to MadMerlin|work for the hints!

Taxonomy upgrade extras: sortfileorder by

FromDual Performance Monitor for MySQL and MariaDB 0.10.6 has been released

Shinguz - Wed, 2016-08-03 19:40

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

You can download fpmmm from here.

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

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

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

Changes in fpmmm v0.10.6 fpmmm agent
  • Do not connect to server bug fixed.
  • Special case when lock file was removed when it was read is fixed.
  • Added ORDER BY to all GROUP BY to be compliant for the future.
  • Zabbix 3.0 templates added.
  • MaaS: Function curl_file_create implemented for php < 5.5
  • MaaS: Debug message fixed.
  • Maas: Curl upload fixed.
  • MaaS: InnoDB: Deadlock and Foreign Key errors are only escaped with xxx when used in MaaS. Otherwise they are sent normally. Foreign Key errors with MaaS is now also escaped with xxx.
Process module
  • Wrong substitution in process vm calculation fixed.
Galera module
  • Template: Galera items changed from normal to delta.
InnoDB module
  • Template: Fixed InnoDB template to work with Zabbix v3.0.
  • Template: InnoDB locking graph improved.

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

Taxonomy upgrade extras: mysqlperformancemonitormonitoringfpmmmmaasperformance monitormpmrelease

MySQL Environment MyEnv 1.3.1 has been released

Shinguz - Wed, 2016-08-03 08:27

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

The new MyEnv can be downloaded here.

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

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

Upgrade from 1.1.x or higher to 1.3.1 # cd ${HOME}/product # tar xf /download/myenv-1.3.1.tar.gz # rm -f myenv # ln -s myenv-1.3.1 myenv

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

cd ${HOME}/product/myenv ln -s ../../utl/oem_agent.php plg/showMyEnvStatus/
Changes in MyEnv 1.3.1 MyEnv
  • Bash function bootstrap added.
  • Galera options --bootstrap --new-cluster and start method bootstrap was implemented. Typo fixed.
  • New 5.7 variables added and 5.6 variables to avoid nasty warnings in the error log added to the my.cnf template. Further new file system structure was prepared.
  • MySQL 5.7 variables for error log behaviour added.
  • Comment for log_bin added to my.cnf template.
  • ulimit problem fixed rudely in MyEnv init script.
  • wsrep_provider for CentOS added in my.cnf template.
  • Cgroup template improved.
  • Cgroup how-to improved and configuration example added.
MyEnv Installer
  • default as instance name set to blacklist.
  • Typo fixed in help of installMyEnv.
MyEnv Utilities
  • Test table prepared for explicit_defaults_for_timestamp configuration.
  • insert_test.sh now has optional parameters for user, host etc.

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

Taxonomy upgrade extras: myenvoperationMySQL Operationsmulti instanceconsolidationtestingupgradereleasecloudcgroupscontainermysqld_multi

Temporary tables and MySQL STATUS information

Shinguz - Fri, 2016-07-08 18:42

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

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

Caution: Different MySQL or MariaDB versions might behave differently!

Session 1 Global Session 2 CREATE TABLE t1 (id INT);
Query OK, 0 rows affected     Com_create_table +1
Opened_table_definitions +1 Com_create_table +1
Opened_table_definitions +1    CREATE TABLE t1 (id INT);
ERROR 1050 (42S01): Table 't1' already exists     Com_create_table +1
Open_table_definitions +1
Open_tables +1
Opened_table_definitions +1
Opened_tables +1 Com_create_table + 1
Open_table_definitions +1
Open_tables +1
Opened_table_definitions +1
Opened_tables +1    CREATE TABLE t1 (id INT);
ERROR 1050 (42S01): Table 't1' already exists     Com_create_table + 1 Com_create_table + 1    DROP TABLE t1;
Query OK, 0 rows affected     Com_drop_table +1
Open_table_definitions -1
Open_tables -1 Com_drop_table +1
Open_table_definitions -1
Open_tables -1    DROP TABLE t1;
ERROR 1051 (42S02): Unknown table 'test.t1'     Com_drop_table -1 Com_drop_table -1    CREATE TEMPORARY TABLE ttemp (id INT);
Query OK, 0 rows affected     Com_create_table +1
Opened_table_definitions +2
Opened_tables +1 Com_create_table +1
Opened_table_definitions +2
Opened_tables +1    CREATE TEMPORARY TABLE ttemp (id INT);
ERROR 1050 (42S01): Table 'ttemp' already exists     Com_create_table +1 Com_create_table +1    DROP TABLE ttemp;
Query OK, 0 rows affected     Com_drop_table +1 Com_drop_table +1    CREATE TEMPORARY TABLE ttemp (id int);
Query OK, 0 rows affected   CREATE TEMPORARY TABLE ttemp (id int);
Query OK, 0 rows affected Com_create_table +1
Opened_table_definitions +2
Opened_tables +1 Com_create_table +2
Opened_table_definitions +4
Opened_tables +2 Com_create_table +1
Opened_table_definitions +2
Opened_tables +1  DROP TABLE ttemp;
Query OK, 0 rows affected   DROP TABLE ttemp;
Query OK, 0 rows affected Com_drop_table +1 Com_drop_table +2 Com_drop_table +1
Conclusion
  • A successful CREATE TABLE command opens and closes a table definition.
  • A non successful CREATE TABLE command opens the table definition and the file handle of the previous table. So a faulty application can be quite expensive.
  • A further non successful CREATE TABLE command has no other impact.
  • A DROP TABLE command closes a table definition and the file handle.
  • A CREATE TEMPORARY TABLE opens 2 table definitions and the file handle. Thus behaves different than CREATE TABLE
  • But a faulty CREATE TEMPORARY TABLE seems to be much less intrusive.
  • Open_table_definitions and Open_tables is always global, also in session context.
Taxonomy upgrade extras: statustemporary table

MySQL spatial functionality - points of interest around me

Shinguz - Wed, 2016-06-01 10:13

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

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

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

   My position   Shops   Restaurants   Cafes

To do this I needed a table and some data:

CREATE TABLE poi ( id INT UNSIGNED NOT NULL AUTO_INCREMENT , name VARCHAR(40) , type VARCHAR(20) , sub_type VARCHAR(20) , pt POINT NOT NULL , PRIMARY KEY (id) , SPATIAL INDEX(pt) ) ENGINE=InnoDB; INSERT INTO poi (name, type, sub_type, pt) VALUES ('Shop 1', 'Shop', 'Cloth', Point(2,2)) , ('Cafe 1', 'Cafe', '', Point(11,2)) , ('Shop 2', 'Shop', 'Cloth', Point(5,4)) , ('Restaurant 1', 'Restaurant', 'Portugies', Point(8,7)) , ('Cafe 2', 'Cafe', '', Point(3,9)) , ('Shop 3', 'Shop', 'Hardware', Point(11,9)) ;

This looks as follows:

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

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

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

The query execution plan looks like this:

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

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

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

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

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

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

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

With this hexagon I tried again:

SET @hereami = POINT(9,4); SET @hexagon = 'POLYGON((9 8.5, 12.897 6.25, 12.897 1.75, 9 -0.5, 5.103 1.75, 5.103 6.25, 9 8.5))'; SELECT id, ST_AsText(pt) AS point, name, ROUND(ST_Distance(@hereami, pt), 2) AS distance FROM poi WHERE MBRContains(ST_GeomFromText(@hexagon), pt) AND ST_Distance(@hereami, pt) < 4.5 AND type = 'Shop' ORDER BY distance ASC ; Empty set (0.03 sec)

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

At least the index is considered now! :-)

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

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

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

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

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

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

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

SELECT id, ST_AsText(pt) AS point, name, ROUND(ST_Distance(@hereami, pt), 2) AS distance FROM poi FORCE INDEX (xy) WHERE x >= 4.5 AND x <= 13.5 AND y >= -0.5 AND y <= 8.5 AND ST_Distance(@hereami, pt) < 4.5 AND type = 'Shop' ORDER BY distance ASC ; 1 row in set (0.03 sec) id: 1 select_type: SIMPLE table: poi partitions: NULL type: range possible_keys: xy key: xy key_len: 10 ref: NULL rows: 115592 filtered: 1.11 Extra: Using index condition; Using where; Using filesort

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

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

DROP FUNCTION polygon_circle; delimiter // CREATE FUNCTION polygon_circle(pX DOUBLE, pY DOUBLE, pDiameter DOUBLE, pPoints SMALLINT UNSIGNED) -- RETURNS VARCHAR(4096) DETERMINISTIC RETURNS POLYGON DETERMINISTIC BEGIN DECLARE i SMALLINT UNSIGNED DEFAULT 0; DECLARE vSteps SMALLINT UNSIGNED; DECLARE vPolygon VARCHAR(4096) DEFAULT ''; -- Input validation IF pPoints < 3 THEN RETURN NULL; END IF; IF pPoints > 360 THEN RETURN NULL; END IF; IF pPoints > 90 THEN RETURN NULL; END IF; if (360 % pPoints) != 0 THEN RETURN NULL; END IF; -- Start SET vSteps = 360 / pPoints; WHILE i < 360 DO SET vPolygon = CONCAT(vPolygon, (pX + (SIN(i * 2 * PI() / 360) * pDiameter)), ' ', (pY + (COS(i * 2 * PI() / 360) * pDiameter)), ', '); SET i = i + vSteps; END WHILE; -- Add first point again SET vPolygon = CONCAT("POLYGON((", vPolygon, (pX + (SIN(0 * 2 * PI() / 360) * pDiameter)), " ", (pY + (COS(0 * 2 * PI() / 360) * pDiameter)), "))"); -- RETURN vPolygon; RETURN ST_GeomFromText(vPolygon); END; // delimiter ; SELECT ST_AsText(polygon_circle(9, 4, 4.5, 6)); -- SELECT polygon_circle(9, 4, 4.5, 8);

Then calling the query in the same way:

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

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

Results Test#rowsoperationlatencyTotal655360FTS1300 msSpatial exact Circle4128FTS520 msSpatial inner Hexagon3916range (pt)20 msSpatial outer Square4128range (pt)30 msConventional outer Square on (x)4128range (x) or (y)150 msConventional outer Square on (xy)4128range (x,y)30 msSpatial good Polygon4128range (pt)30 msTaxonomy upgrade extras: spatialgis

Why you should take care of MySQL data types

Shinguz - Wed, 2016-05-25 11:42

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

CREATE TABLE `test` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `data` varchar(64) DEFAULT NULL, `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `data` (`data`) ) ENGINE=InnoDB; EXPLAIN SELECT * FROM test WHERE data = 42\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: test partitions: NULL type: ALL possible_keys: data key: NULL key_len: NULL ref: NULL rows: 522500 filtered: 10.00 Extra: Using where EXPLAIN SELECT * FROM test WHERE data = '42'\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: test partitions: NULL type: ref possible_keys: data key: data key_len: 67 ref: const rows: 1 filtered: 100.00 Extra: NULL

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

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

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

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

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

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

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

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

SELECT * FROM test WHERE id = 42; +----+----------------------------------+---------------------+ | id | data | ts | +----+----------------------------------+---------------------+ | 42 | 81d74057d7be8f20563da404bb1b3ab0 | 2016-05-25 10:26:56 | +----+----------------------------------+---------------------+ SELECT * FROM test WHERE id = '42'; +----+----------------------------------+---------------------+ | id | data | ts | +----+----------------------------------+---------------------+ | 42 | 81d74057d7be8f20563da404bb1b3ab0 | 2016-05-25 10:26:56 | +----+----------------------------------+---------------------+ EXPLAIN SELECT * FROM test WHERE id = 42\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: test partitions: NULL type: const possible_keys: PRIMARY key: PRIMARY key_len: 4 ref: const rows: 1 filtered: 100.00 Extra: NULL
Taxonomy upgrade extras: query tuningexplaindata typesql

MariaDB 10.2 Window Function Examples

Shinguz - Mon, 2016-04-18 22:39

MariaDB 10.2 has introduced some Window Functions for analytical queries.

See also: Window Functions, Window Functions, Window function and Rows and Range, Preceding and Following

Function ROW_NUMBER()

Simulate a row number (sequence) top 3

SELECT ROW_NUMBER() OVER (PARTITION BY NULL ORDER BY category_id) AS num , category.category_id FROM category LIMIT 3 ;

or

SELECT ROW_NUMBER() OVER (ORDER BY category_id) AS num , category.category_id FROM category LIMIT 3 ; +-----+-------------+ | num | category_id | +-----+-------------+ | 1 | ACTUAL | | 2 | ADJUSTMENT | | 3 | BUDGET | +-----+-------------+
ROW_NUMBER() per PARTITION SELECT ROW_NUMBER() OVER (PARTITION BY store_type ORDER BY SUM(sf.store_sales) DESC) AS Nbr , s.store_type AS "Store Type", s.store_city AS City, SUM(sf.store_sales) AS Sales FROM store AS s JOIN sales_fact AS sf ON sf.store_id = s.store_id GROUP BY s.store_type, s.store_city ORDER BY s.store_type, Rank ; +-----+---------------------+---------------+------------+ | Nbr | Store Type | City | Sales | +-----+---------------------+---------------+------------+ | 1 | Deluxe Supermarket | Salem | 1091274.68 | | 2 | Deluxe Supermarket | Tacoma | 993823.44 | | 3 | Deluxe Supermarket | Hidalgo | 557076.84 | | 4 | Deluxe Supermarket | Merida | 548297.64 | | 5 | Deluxe Supermarket | Vancouver | 534180.96 | | 6 | Deluxe Supermarket | San Andres | 518044.80 | | 1 | Gourmet Supermarket | Beverly Hills | 619013.24 | | 2 | Gourmet Supermarket | Camacho | 357772.88 | | 1 | Mid-Size Grocery | Yakima | 304590.92 | | 2 | Mid-Size Grocery | Mexico City | 166503.48 | | 3 | Mid-Size Grocery | Victoria | 144827.48 | | 4 | Mid-Size Grocery | Hidalgo | 144272.84 | +-----+---------------------+---------------+------------+
Function RANK()

Ranking of top 10 salaries

SELECT full_name AS Name, salary AS Salary , RANK() OVER(ORDER BY salary DESC) AS Rank FROM employee ORDER BY salary DESC LIMIT 10 ; +-----------------+----------+------+ | Name | Salary | Rank | +-----------------+----------+------+ | Sheri Nowmer | 80000.00 | 1 | | Darren Stanz | 50000.00 | 2 | | Donna Arnold | 45000.00 | 3 | | Derrick Whelply | 40000.00 | 4 | | Michael Spence | 40000.00 | 4 | | Maya Gutierrez | 35000.00 | 6 | | Pedro Castillo | 35000.00 | 6 | | Laurie Borges | 35000.00 | 6 | | Beverly Baker | 30000.00 | 9 | | Roberta Damstra | 25000.00 | 10 | +-----------------+----------+------+
Function DENSE_RANK() SELECT full_name AS Name, salary AS Salary , DENSE_RANK() OVER(ORDER BY salary DESC) AS Rank FROM employee ORDER BY salary DESC LIMIT 10 ; +-----------------+----------+------+ | Name | Salary | Rank | +-----------------+----------+------+ | Sheri Nowmer | 80000.00 | 1 | | Darren Stanz | 50000.00 | 2 | | Donna Arnold | 45000.00 | 3 | | Derrick Whelply | 40000.00 | 4 | | Michael Spence | 40000.00 | 4 | | Maya Gutierrez | 35000.00 | 5 | | Pedro Castillo | 35000.00 | 5 | | Laurie Borges | 35000.00 | 5 | | Beverly Baker | 30000.00 | 6 | | Roberta Damstra | 25000.00 | 7 | +-----------------+----------+------+
Aggregation Windows SELECT full_name AS Name, salary AS Salary , SUM(salary) OVER(ORDER BY salary DESC) AS "Sum sal" FROM employee ORDER BY salary DESC LIMIT 10 ; +-----------------+----------+-----------+ | Name | Salary | Sum sal | +-----------------+----------+-----------+ | Sheri Nowmer | 80000.00 | 80000.00 | | Darren Stanz | 50000.00 | 130000.00 | | Donna Arnold | 45000.00 | 175000.00 | | Derrick Whelply | 40000.00 | 255000.00 | | Michael Spence | 40000.00 | 255000.00 | | Laurie Borges | 35000.00 | 360000.00 | | Maya Gutierrez | 35000.00 | 360000.00 | | Pedro Castillo | 35000.00 | 360000.00 | | Beverly Baker | 30000.00 | 390000.00 | | Roberta Damstra | 25000.00 | 415000.00 | +-----------------+----------+-----------+
Function CUME_DIST() and PERCENT_RANK() SELECT s.store_state AS State, s.store_city AS City, SUM(e.salary) AS Salary , CUME_DIST() OVER (PARTITION BY State ORDER BY Salary) AS CumeDist , PERCENT_RANK() OVER (PARTITION BY State ORDER BY Salary) AS PctRank FROM employee AS e JOIN store AS s on s.store_id = e.store_id WHERE s.store_country = 'USA' GROUP BY s.store_name ORDER BY s.store_state, Salary DESC ; +-------+---------------+-----------+--------------+--------------+ | State | City | Salary | CumeDist | PctRank | +-------+---------------+-----------+--------------+--------------+ | CA | Alameda | 537000.00 | 1.0000000000 | 1.0000000000 | | CA | Los Angeles | 221200.00 | 0.8000000000 | 0.7500000000 | | CA | San Diego | 220200.00 | 0.6000000000 | 0.5000000000 | | CA | Beverly Hills | 191800.00 | 0.4000000000 | 0.2500000000 | | CA | San Francisco | 30520.00 | 0.2000000000 | 0.0000000000 | | OR | Salem | 260220.00 | 1.0000000000 | 1.0000000000 | | OR | Portland | 221200.00 | 0.5000000000 | 0.0000000000 | | WA | Tacoma | 260220.00 | 1.0000000000 | 1.0000000000 | | WA | Spokane | 223200.00 | 0.8571428571 | 0.8333333333 | | WA | Bremerton | 221200.00 | 0.7142857143 | 0.6666666667 | | WA | Seattle | 220200.00 | 0.5714285714 | 0.5000000000 | | WA | Yakima | 74060.00 | 0.4285714286 | 0.3333333333 | | WA | Bellingham | 23220.00 | 0.2857142857 | 0.1666666667 | | WA | Walla Walla | 21320.00 | 0.1428571429 | 0.0000000000 | +-------+---------------+-----------+--------------+--------------+
Function NTILE() SELECT promotion_name, media_type , TO_DAYS(end_date)-TO_DAYS(start_date) AS Duration , NTILE(4) OVER (PARTITION BY promotion_name ORDER BY DURATION) AS quartile , NTILE(5) OVER (PARTITION BY promotion_name ORDER BY DURATION) AS quintile , NTILE(100) OVER (PARTITION BY promotion_name ORDER BY DURATION) AS precentile FROM promotion WHERE promotion_name = 'Weekend Markdown' LIMIT 10 ; +------------------+-------------------------+----------+----------+----------+------------+ | promotion_name | media_type | Duration | quartile | quintile | precentile | +------------------+-------------------------+----------+----------+----------+------------+ | Weekend Markdown | In-Store Coupon | 2 | 1 | 1 | 9 | | Weekend Markdown | Daily Paper | 3 | 3 | 4 | 29 | | Weekend Markdown | Radio | 3 | 4 | 4 | 36 | | Weekend Markdown | Daily Paper, Radio | 2 | 2 | 2 | 13 | | Weekend Markdown | Daily Paper, Radio, TV | 2 | 2 | 3 | 20 | | Weekend Markdown | TV | 2 | 3 | 3 | 26 | | Weekend Markdown | Sunday Paper | 3 | 3 | 4 | 28 | | Weekend Markdown | Daily Paper, Radio, TV | 3 | 3 | 4 | 34 | | Weekend Markdown | Daily Paper | 2 | 1 | 2 | 10 | | Weekend Markdown | Street Handout | 2 | 2 | 2 | 18 | | Weekend Markdown | Bulk Mail | 3 | 4 | 5 | 37 | | Weekend Markdown | Cash Register Handout | 2 | 2 | 2 | 14 | | Weekend Markdown | Daily Paper, Radio, TV | 3 | 3 | 4 | 31 | | Weekend Markdown | Sunday Paper | 2 | 3 | 3 | 27 | | Weekend Markdown | Sunday Paper, Radio, TV | 1 | 1 | 1 | 4 | +------------------+-------------------------+----------+----------+----------+------------+
Taxonomy upgrade extras: mariadbdwhreportingAnalyticsWindow FunctionOLAPData Mart

Galera Cache sizing

Shinguz - Mon, 2016-04-04 22:03

To synchronize the data between the Galera Cluster and a new or re-entering Galera node Galera Cluster uses 2 different mechanisms:

  • For full synchronization of data: Snapshot State Transfer (SST).
  • For delta synchronization of data: Incremental State Transfer (IST).

The Incremental State Transfer (IST) is relevant when a node is already known to the Galera Cluster and just left the cluster short time ago. This typically happens in a maintenance window during a rolling cluster restart.

The Galera Cache is a round-robin file based cache that keeps all the write-sets (= transactions + meta data) for a certain amount of time. This time, which should be bigger than your planned maintenance window, depends on the size of the Galera Cache (default 128 Mbyte) and the traffic which will happen during your maintenance window.

If your traffic is bigger than the Galera Cache can keep Galera Cluster will fall-back from IST to SST which is a very expensive operation for big databases.

The size of the Galera Cache can be calculated of the delta of the sum of the following 2 Galera status informations before and after the maintenance window:

Galera Cache size = delta(wsrep_replicated_bytes + wsrep_received_bytes)

Ideally you determine these values before your change happens in a time window where you have roughly the same traffic as during your maintenance window.

If you do not have a Galera Cluster in place yet or if you do not have those values available you can also use the numbers of the traffic written to the binary log or the number of the traffic written to InnoDB transaction log (Innodb_os_log_written).

As a rough estimate we have evaluated the following formulas for you:

Binary Log Traffic x 1.3 = Wsrep traffic (+/- 10%)

or

InnoDB Log File traffic x 0.6 = Wsrep traffic (+/- 10%)
Taxonomy upgrade extras: Galera Clustercachesizing

Max_used_connections per user/account

Shinguz - Thu, 2015-07-30 23:34
Taxonomy upgrade extras: max_used_connectionsuseraccountconnectionconfiguration

How many connections can be opened concurrently against my MySQL or MariaDB database can be configured and checked with the following command:

SHOW GLOBAL VARIABLES LIKE 'max_connections'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 505 | +-----------------+-------+

If this limit was ever reached in the past can be checked with:

SHOW GLOBAL STATUS LIKE 'max_use%'; +----------------------+-------+ | Variable_name | Value | +----------------------+-------+ | Max_used_connections | 23 | +----------------------+-------+

But on MySQL instances with many different applications (= databases/schemas) and thus many different users it is a bit more complicated to find out which of these users have connected how many times concurrently. We can configure how many connections one specific user can have at maximum at the same time with:

SHOW GLOBAL VARIABLES LIKE 'max_user_connections'; +----------------------+-------+ | Variable_name | Value | +----------------------+-------+ | max_user_connections | 500 | +----------------------+-------+

Further we can limit one specific user with:

GRANT USAGE ON *.* TO 'repl'@'%' WITH MAX_CONNECTIONS_PER_HOUR 100 MAX_USER_CONNECTIONS 10;

and check with:

SELECT User, Host, max_connections, max_user_connections FROM mysql.user; +------+---------------+-----------------+----------------------+ | User | Host | max_connections | max_user_connections | +------+---------------+-----------------+----------------------+ | root | localhost | 0 | 0 | | repl | % | 100 | 10 | | repl | 192.168.1.139 | 0 | 0 | +------+---------------+-----------------+----------------------+

But we have currently no chance to check if this limit was reached or nearly reached in the past...

A feature request for this was opened at MySQL wit bug #77888

Solution

If you cannot wait for the implementation here we have a little workaround:

DROP TABLE IF EXISTS mysql.`max_used_connections`; CREATE TABLE mysql.`max_used_connections` ( `USER` char(16) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL, `HOST` char(60) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL, `MAX_USED_CONNECTIONS` bigint(20) NOT NULL, PRIMARY KEY (`USER`, `HOST`) USING HASH ) ENGINE=MEMORY DEFAULT CHARSET=utf8 ; DROP EVENT IF EXISTS mysql.gather_max_used_connections; -- event_scheduler = on CREATE DEFINER=root@localhost EVENT mysql.gather_max_used_connections ON SCHEDULE EVERY 10 SECOND DO INSERT INTO mysql.max_used_connections SELECT user, host, current_connections FROM performance_schema.accounts WHERE user IS NOT NULL AND host IS NOT NULL ON DUPLICATE KEY UPDATE max_used_connections = IF(current_connections > max_used_connections, current_connections, max_used_connections) ; SELECT * FROM mysql.max_used_connections; +--------+-----------+----------------------+ | USER | HOST | MAX_USED_CONNECTIONS | +--------+-----------+----------------------+ | root | localhost | 4 | | zabbix | localhost | 21 | +--------+-----------+----------------------+

Caution: Because we used a MEMORY table those values are reset at every MySQL restart (as it happens with the PERFORMANCE_SCHEMA or the INFORMATION_SCHEMA).

FromDual Backup Manager for MySQL 1.2.2 has been released

Shinguz - Tue, 2015-06-23 11:33

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

You can download the FromDual Backup Manager from here.

In the inconceivable case that you find a bug in the Backup Manager please report it to our Bugtracker.

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

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

It contains mainly fixes with brman catalog and physical backups.

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

fromdual_bman --version
  • Archiving with physical backup bug fixed.
  • Connect replaced by OO style and error exit fixed.
  • Create catalog fixed.
  • Archivedir without archive option does not make sense.

Wir suchen Dich: MySQL/MariaDB DBA für FromDual Support

Shinguz - Mon, 2015-06-22 13:51
Taxonomy upgrade extras: jobDBAsupportWer sind wir?

FromDual ist das führende unabhängige Beratungs- und Dienstleistungsunternehmen für MySQL, Galera Cluster, MariaDB und Percona Server in Europa mit Hauptsitz in der Schweiz.

Unsere Kunden stammen hauptsächlich aus Europa und reichen vom kleinen Start-Up bis zur europäischen Top-500 Firma. Sie erhalten von uns Support bei Datenbank-Problemen, direkte Eingriffe als remote-DBA, Schulung für ihre DBAs und Entwickler sowie Beratung bei Architektur- und Design-Entscheidungen. Ausserdem entwickeln wir Tools rund um MySQL, schreiben Blog-Artikel und halten Vorträge bei Konferenzen.

Da unsere qualitativ guten Dienstleistungen immer mehr Kunden anziehen, brauchen wir Kollegen (m/w), welche selbst und mit uns wachsen wollen.

Stellenbeschreibung

Wir suchen deutschsprachige Mitarbeiter (Sie oder Ihn) auf Junior- oder Senior-Level für Dienstleistungen rund um MySQL (hauptsächlich Support und remote-DBA Arbeiten) in Vollzeit. Primär solltest Du sicherstellen, dass die geschäftskritischen MySQL-Datenbanken unserer Kunden wie am Schnürchen laufen - und falls nicht, diese schnell wieder ans Laufen kriegen...


Unser/e "Wunschkandidat/in"

  • hat Erfahrung im Betrieb kritischer und hoch verfügbarer produktiver Datenbanken hauptsächlich auf Linux,
  • kennt Replikation in allen Variationen aus der täglichen Arbeit,
  • weiß, wie die meist verbreiteten MySQL-HA-Setups funktionieren und wie man sie wieder effizient repariert, wenn ein Problem auftritt,
  • ist sattelfest in SQL,
  • bringt Erfahrung mit Galera Cluster mit,
  • kann Bash skripten und einfache Programme in mindestens einer verbreiteten Programmier-/Skripting-Sprache (PHP, Bash, ...) erstellen.

Wir suchen Verstärkung, die von soliden Grundlagen aus auf dem Weg zu diesem Ideal ist.


Was wir von Dir erwarten:

  • Kenntnisse in MySQL, Percona Server oder MariaDB oder Bereitschaft, sich diese anzueignen
  • wissen, wie man kritische Datenbank-Systeme betreibt
  • Verständnis, was beim Betrieb von Datenbanken falsch laufen kann
  • selbständige Arbeitsweise (remote) mit Kommunikation über IRC, Skype, Mail und Telefon
  • Kenntnisse des Linux Systems

DBA- oder DevOps-Erfahrungen wären z.B. eine gute fachliche Basis.


Du schätzt den direkten Kontakt mit Kunden, hast ein gutes Gespür für deren Probleme, kannst zuhören und findest schnell die eigentlichen Probleme. Du bist gewohnt, proaktiv zu handeln bevor etwas passiert, und führst den Kunden wieder auf den richtigen Pfad zurück.


Um Deine Arbeit erledigen zu können, arbeitest Du in einer europäischen Zeitzone. Deine Arbeitszeit kannst Du, der betrieblichen Situation entsprechend, flexibel gestalten. Wir erwarten, dass Du Deinen Beitrag zum Bereitschaftsdienst leistest. FromDual hat voraussichtlich keine Büroräumlichkeiten in Deinem Wohnort. Ein Umzug ist jedoch nicht notwendig: Wir ermöglichen Dir das Arbeiten von zu Hause aus oder unterstützen Dich bei der Suche einer geeigneten Arbeitsräumlichkeit in Deiner Nähe. Gute schriftliche und mündliche Englischkenntnisse sind erforderlich.

Was wir Dir bieten:
  • Deinen Leistungen angemessenes Gehalt.
  • Möglichkeit Dich zum Top MySQL-Datenbankspezialisten zu entwickeln.
  • Selbständiges Arbeiten.
  • Verantwortung für Deine Projekte und Kunden zu übernehmen.
  • Gute Kameradschaft im Team, sowie lockerer und angenehmer Umgang.
  • Stellenbezogene Weiterbildungsmöglichkeiten.
  • Teilnahme an Open Source Anlässen.
  • Arbeit von Deinem bevorzugten Wohnort aus.

Du solltest in der Lage sein, die meiste Zeit selbständig zu arbeiten, zu denken und zu handeln und Dir neues Wissen selbständig anzueignen (durch Web-Suche, die MySQL-Dokumentation, Ausprobieren, etc.). Solltest Du dennoch einmal nicht weiterkommen, werden Dir Deine Kollegen von FromDual gerne helfen.


Wenn Du jemanden brauchst, der Dir die ganze Zeit Dein Händchen hält, ist FromDual nicht die richtige Wahl.


Wie geht es weiter

Wenn Du an dieser Chance interessiert bist und Du denkst, dass Du die passende Kandidatin oder der passende Kandidat bist, würden wir uns freuen, von Dir zu hören. Wir wissen, dass niemand 100% auf diese Stellenbeschreibung passt!


Bitte schicke Deinen ungeschönten Lebenslauf mit Deinen Gehaltsvorstellungen an jobs@fromdual.com. Wenn Du mehr über diese Stelle erfahren oder wenn Du mit mir persönlich sprechen möchtest, ruf mich bitte an unter +41 79 830 09 33 (Oli Sennhauser, CTO). Bitte nur Bewerber, KEINE Headhunter!


Nachdem Du uns Deinen Lebenslauf zugeschickt hast, darfst Du Deine Fähigkeiten in einem kleinen MySQL-Test unter Beweis zu stellen. Nach bestandenem Test laden wir Dich für die finalen Interviews ein.

Controlling worldwide manufacturing plants with MySQL

Shinguz - Thu, 2015-05-14 21:43
Taxonomy upgrade extras: multi-source replicationmysql-replicationreplicationMulti-Master Replicationfan-in replicationrow filteringGTID

A MySQL customer of FromDual has different manufacturing plants spread across the globe. They are operated by local companies. FromDuals customer wants to maintain the manufacturing receipts centralized in a MySQL database in the Head Quarter in Europe. Each manufacturing plant should only see their specific data.

Manufacturing log information should be reported backup to European Head Quarter MySQL database.

The process was designed as follows:

Preparation of Proof of Concept (PoC)

To simulate all cases we need different schemas. Some which should be replicated, some which should NOT be replicated:

CREATE DATABASE finance; CREATE TABLE finance.accounting ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `data` varchar(255) DEFAULT NULL, `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `data_rename` (`data`) ); CREATE DATABASE crm; CREATE TABLE crm.customer ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `data` varchar(255) DEFAULT NULL, `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `data_rename` (`data`) ); CREATE DATABASE erp; -- Avoid specifying Storage Engine here!!! CREATE TABLE erp.manufacturing_data ( id INT UNSIGNED NOT NULL AUTO_INCREMENT , manufacture_plant VARCHAR(32) , manufacture_info VARCHAR(255) , PRIMARY KEY (id) , KEY (manufacture_plant) ); CREATE TABLE erp.manufacturing_log ( id INT UNSIGNED NOT NULL AUTO_INCREMENT , manufacture_plant VARCHAR(32) , log_data VARCHAR(255) , PRIMARY KEY (id) , KEY (manufacture_plant) );
MySQL replication architecture

Before you start with such complicated MySQL set-ups it is recommended to make a little sketch of what you want to build:

Preparing the Production Master database (Prod M1)

To make use of all the new and cool features of MySQL we used the new GTID replication. First we set up a Master (Prod M1) and its fail-over System (Prod M2) in the customers Head Quarter:

# /etc/my.cnf [mysqld] binlog_format = row # optional log_bin = binary-log # mandatory, also on Slave! log_slave_updates = on # mandatory gtid_mode = on # mandatory enforce_gtid_consistency = on # mandatory server-id = 39 # mandatory

This step requires a system restart (one minute downtime).

Preparing the Production Master standby database (Prod M2)

On Master (Prod M1):

GRANT REPLICATION SLAVE ON *.* TO 'replication'@'192.168.1.%' IDENTIFIED BY 'secret'; mysqldump -u root --set-gtid-purged=on --master-data=2 --all-databases --triggers --routines --events > /tmp/full_dump.sql

On Slave (Prod M2):

CHANGE MASTER TO MASTER_HOST='192.168.1.39', MASTER_PORT=3306 , MASTER_USER='replication', MASTER_PASSWORD='secret' , MASTER_AUTO_POSITION=1; RESET MASTER; -- On SLAVE! system mysql -u root < /tmp/full_dump.sql START SLAVE;

To make it easier for a Slave to connect to its master we set a VIP in front of those 2 database servers (VIP Prod). This VIP should be used by all applications in the head quarter and also the filter engines.

Set-up filter engines (Filter BR and Filter CN)

To make sure every manufacturing plant sees only the data it is allowed to see we need a filtering engine between the production site and the manufacturing plant (Filter BR and Filter CN).

To keep this filter engine lean we use a MySQL instance with all tables converted to the Blackhole Storage Engine:

# /etc/my.cnf [mysqld] binlog_format = row # optional log_bin = binary-log # mandatory, also on Slave! log_slave_updates = on # mandatory gtid_mode = on # mandatory enforce_gtid_consistency = on # mandatory server-id = 36 # mandatory default_storage_engine = blackhole

On the production master (Prod M1) we get the data as follows:

mysqldump -u root --set-gtid-purged=on --master-data=2 --triggers --routines --events --no-data --databases erp > /tmp/erp_dump_nd.sql

The Filter Engines (Filter BR and CN) are set-up as follows::

-- Here we can use the VIP! CHANGE MASTER TO master_host='192.168.1.33', master_port=3306 , master_user='replication', master_password='secret' , master_auto_position=1; RESET MASTER; -- On SLAVE! system cat /tmp/erp_dump_nd.sql | sed 's/ ENGINE=[a-zA-Z]*/ ENGINE=blackhole/' | mysql -u root START SLAVE;

Do not forget to also create the replication user on the filter engines.

GRANT REPLICATION SLAVE ON *.* TO 'replication'@'192.168.1.%' IDENTIFIED BY 'secret';
Filtering out all non ERP schemata

We only want the erp schema to be replicated to the manufacturing plants, not the crm or the finance application. This we achieve with the following option on the filter engines:

# /etc/my.cnf [mysqld] replicate_do_db = erp replicate_ignore_table = erp.manufacturing_log
MySQL row filtering

To achieve row filtering we use TRIGGERS. Make sure they are not replicated further down the hierarchy:

SET SESSION SQL_LOG_BIN = 0; use erp DROP TRIGGER IF EXISTS filter_row; delimiter // CREATE TRIGGER filter_row BEFORE INSERT ON manufacturing_data FOR EACH ROW BEGIN IF ( NEW.manufacture_plant != 'China' ) THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Row was filtered out.' , CLASS_ORIGIN = 'FromDual filter trigger' , SUBCLASS_ORIGIN = 'filter_row' , CONSTRAINT_SCHEMA = 'erp' , CONSTRAINT_NAME = 'filer_row' , SCHEMA_NAME = 'erp' , TABLE_NAME = 'manufacturing_data' , COLUMN_NAME = '' , MYSQL_ERRNO = 1644 ; END IF; END; // delimiter ; SET SESSION SQL_LOG_BIN = 0;

Up to now this would cause to stop replication for every filtered row. To avoid this we tell the Filtering Slaves to skip this error number:

# /etc/my.cnf [mysqld] slave_skip_errors = 1644
Attaching production manufacturing Slaves (Man BR M1 and Man CN M1)

When we have finished everything on our head quarter site. We can start with the manufacturing sites (BR and CN):

On Master (Prod M1):

mysqldump -u root --set-gtid-purged=on --master-data=2 --triggers --routines --events --where='manufacture_plant="Brazil"' --databases erp > /tmp/erp_dump_br.sql mysqldump -u root --set-gtid-purged=on --master-data=2 --triggers --routines --events --where='manufacture_plant="China"' --databases erp > /tmp/erp_dump_cn.sql

On the Manufacturing Masters (Man BR M1 and Man BR M2). Here we do NOT use a VIP because we think a blackhole storage engine is robust enough as master:

CHANGE MASTER TO master_host='192.168.1.43', master_port=3306 , master_user='replication', master_password='secret' , master_auto_position=1; RESET MASTER; -- On SLAVE! system cat /tmp/erp_dump_br.sql | mysql -u root START SLAVE;

The standby manufacturing (Man BR M2 and Man CN M2) database is created in the same way as the production manufacturing database on the master.

Testing replication from HQ to manufacturing plants

First we make sure, crm and finance is not replicated out and replication also does not stop (on Prod M1):

INSERT INTO finance.accounting VALUES (NULL, 'test data over VIP', NULL); INSERT INTO finance.accounting VALUES (NULL, 'test data over VIP', NULL); INSERT INTO crm.customer VALUES (NULL, 'test data over VIP', NULL); INSERT INTO crm.customer VALUES (NULL, 'test data over VIP', NULL); UPDATE finance.accounting SET data = 'Changed data'; UPDATE crm.customer SET data = 'Changed data'; DELETE FROM finance.accounting WHERE id = 1; DELETE FROM crm.customer WHERE id = 1; SELECT * FROM finance.accounting; SELECT * FROM crm.customer; SHOW SLAVE STATUS\G

The schema filter seems to work correctly. Then we check if also the row filter works correctly. For this we have to run the queries in statement based replication (SBR)! Otherwise the trigger would not fire:

use mysql INSERT INTO erp.manufacturing_data VALUES (NULL, 'China', 'Highly secret manufacturing info as RBR.'); INSERT INTO erp.manufacturing_data VALUES (NULL, 'Brazil', 'Highly secret manufacturing info as RBR.'); -- This needs SUPER privilege... :-( SET SESSION binlog_format = STATEMENT; -- Caution those rows will NOT be replicated!!! -- See filter rules for SBR INSERT INTO erp.manufacturing_data VALUES (NULL, 'China', 'Highly secret manufacturing info as SBR lost.'); INSERT INTO erp.manufacturing_data VALUES (NULL, 'Brazil', 'Highly secret manufacturing info as SBR lost.'); use erp INSERT INTO manufacturing_data VALUES (NULL, 'China', 'Highly secret manufacturing info as SBR.'); INSERT INTO manufacturing_data VALUES (NULL, 'Brazil', 'Highly secret manufacturing info as SBR.'); INSERT INTO manufacturing_data VALUES (NULL, 'Germany', 'Highly secret manufacturing info as SBR.'); INSERT INTO manufacturing_data VALUES (NULL, 'Switzerland', 'Highly secret manufacturing info as SBR.'); SET SESSION binlog_format = ROW; SELECT * FROM erp.manufacturing_data;
Production data back to head quarter

Now we have to take care about the production data on their way back to the HQ. To achieve this we use the new MySQL 5.7 feature called multi source replication. For multi source replication the replication repositories must be kept in tables instead of files:

# /etc/my.cnf [mysqld] master_info_repository = TABLE # mandatory relay_log_info_repository = TABLE # mandatory

Then we have to configure 2 replication channels from Prod M1 to their specific manufacturing masters over the VIP (VIP BR and VIP CN):

CHANGE MASTER TO MASTER_HOST='192.168.1.98', MASTER_PORT=3306 , MASTER_USER='replication', MASTER_PASSWORD='secret' , MASTER_AUTO_POSITION=1 FOR CHANNEL "manu_br"; CHANGE MASTER TO MASTER_HOST='192.168.1.99', MASTER_PORT=3306 , MASTER_USER='replication', MASTER_PASSWORD='secret' , MASTER_AUTO_POSITION=1 FOR CHANNEL "manu_cn"; START SLAVE FOR CHANNEL 'manu_br'; START SLAVE FOR CHANNEL 'manu_cn'; SHOW SLAVE STATUS FOR CHANNEL 'manu_br'\G SHOW SLAVE STATUS FOR CHANNEL 'manu_cn'\G

Avoid to configure and activate the channels on Prod M2 as well.

Testing back replication from manufacturing plants

Brazil on Man BR M1:

INSERT INTO manufacturing_log VALUES (1, 'Production data from Brazil', 'data');

China on Man CN M1:

INSERT INTO manufacturing_log VALUES (2, 'Production data from China', 'data');

For testing:

SELECT * FROM manufacturing_log;

Make sure you do not run into conflicts (Primary Key, AUTO_INCREMENTS). Make sure filtering is defined correctly!

To check the different channel states you can use the following command:

SHOW SLAVE STATUS\G or SELECT ras.channel_name, ras.service_state AS 'SQL_thread', ras.remaining_delay , CONCAT(user, '@', host, ':', port) AS user , rcs.service_state AS IO_thread, REPLACE(received_transaction_set, '\n', '') AS received_transaction_set FROM performance_schema.replication_applier_status AS ras JOIN performance_schema.replication_connection_configuration AS rcc ON rcc.channel_name = ras.channel_name JOIN performance_schema.replication_connection_status AS rcs ON ras.channel_name = rcs.channel_name ;
Troubleshooting Inject empty transaction

If you try to skip a transaction as you did earlier (SQL_SLAVE_SKIP_COUNTER) you will face some problems:

STOP SLAVE; ERROR 1858 (HY000): sql_slave_skip_counter can not be set when the server is running with @@GLOBAL.GTID_MODE = ON. Instead, for each transaction that you want to skip, generate an empty transaction with the same GTID as the transaction

To skip the next transaction you have find the ones applied so far:

SHOW SLAVE STATUS\G ... Executed_Gtid_Set: c3611091-f80e-11e4-99bc-28d2445cb2e9:1-20

then tell MySQL to skip this by injecting a new empty transaction:

SET SESSION GTID_NEXT='c3611091-f80e-11e4-99bc-28d2445cb2e9:21'; BEGIN; COMMIT; SET SESSION GTID_NEXT='AUTOMATIC'; SHOW SLAVE STATUS\G ... Executed_Gtid_Set: c3611091-f80e-11e4-99bc-28d2445cb2e9:1-21 START SLAVE;
Revert from GTID-based replication to file/position-based replication

If you want to fall-back from MySQL GTID-based replication to file/position-based replication this is quite simple:

CHANGE MASTER TO MASTER_AUTO_POSITION = 0;
MySQL Support and Engineering

If you need some help or support our MySQL support and engineering team is happy to help you.

Logging Galera Cluster conflicts

Shinguz - Sat, 2015-04-11 12:30
Taxonomy upgrade extras: logginggaleraclusterconflictdeadlockerror logerror

We typically suggest our customers to use our MySQL/Galera Cluster my.cnf configuration template to avoid MySQL configuration and performance problems.

And we are paranoid as well. Thus we enable all useful logging:

wsrep_log_conflicts = 1

But this has also some consequences of more visibility...

If you monitor carefully your Galera Cluster for example with the FromDual Performance Monitor for MySQL and MariaDB, you might probably see some strange values increasing from time to time:

mysql< SHOW GLOBAL STATUS LIKE 'wsrep_local_%r_s'; +---------------------------+-------+ | Variable_name | Value | +---------------------------+-------+ | wsrep_local_cert_failures | 42 | | wsrep_local_bf_aborts | 13 | +---------------------------+-------+

Those values are indicators that some transactions (Galera write sets) did to not succeed and were aborted by Galera. In this case the paranoid logging helps to find, what exactly was aborted and possibly helps to find out, if this can or should be fixed:

150410 1:44:18 [Note] WSREP: cluster conflict due to certification failure for threads: 150410 1:44:18 [Note] WSREP: Victim thread: THD: 151856, mode: local, state: executing, conflict: cert failure, seqno: 30399304 SQL: UPDATE login SET lTsexpire = UNIX_TIMESTAMP(NOW()) + lTimeout WHERE lSessionId = 'va3ta7besku82k56ncv3bnhlj5' *** Priority TRANSACTION: TRANSACTION 464359568, ACTIVE 0 sec starting index read mysql tables in use 1, locked 1 1 lock struct(s), heap size 360, 0 row lock(s) MySQL thread id 4, OS thread handle 0x7f1c0916c700, query id 8190690 Update_rows_log_event::find_row(30399302) *** Victim TRANSACTION: TRANSACTION 464359562, ACTIVE 0 sec mysql tables in use 1, locked 1 2 lock struct(s), heap size 360, 1 row lock(s), undo log entries 1 MySQL thread id 151856, OS thread handle 0x7f1c09091700, query id 8190614 172.20.100.11 sam_angiz query end UPDATE login SET lTsexpire = UNIX_TIMESTAMP(now()) + lTimeout WHERE lSessionId = 'va3ta7besku82k56ncv3bnhlj5' *** WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 835205 page no 3 n bits 72 index `PRIMARY` of table `fromdual`.`login` trx table locks 1 total table locks 2 trx id 464359562 lock_mode X locks rec but not gap lock hold time 0 wait time before grant 0 150410 1:44:18 [Note] WSREP: cluster conflict due to high priority abort for threads: 150410 1:44:18 [Note] WSREP: Winning thread: THD: 4, mode: applier, state: executing, conflict: no conflict, seqno: 30399302 SQL: (null) 150410 1:44:18 [Note] WSREP: Victim thread: THD: 151856, mode: local, state: committing, conflict: no conflict, seqno: -1 SQL: UPDATE login SET lTsexpire = UNIX_TIMESTAMP(now()) + lTimeout WHERE lSessionId = 'va3ta7besku82k56ncv3bnhlj5'

In the above Galera conflict 2 login transactions where running at the same time. They both come with the same Session ID and want to update the expiry timestamp. Now how to solve or fix this:

  • First check, if this table has a Primary Key (tables without a PK causes full table scans which can last for long time, increasing the chance for conflicts).
  • Second check, if there is a (UNIQUE?) index on lSessionId. A missing index leads to full table scans which increases the chance for conflicts.
  • Third check WHY 2 logins from the same Session ID can arrive at the same time (within 1 second) on 2 different Galera nodes (Ajax requests, etc...). Try to avoid such situations.

Galera Cluster last inactive check and VMware snapshots

Shinguz - Sat, 2015-04-11 11:46
Taxonomy upgrade extras: galeravmwaresnapshot

From time to time we see at Galera Cluster customer engagements the following, for me scary, warning in the MySQL error log:

[Warning] WSREP: last inactive check more than PT1.5S ago (PT7.06159S), skipping check

We mostly see this in VMware set-ups. Some further enquiry with the Galera developers did not give a satisfying answer:

This can be seen on bare metal as well - with poorly configured mysqld, O/S, or simply being overloaded. All it means is that this thread could not get CPU time for 7.1 seconds. You can imagine that access to resources in virtual machines is even harder (especially I/O) than on bare metal, so you will see this in virtual machines more often.

This is not a Galera specific issue (it just reports being stuck, other mysqld threads are equally stuck) so there is no configuration options for that. You simply must make sure that your system and mysqld are properly configured, that there is enough RAM (buffer pool not over provisioned), that there is swap, that there are proper I/O drivers installed on guest and so on.

Basically, Galera runs in virtual machines as well as well virtual machines approximates bare metal.

We were still suspecting that this is somehow VMware related. This week we had the chance to investigate... At 01:36 am node Galera2 lost connection to the Cluster and became NON-PRIMARY. This is basically a bad sign:

150401 1:36:15 [Warning] WSREP: last inactive check more than PT1.5S ago (PT5.08325S), skipping check 150401 1:36:15 [Note] WSREP: (09c6b2f2, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://192.168.42.2:4567 150401 1:36:16 [Note] WSREP: view(view_id(NON_PRIM,09c6b2f2,30) memb { 09c6b2f2,0 } joined { } left { } partitioned { ce6bf2e1,0 d1f9bee0,0 }) 150401 1:36:16 [Note] WSREP: view(view_id(NON_PRIM,09c6b2f2,31) memb { 09c6b2f2,0 } joined { } left { } partitioned { ce6bf2e1,0 d1f9bee0,0 }) 150401 1:36:16 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1 150401 1:36:16 [Note] WSREP: Flow-control interval: [16, 16] 150401 1:36:16 [Note] WSREP: Received NON-PRIMARY. 150401 1:36:16 [Note] WSREP: Shifting SYNCED -> OPEN (TO: 26304132) 150401 1:36:16 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1 150401 1:36:16 [Note] WSREP: Flow-control interval: [16, 16] 150401 1:36:16 [Note] WSREP: Received NON-PRIMARY. 150401 1:36:16 [Warning] WSREP: Send action {(nil), 328, TORDERED} returned -107 (Transport endpoint is not connected) 150401 1:36:16 [Note] WSREP: New cluster view: global state: dcca768c-b5ad-11e3-bbc0-fb576fb3c451:26304132, view# -1: non-Primary, number of nodes: 1, my index: 0, protocol version 3 150401 1:36:17 [Note] WSREP: (09c6b2f2, 'tcp://0.0.0.0:4567') reconnecting to d1f9bee0 (tcp://192.168.42.1:4567), attempt 0

I suspected, after some investigation with the FromDual Performance Monitor for MySQL and MariaDB, that the database backup (mysqldump) could be the reason. It was not. But the customer explained, that after the database backup they do a VMware snapshot.

And when we compared our problem with the backup log file:

2015/04/01 01:35:08 [3] backup.fromdual.com: Creating a snapshot of galera3 2015/04/01 01:35:16 [3] backup.fromdual.com: Created a snapshot of galera3 2015/04/01 01:35:23 [3] backup.fromdual.com: galera3: backup the changed blocks of disk 'Festplatte 1' using NBD transport 2015/04/01 01:36:10 [3] backup.fromdual.com: galera3: saving the Change Block Tracking's reference for disk 'Festplatte 1' 2015/04/01 01:36:10 [3] backup.fromdual.com: Removing Arkeia's snapshot of galera3

we can see that our problem pretty much started with the end of the WMware snapshot (01:36:10 + 5.08 = 1:36:15). By the way: For such kind of investigations it is always good to have a ntp daemon for time synchronization running. Otherwise problem investigation becomes much harder...

Some more and deeper investigation shows that we loose from time to time nodes during VMware snapshots (galera3). But they recover quickly because they can do an IST. In worst case we can loose 2 nodes and then the whole Galera Cluster has gone.

192.168.42.3 / node Galera3 2015-04-10 01:44:00 [3] backup.fromdual.com: Creating a snapshot of galera3 2015-04-10 01:44:08 [3] backup.fromdual.com: Created a snapshot of galera3 2015-04-10 01:44:15 [3] backup.fromdual.com: galera3: backup the changed blocks of disk 'Festplatte 1' using NBD transport 2015-04-10 01:45:39 [3] backup.fromdual.com: galera3: saving the Change Block Tracking's reference for disk 'Festplatte 1' 2015-04-10 01:45:39 [3] backup.fromdual.com: Removing Arkeia's snapshot of galera3
150410 1:44:07 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera1:4567 tcp://galera2:4567 150410 1:44:07 [Warning] WSREP: last inactive check more than PT1.5S ago (PT7.06159S), skipping check 150410 1:44:08 [Note] WSREP: Received NON-PRIMARY. 150410 1:44:10 [Note] WSREP: Shifting OPEN -> PRIMARY (TO: 30399299) 150410 1:44:11 [Warning] WSREP: Gap in state sequence. Need state transfer. 150410 1:44:11 [Note] WSREP: Prepared IST receiver, listening at: tcp://galera3:4568 150410 1:44:11 [Note] WSREP: Member 0.0 (galera3) requested state transfer from '*any*'. Selected 2.0 (galera2)(SYNCED) as donor. 150410 1:44:11 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 30399309) 150410 1:44:11 [Note] WSREP: Requesting state transfer: success, donor: 2 150410 1:44:11 [Note] WSREP: 2.0 (galera2): State transfer to 0.0 (galera3) complete. 150410 1:44:11 [Note] WSREP: Member 2.0 (galera2) synced with group. 150410 1:44:11 [Note] WSREP: Receiving IST: 8 writesets, seqnos 30399291-30399299 150410 1:44:11 [Note] WSREP: IST received: dcca768c-b5ad-11e3-bbc0-fb576fb3c451:30399299 150410 1:44:11 [Note] WSREP: 0.0 (galera3): State transfer from 2.0 (galera2) complete. 150410 1:44:11 [Note] WSREP: Shifting JOINER -> JOINED (TO: 30399309) 150410 1:44:11 [Note] WSREP: Member 0.0 (galera3) synced with group. 150410 1:44:11 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 30399309) 150410 1:44:11 [Note] WSREP: Synchronized with group, ready for connections 150410 1:44:13 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:45:42 [Warning] WSREP: last inactive check more than PT1.5S ago (PT2.47388S), skipping check 150410 1:45:43 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera1:4567 tcp://galera2:4567 150410 1:45:44 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') reconnecting to 54de92f8 (tcp://galera1:4567), attempt 0 150410 1:45:44 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') reconnecting to c9d964d3 (tcp://galera2:4567), attempt 0 150410 1:45:48 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:47:26 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera1:4567 150410 1:47:27 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') reconnecting to 54de92f8 (tcp://galera1:4567), attempt 0 150410 1:47:31 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting off
192.168.42.1 / node Galera1 2015-04-10 01:47:24 [3] backup.fromdual.com: Creating a snapshot of galera1 2015-04-10 01:47:29 [3] backup.fromdual.com: Created a snapshot of galera1 2015-04-10 01:47:40 [3] backup.fromdual.com: galera1: backup the changed blocks of disk 'Festplatte 1' using NBD transport 2015-04-10 01:48:43 [3] backup.fromdual.com: galera1: saving the Change Block Tracking's reference for disk 'Festplatte 1' 2015-04-10 01:48:44 [3] backup.fromdual.com: Removing Arkeia's snapshot of galera1 150410 1:44:02 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:44:04 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') reconnecting to 158f71de (tcp://galera3:4567), attempt 0 150410 1:44:12 [Note] WSREP: Member 0.0 (galera3) requested state transfer from '*any*'. Selected 2.0 (galera2)(SYNCED) as donor. 150410 1:45:43 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:45:44 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') reconnecting to 158f71de (tcp://galera3:4567), attempt 0 150410 1:45:48 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:47:27 [Warning] WSREP: last inactive check more than PT1.5S ago (PT3.66452S), skipping check 150410 1:47:27 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:47:30 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting off
192.168.42.2 / node Galera2 2015-04-10 02:09:55 [3] backup.fromdual.com: Creating a snapshot of galera2 2015-04-10 02:09:58 [3] backup.fromdual.com: Created a snapshot of galera2 2015-04-10 02:10:05 [3] backup.fromdual.com: galera2: backup the changed blocks of disk 'Festplatte 1' using NBD transport 2015-04-10 02:10:53 [3] backup.fromdual.com: galera2: saving the Change Block Tracking's reference for disk 'Festplatte 1' 2015-04-10 02:10:54 [3] backup.fromdual.com: Removing Arkeia's snapshot of galera2
150410 1:44:02 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:44:03 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') reconnecting to 158f71de (tcp://galera3:4567), attempt 0 150410 1:44:08 [Warning] WSREP: discarding established (time wait) 158f71de (tcp://192.168.42.3:4567) 150410 1:44:11 [Note] WSREP: Member 0.0 (galera3) requested state transfer from '*any*'. Selected 2.0 (galera2)(SYNCED) as donor. 150410 1:44:13 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:45:43 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:45:44 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') reconnecting to 158f71de (tcp://galera3:4567), attempt 0 150410 1:45:48 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:47:26 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera1:4567 150410 1:47:27 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') reconnecting to 54de92f8 (tcp://galera1:4567), attempt 0 150410 1:47:30 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 2:09:57 [Warning] WSREP: last inactive check more than PT1.5S ago (PT1.83618S), skipping check

The backups are done with the 2 options:

enabled.

Possibly this is the reason and one should disable those features in combination with Galera. Further investigation is going on. In worst case VMware snapshotting with Galera should be avoided.

Rename MySQL Partition

Shinguz - Fri, 2015-03-06 15:00
Taxonomy upgrade extras: partitionrenameDDL

Before I forget it and have to search again here a short note about how to rename a MySQL Partition:

My dream:

ALTER TABLE history RENAME PARTITION p2015_kw10 INTO p2015_kw09;
In reality: ALTER TABLE history REORGANIZE PARTITION p2015_kw10 INTO ( PARTITION p2015_kw09 VALUES LESS THAN (UNIX_TIMESTAMP('2015-03-02 00:00:00')) );

Caution: REORGANIZE PARTITION causes a full copy of the whole partition!

Hint: I assume it would be very easy for MySQL or MariaDB to make this DDL command an in-place operation...

MySQL Partitioning was introduced in MySQL 5.1.

Pages

Subscribe to MySQL, Galera Cluster and MariaDB support and services aggregator - MySQL Tech-Feed (en)