Mon, 2015-07-20 12:09guillaumelefranc

When MariaDB 10.0 was launched as GA in 2014 it introduced a major feature: Parallel Replication. Parallel Replication is a fantastic addition to the long list of new MariaDB features, along with Global Transaction IDs. However I don’t think like many people understand this feature very well and know how to leverage its potential to the fullest extent. This blog post will explain a few of the gotchas that you could need while setting up Parallel Replication.

1. Single-thread replication can be slower in MariaDB 10.x than in MariaDB 5.5

The addition of new features in a new branch often comes at a cost. If you have a huge replication workload then you may find out that MariaDB 10.x replication is somehow slower than its counterpart in MariaDB 5.5. Thankfully, that can be counterbalanced by setting up Parallel Replication and the benefits will be much bigger than the ones you’d have …

Introduction

With Galera you can construct database clusters where each node is located in a different physical or even geographical location. In this blog post we will show some of the benefits from having such a geo-distributed cluster and the specific Galera features that enable practical replication across WAN links.

Benefits From Geo-Distribution

Geo-distribution allows database to break out from the single data center, which opens a whole new approach to redundancy and performance.

Increased Redundancy

Having database nodes in various geographic locations increases redundancy considerably, so that a local power failure or network outage can not possibly affect all nodes in the cluster. Outages that affect multiple availability zones within a single facility are not unheard of, but Galera allows you to go beyond the availability zones and have a truly multi-datacenter database cluster.

…

Are your databases more costly than they need to be? If you’re not sure, this webinar will show you how to find out, quickly and easily, with KPIs that indicate overprovisioning or opportunity for driving more efficiency from your databases. If there is an opportunity to run your databases at lower cost, you’ll find out how to identify which of 5 key areas offer the biggest chances for improvement, and a specific action plan to get results fast.

If you did not have a chance to join the webinar, the slide deck is embedded below. You can also register for a recording here.

Both MySQL and MariaDB have been busy, each introducing new features, sometimes creating the same feature, often with different syntax.

This is sometimes good for users, who have a wide choice. And sometimes it is bad, as once you are used to the deployment and syntax of one flavor, it is hard to switch to a different one. This problem is enhanced if you are dealing with an application, MySQL Sandbox, that needs to work well with all flavors.

The latest releases of MySQL Sandbox (3.0.51 to 3.0.55) have been necessary to solve minor and major troublesome points with MySQL 5.7.8 and MariaDB 10.1.

The current version (3.0.55) can install all the newest releases, including replication with MySQL 5.7.8 which suffers from a compatibility bug (better explored in a separate article). …

The MySQL manual says

--socket=file_name, -S file_name ... On Unix, the name of the Unix socket file to use, for connections made using a named pipe to a local server.
The default Unix socket file name is /tmp/mysql.sock.

which might surprise folks who've had to contend with the error message
"Can't connect to local MySQL server through socket '[something-other-than-/tmp/mysql.sock]'".

I'll try to explain here why the name is often something quite different, how to know what the MySQL server is really listening for, what the fixes are for either users or application developers, and why it still matters.

Why the name is not always /tmp/mysql.sock

First, the Linux Foundation publishes a document "Filesystem Hierarchy Standard". Version 2.3 says …

Thanks for writing this. I have filed https://bugs.launchpad.net/percona-server/+bug/1475955 to improve ours docs as well.

[…] innodb_fast_checksum=1 and upgrading to MySQL 5.6 […]

Yet again, this log buffer edition brings some rich blog posts from Oracle, SQL Server and MySQL.

Oracle:

• Installing Oracle XE, ORDS and Apex on CentOS
• Major Growth is Expected in the DBaaS Space. Are Your Skills Ready?
• How to Hide Actions in OBPM 12c Workspace
• You can configure auto refresh for ADF BC cached LOV and this works out of the box, no special coding is needed.
• Search and …

Fri, 2015-07-17 07:47diptijoshi

In the last two releases of MariaDB Enterprise, we have provided enhanced performance with the introduction of certified MariaDB binaries for POWER8 and optimized binaries for the x86 platform. This Summer we make it more efficient and automated for developers and DBAs to use our high performance MariaDB binaries.

Ease of Use

MariaDB Enterprise now comes with Docker images as well as Chef recipes and cookbooks so developers can now easily deploy and run their database applications. Using Docker images from the MariaDB Enterprise repository,

• you …

As part of the release of MySQL-5.7.7, based on community feedback, improvements have been made with respect to replication defaults, which will make MySQL replication safer and easier to use.

This blog is intended to provide information about these default changes, and it briefly explains the advantages of having them.

1) Enable Simplified GTID recovery by default:

binlog_gtid_simple_recovery=TRUE by default.
https://dev.mysql.com/doc/refman/5.7/en/replication-options-gtids.html#sysvar_binlog_gtid_simple_recovery

This variable controls how binary log files are iterated during the search for GTIDs when MySQL starts or restarts.

Setting this option to TRUE gives improved recovery performance. Because of this option server startup and binary log purge …