This blog gives some background to the decisions made when designing the
storage engine NDB Cluster used in MySQL Cluster around how to support
real-time requirements (or as I sometime refer to it, predictable response
time requirements).

Requirement analysisWhen analysing the requirements for NDB Cluster based on its usage in telecom
databases two things were important. The first requirement is that we need to
be able to respond to queries within a few milliseconds (today even down to
tens of microseconds). The second requirement is that we need to do this while
at the same time supporting a mix of simple traffic queries combined with a
number of more complex queries running at the same time.

The first requirement was the main requirement that led to NDB Cluster using a
main memory storage model with durability on disk using a REDO log and
various …

This is a description of the simplest case of 2-phase commit (2PC) in NDBCluster: one transaction, containing a single insert, update or delete operation on a single row. The PREPARE phase of the 2PC is initiated by the API node (which is a mysqld or a NoSQL client) sending a TCKEYREQ to the Transaction Coordinator of a data node.…

We regularly get questions about how to set up a Galera cluster with just 2 nodes. The documentation clearly states you should have at least 3 Galera nodes to avoid network partitioning. But there are some valid reasons for considering a 2 node deployment, e.g., if you want achieve database high availability but have limited budget to spend on a third database node. Or perhaps you are running Galera in a development/sandbox environment and prefer a minimal setup.

Galera implements a quorum-based algorithm to select a primary component through which it enforces consistency. The primary component needs to have a majority of votes, so in a 2 node system, there would be no majority resulting in split brain. Fortunately, it is possible to add a …

In this blog, we’ll discuss changing the tablespace directory using pt-online-schema-change.

One of the most annoying situations in the life of a DBA is realizing that the disk where the datadir resides is running out of space. If you’re lucky enough to run over an LVM volume or a RAID (depending on the level, though), it is easy to add disk space. But what if you are not that lucky, and your datadir is running on a single disk? Not so funny!

That is the exact situation we recently faced with a customer, for both the master and slave server. When trying to figure out a solution we saw that:

• There was enough space on a different partition within the same server.
• The tables have their own tablespace (innodb_file_per_table = on)
• The MySQL version was …

This release fixes a rare crash as well as a regression bug introduced in 12.3.0.

Changes as compared to SQLyog MySQL GUI 12.3.0 include:

Bug Fixes:

* 12.3.0 introduced a slowness when displaying the saved connections list with a large no. (100+) of saved connections. This is fixed now.
* Fixed a rare crash occurring sometimes when typing in the editor inside an invalid query longer than 128 characters. Auto-complete was at fault.

Downloads: https://www.webyog.com/product/downloads
Purchase: https://www.webyog.com/shop

The post SQLyog MySQL GUI 12.3.1 Released …

Ok, maybe evil is too strong a word, but MySQL can certainly be deceiving.

Ok, maybe evil is too strong a word, but MySQL can certainly be deceiving.

Ok, maybe evil is too strong a word, but MySQL can certainly be deceiving.

In this post, I’ll discuss how to moving VIPs during a failover using Orchestrator.

In our previous post, we showed you how Orchestrator works. In this post, I am going to give you a proof-of-concept on how Orchestrator can move VIPs in case of failover. For this post, I’m assuming the Orchestrator is already installed and able to manage the topology.

Hooks

Orchestrator is a topology manager. Nothing less nothing more. In the case of failover, it will reorganize the topology, promote a new master and connect the slaves to it. But it won’t do any DNS changes, and it won’t move VIPs (or anything else).

However, Orchestrator supports hooks. Hooks are external scripts …

As many of you will know, MySQL Replication has become an instrumental part of scale-out architectures in LAMP environments. MySQL offers plenty of solutions when there is a need to scale out, the most common being to add read replicas. The major bottleneck for our data is generally not so much oriented around writing our data but more around reading it back. Therefore the easiest way to scale MySQL is to add replicas for reading.

We’ve produced a number of resources during the course of this year aimed at helping users to get started with MySQL Replication and/or get more out of their existing setups.

We’ve summarised these resources here in a handy overview, so that you can pick and chose the ones that might be the most relevant to you.

Do check them out and let us know your feedback!

The White Papers The MySQL© Replication Blueprint by Severalnines

This is a great resource for anyone wanting to …