MySQL Replication is based on a master-slave architecture, where updates on the master are propagated to the slave through binary log events via a communication channel (aka a network connection). A slave would have been able to connect to only a single master at a time. If a slave wanted to receive updates from several masters, there were a few choices possible:

1. Time sharing replication, where a slave would connect to a master for a particular time slice.   (See, Mats blog here )
2. Have a hierarchical replication, where a slave that is to receive updates from the several masters is at the end of replication hierarchy. ( Like, M1->M2->M3->Slave)
3. Using several instances of mysqlbinlog + GTIDs. (See Luis blog   …

Yes, we've done it! ;-)

Tomas just announced we've reached 500K QPS performance level in OLTP_RO Point-Selects 8-tables benchmark, and I may only confirm it and say you little bit more:

This is the best-to-best comparison between the all listed engines obtained on the same 32cores-HT server that I've used in my previously published benchmark results. Same workload, same conditions, updated players. All details about this and other tests results I'll provide during my tomorrow's talk at MySQL Connect conference (11:30AM), and then later publish them within another blog post..

Well, what else to say.. - MySQL 5.7 is preparing to become the next …

Applications should be written taking into account that errors will eventually happen and, in particular, database application developers usually consider this while writing their applications.

Although the concepts required to write such applications are commonly taught in database courses and to some extent are widely spread, building a reliable and fault-tolerant database application is still not an easy task and hides some pitfalls that we intend to highlight in this post with a set of suggestions or tips.

In what follows, we consider that the execution flow in a database application is characterized by two distinct phases: connection and business logic. In the connection phase, the application connects to a database, sets up the environment and passes the control to the business logic phases. In this phase, it gets inputs from a source, which may be an operator, another application or a component within the same …

In this post, we are going to show how to develop fault-tolerant applications using MySQL Fabric, or simply Fabric, which is an approach to building high availability sharding solutions for MySQL and that has recently become available for download as a labs release (http://labs.mysql.com/). We are going to focus on Fabric's high availability aspects but to find out more on sharding readers may check out the following blog post:

•  http://vnwrites.blogspot.com/2013/09/mysqlfabric-sharding-introduction.html

Servers managed by Fabric are registered in a MySQL Server instance, called backing store, and are …

In MySQL we have the typical behaviour that we open and close connections very often and rapidly. So we have very short-living connections to the server. This can lead in extreme cases to the situation that the maximum number of TCP ports are exhausted.

The maximum number of TCP ports we can find with:

# cat /proc/sys/net/ipv4/ip_local_port_range
32768   61000

In this example we can have in maximum (61000 - 32768 = 28232) connections concurrently open.

When a TCP connections closes the port cannot be reused immediately afterwards because the Operating System has to wait for the duration of the TIME_WAIT interval (maximum segment lifetime, MSL). This we can see with the command:

# netstat -nat

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State
tcp        0      0 0.0.0.0:10050 …

The occurrence of failures and crashes can compromise the high availability of your database system affecting your revenue and reputation. Therefore, it is fundamental to minimize downtime and have an efficient strategy for crash recovery.

Replication and failover are commonly applied to deal with those situations. However, other types of failures can also affect the recovery process. In fact, the occurrence of unanticipated faults can really be an headache! Thus, it is better to be prepared and implement a good fault-tolerant failover strategy.

Performing failover is not trivial. It requires the execution of several steps in order to ensure data consistency (i.e., no data loss) -- especially if the "best" candidate to become the new master is not the most up-to-date.

Note that, one might desire that the slave with the best hardware should become the new master. In this case, the candidate must be …

Percona Server version 5.6.13-60.6

Percona is glad to announce the fourth Release Candidate of Percona Server 5.6.13-60.6 (downloads are available here and from the Percona Software Repositories).

Based on MySQL 5.6.13, including all the bug fixes in it, Percona Server 5.6.13-60.6 is the fourth RC release in the Percona Server 5.6 series. All of Percona‘s software is open-source and …

MySQL 5.7.2 features enhanced Multi-threaded slave which can be used to apply transactions in parallel even within a single database. Internal details of its working can be found in an earlier post. In this  post we will see how we can configure our replication slave to use this enhancement.
MySQL 5.7.2 has a new system variable  --slave-parallel-type which is dynamic. It can be set to the following values:

1. DATABASE  : (Default) Use the db partitioned MTS (1 worker per database)
2. LOGICAL_CLOCK:  Use logical clock based parallelization mode.

Apart from this the original option of --slave-parallel-workers=N is still valid and it sets that number of workers that we need to spawn. Also since the slave leverages the group of transactions that have …

IntroductionRe-applying binary logs generated from highly concurrent master on the slave has always been an area of focus. It is important for various reasons. First, in real-time systems, it becomes extremely important for the slave to keep up with the master. This can only be guaranteed if the slaves’ performance in reapplying the transactions from the binary log is similar (or at-least comparable) to that of master, which is accepting queries directly from multiple clients. Second, in synchronous replication scenarios, having a fast slaves, aids in reducing the response times as seen by the clients to the master. This can be made possible by applying transactions from the binary log in parallel. However if left uncontrolled, a simple round-robin multi-threaded applying will lead to inconsistency and the slave will no longer be the exact replica of the leader.
The infamous out of order commit problemThe Out of order execution of transaction …

Learn how Modernizing Medicine, an electronic medical records company, serves thousands of customers and leverages Continuent Tungsten to manage databases on Amazon AWS. Modernizing Medicine is as fast growing SaaS company, offering electronic medical records management solution for thousands of small and medium-sizes dermatology, ophthalmology, optometry, plastic surgery, cosmetic and