Month: January 2016

Tuning Integrated Replicat performance using EAGER_SIZE parameter

Is Oracle GoldenGate really designed for batch processing or “large” transactions? – not sure what the official Oracle take on this is but I would hazard a guess and say maybe no. Maybe that is something better suited to an ETL type of product like Oracle Data Integrator. Goldengate considers a transaction to be large […]

FromDual.en: MySQL Environment MyEnv 1.3.0 has been released

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

Upgrade from 1.1.x or higher to 1.3.0

# cd ${HOME}/product
# tar xf /download/myenv-1.3.0.tar.gz
# rm -f myenv
# ln -s myenv-1.3.0 myenvIf 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.0


NDB Cluster stuff was removed and cleaned-up.
my.cnf template was slightly adapted to new requirements (query_cache_size, innodb_buffer_pool_instances, binlog_stmt_cache_size, wsrep_sst_method and wsrep_sst_auth).
Cgroups stuff was fixed and made more verbose in case of configuration errors.
Cgroups template (tpl/cgroups.conf) was extended.
Some warnings made more clear.
Too verbose error message in case of missing my.cnf was redirected to debug logging.
MyEnv Installer

Preparation work for Mac OSX was done.
Installation deletion can be automatized now.
Installer made ready for 5.7
Tags angel and default are not attached to each section any more.
Schema sys was added to hideschema variable
MyEnv Utilities

Script host tag added.
ORDER BY added to GROUP BY (in query_bench.php) to make it working the same in the future.
rc bug fixed in
For subscriptions of commercial use of MyEnv please get in contact with us.Taxonomy upgrade extras: myenvoperationMySQL Operationsmulti instanceconsolidationtestingupgradereleasecloudcgroupscontainer

Why log_slave_updates is a bad default

In a recent post the MySQL product managers asked the community for feedback about proposed new defaults. One of the proposals is to make log-slave-updates on by default.There are other important options that require some debate. They all look reasonable to me. This one, instead, which implies funnelling the replication events in a slave to its binary log, is questionable.Let’s start for the reason why it is a good idea. The scenario in which it makes sense is when you want a slave to be a master of one or more slaves. This is a common scenario in many cases where you need to support many servers in production. It is not, however always useful. I would like to show, here, a few cases when log-slaves-update is a problem rather than a solution.Regular Master/Slave deploymentsI would say that this case, rather than the hierarchical topology, is the most common situation. When you have a master/slave topology, you want the slave to be ready to replace the master, and for this you don’t need log-slave-updates. Also the manual recommends having a slave without log-slave-updates when your goal is to switch roles after a failover.When using multi-source replicationIn multi-source replication, you can have more than one topology. Unlike the ancient circular replication, which was the only way of implementing multi source replication prior to MySQL 5.7, and has proven to be inefficient, the new methods for multi source don’t need to enable log-slave-update, unless you are using complex and hybrid topologies like a star or a composite topology. Having used and tested such methods with MySQL and Tungsten replication for years, I can tell confidently that having a direct node-to-node replication stream is always preferable to using an intermediate node: there is better performance, less risk of data muddling, more certainty about the data origin.Whenever you need performance in the slaveIf we are not dealing with a hierarchical topology, having log-slave-updates means that the slave has a penalty performance for no good reason. Suggesting a better improvement than the intended defaultRather than making log-slave-update the default, what I would like to see in the next MySQL version is a mechanism for log servers, i.e. an intermediate node that receives binary logs from a master and serves them to the slaves without need of applying anything. If hierarchical topologies are so important, this should be the way to go, rather than stretching an obsolete technology beyond its capabilities.

EXPLAIN FORMAT=JSON knows everything about UNIONs: union_result and query_specifications

EXPLAIN FORMAT=JSONReady for another post in the EXPLAIN FORMAT=JSON is Cool series! Great! This post will discuss how to see all the information that is contained in optimized queries with [crayon-56ba3734c92fb880375816-i/] using the [crayon-56ba3734c9315535552544-i/] and [crayon-56ba3734c9321300328237-i/] commands.   When …

MariaDB 10.1.11 now available

The MariaDB project is pleased to announce the immediate availability of MariaDB 10.1.11. See the release notes and changelog for details on this release. Download MariaDB 10.1.11 Release Notes Changelog What is MariaDB 10.1? MariaDB APT and YUM Repository Configuration Generator Thanks, and enjoy MariaDB!
The post MariaDB 10.1.11 now available appeared first on

Percona XtraDB Cluster 5.6.28-25.14 is now available

Percona is glad to announce the new release of Percona XtraDB Cluster 5.6 on January 29, 2016. Binaries are available from the downloads area or from our software repositories.
Percona XtraDB Cluster 5.6.28-25.14 is now the current release, based on the following:

Percona Server 5.6.28-76.1
Galera Replicator 3.14
Codership wsrep API 25.13

All of Percona software is open-source and free, and all the details of the release can be found in the 5.6.28-25.14 milestone at Launchpad.
For more information about relevant Codership releases, see this announcement.
Bugs Fixed:

1494399: Fixed issue caused by replication of events on certain system tables (for example, mysql.slave_master_info, mysql.slave_relay_log_info). Replication in the Galera eco-system is now avoided when bin-logging is disabled for said tables.
NOTE: As part of this fix, when bin-logging is enabled, replication in the Galera eco-system will happen only if BINLOG_FORMAT is set to either ROW or STATEMENT. The recommended format is ROW, while STATEMENT is required only for the pt-table-checksum tool to operate correctly. If BINLOG_FORMAT is set to MIXED, replication of events in the Galera eco-system tables will not happen even with bin-logging enabled for those tables.
1522385: Fixed GTID holes caused by skipped replication. A slave might ignore an event replicated from master, if the same event has already been executed on the slave. Such events are now propagated in the form of special GTID events to maintain consistency.
1532857: The installer now creates a /var/lib/galera/ directory (assigned to user nobody), which can be used by garbd in the event it is started from a directory that garbd cannot write to.

Known Issues:

1531842: Two instances of garbd cannot be started from the same working directory. This happens because each instance creates a state file (gvwstate.dat) in the current working directory by default. Although garbd is configured to use the base_dir variable, it was not registered due to a bug. Until garbd is fixed, you should start each instance from a separate working directory.

Help us improve our software quality by reporting any bugs you encounter using our bug tracking system. As always, thanks for your continued support of Percona!

TEL/電話+86 13764045638
QQ 47079569