I wanted to share a recent issue with stock Ruby on Centos6.

We run a Rails application that connects to a MySQL datastore. We're in a datacenter transformation and we deployed the application to our new datacenter though the MySQL datastore is at the other datacenter. As you can see there is about a 35ms distance between the application and the MySQL instance.



[root@host]# ping 172.x.y.19
PING 172.x.y.19 (172.x.y.19) 56(84) bytes of data.
64 bytes from 172.x.y.19: icmp_seq=1 ttl=253 time=32.6 ms
64 bytes from 172.x.y.19: icmp_seq=2 ttl=253 time=38.1 ms
64 bytes from 172.x.y.19: icmp_seq=3 ttl=253 time=36.0 ms
^C
--- 172.x.y.19 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2751ms
rtt min/avg/max/mdev = 32.656/35.600/38.101/2.250 ms


We started the Rails application up though it just was not …

In one of my previous posts, “How to resize InnoDB logs?”, I gave the advice on how to safely change the size of transaction logs. This time, I will explain why doing it may become necessary.

A brief introduction to InnoDB transaction logs

The transaction logs handle REDO logging, which means they keep the record of all recent modifications performed by queries in any InnoDB table. But they are a lot more than just an archive of transactions. The logs play important part in the process of handling writes. When a transaction commits, InnoDB synchronously makes a note of any changes into the log, while updating the actual table files happens asynchronously and may take place much later. Each log entry is assigned a Log Sequence Number – an incremental value that always uniquely identifies a change.

…

The objective of this benchmark is to measure the performance improvement achieved when enabling the Multi-Threaded Slave enhancement delivered as a part MySQL 5.6.

As the results demonstrate, Multi-Threaded Slaves delivers 5x higher replication performance based on a configuration with 10 databases/schemas. For real-world deployments, higher replication performance directly translates to:

· Improved consistency of reads from slaves (i.e. reduced risk of reading "stale" data)

· Reduced risk of data loss should the master fail before replicating all events in its binary log (binlog)

The multi-threaded slave splits processing between worker threads based on schema, allowing updates to be applied in parallel, rather than sequentially. This delivers benefits to those workloads that isolate application …

Microblogging site reveals some of the enhancements it's made to the database technology it uses to store user-generated data.

It’s been a long time coming, but we’ve just published our Twitter-internal MySQL development branch onto GitHub. The initial publication and announcement isn’t meant to be groundbreaking—we’re setting up some groundwork to be able to collaborate publicly. It comes with an initial set of changes we’ve made to support our production workloads and make DBAs lives easier, which you can read about in the README.

MySQL became wildly successful in part because it had built-in, simple replication. Sure, it had lots of interesting failure scenarios and was not great at first — it is much better these days — but it was nevertheless successful because there was a single, out-of-the-box, not-very-complex way to do replication. I have opined many times before that this was one of the killer features missing from PostgreSQL. I think that can large explain why MySQL became more popular more quickly.

The new killer feature is automatic sharding, in my opinion. If you’re not accustomed to the word, “sharding” means partitioning of a large dataset across many servers.

It is easy to poke fun at MongoDB’s current limitations, but for all that, it has a story to tell about sharding. There is One Right Way To Do It in MongoDB, and it’s a part of the product.

I don’t see sharding …

Oracle has released another huge batch of improvements to MySQL slated for MySQL 5.6. The pace of innovation in MySQL is accelerating rapidly and the improvements are impressive. I have not read all of the blog posts thoroughly yet, but I’ve skimmed and it looks fantastic. The link posted above is ONE of the sets of improvements: there are also a bunch of other posts about new improvements to the query optimizer, InnoDB, and probably more.

We have spent months planning and preparing for the MySQL conference that begins tomorrow. It seems appropriate to reflect on this process, where the open source and business communities are now, and what we have planned for the future.

The annual April MySQL conference was a strong and growing event for years, drawing hundreds of people at its peak. The conference has always been vital not only to MySQL and those who care about MySQL, but also to the many companies that use and enhance MySQL, and that contribute far more to MySQL than might be apparent. But after the acquisitions by Sun and Oracle, O’Reilly found it more difficult to promote the conference. When it became clear that Oracle wouldn’t change their mind about not supporting the event, O’Reilly did not announce a 2012 event.

That’s where Percona stepped in. We were not willing to let the conference die. Others talked about doing something, but Percona took the …

Hi Everyone!

Just a reminder to all of those who are attending the MySQL Conference in Santa Clara this week that I'll be presenting a session all about XtraBackup Manager.

My session will be entitled "Introducing XtraBackup Manager" and happens on 11 April 15:30-16:20 @ Ballroom D.

If you are interested in learning more about XtraBackup Manager, or would just like to come support me - I look forward to seeing you there!

Cheers,
Lachlan

If you have a Java-based product and are, or are thinking of, using MySQL as an embedded database, this webinar is for you. This is a great webinar for OEM/Embedded customers/prospects (particularly, if they develop in Java)!

Mark Matthews is not only the creator and maintainer of MySQL’s JDBC connector (MySQL Connector/J); as an architect on the MySQL Enterprise Tools Team, he is also an OEM user of MySQL and Connector/J. The Java-based MySQL Enterprise Monitor has used MySQL as its embedded repository for the past nearly 8 years.

Most users of MySQL Enterprise Monitor have no idea that it embeds a MySQL database. Like most OEM customers, the MySQL Enterprise Monitor team (and Oracle MySQL) wants its embedded database to perform optimally every time and at all times – without requiring any end-user intervention.

Join this …