VividCortex is thrilled to announce the latest in personalizing your database monitoring experience. System stall? On the go? Look no further than directly in front of your face. Our Google Glass app allows you to see unprecedented query detail even when away from your computer. Save precious seconds as you interactively scroll through features to solve your database problems while in the store, out for coffee or home for dinner.

To explore additional features and see what VividCortex can do for you, start your free trial today!

Few months ago, when MySQL Engineering Team moved MySQL Server sources to GitHub I found it would be waste of time to manually copy all scripts which I use to regularly and automatically build and test all versions, needed for verifying bug reports. I run these scripts on 3 machines at least. So I started my own GitHub project, called mysql-scripts

Now this project contains four scripts. First one is build.sh which  I use for building. By default it checks out MySQL Server sources, builds them in directory $HOME/src/mysql-VERSION, then installs to $HOME/build/mysql-VERSION But all configuration is settable. For example, now I regularly build Percona Server with single command `build.sh -g …

The mysql> command-line prompt is iconic, shown in countless documentation pages, forum posts, tutorials and manuals. It’s immediately identifiable – one look, and you immediately know the context in which commands are being executed. So it’s only with good reason that we would consider changing the prompt value to something else, and Daniël van Eeden provided a compelling suggestion to modify this to provide user, host and database context. Because the mysql prompt is user-configurable, this is easy to do dynamically:

mysql> prompt something>
PROMPT set to 'something> '
something> select 1;
+---+
| 1 |
+---+
| 1 |
+---+
1 row in set (0.00 sec)

something>

Using the special character …

Itchy Ninja Software is pleased to announce the release of Analyst for MySQL v1.1. Revolutionize the way you work and administrate MySQL, MariaDB, Galera, and Percona XtraDB installations.

Make More Efficient Use of Your Time

Gathering all of the metrics to diagnose a database installation is a very time consuming process, and many simply do not have the experience to know where to begin. With Analyst for MySQL, you will be able to get your hands on hundreds of metrics within moments. It really takes all of the guesswork, as well as tedious long sessions of writing queries out of managing a MySQL database server.

Cross-Platform

Not only can you run the program on Windows, Mac, or Linux, you can also generate server reports from each of those platforms as well! No need to install anything on the server at any time. All diagnostics are run from your laptop or desktop machine. The …

Podcasts Performance Server Tuning

In this episode we discuss sharding and high availability with MySQL Fabric, including installation and configuration. Ear Candy is rolling out GTIDs with no restarting, and At the Movies is putting MySQL Fabric to use, including a live demo.

Podcasts Performance Server Tuning

In this episode we discuss sharding and high availability with MySQL Fabric, including installation and configuration. Ear Candy is rolling out GTIDs with no restarting, and At the Movies is putting MySQL Fabric to use, including a live demo.

http://blog.booking.com/evaluating_mysql_parallel_replication_2-slave_group_commit.html

Follow the link above to read my latest article on the Booking.com developer blog.  It is about MySQL Parallel Replication and a very nice side effect of the MariaDB implementation: Slave Group Commit.

This is also a good opportunity to remind you that I will speak at Percona Live Santa Clara 2015 about 

I wrote a guest post for High Scalability about how we scale our backend systems at VividCortex. It’s heavy on MySQL, sprinkled with a little bit of Redis’s magic pixie dust, and Kafka is also a key part of the architecture.

Important takeaways:

• Our workload is unusual in that some use cases require reading huge amounts of data with interactive response times. We have lots of time-series data, but not a typical time-series workload.
• Our data distribution is also weird.
• Read optimization is vital, but we are extremely write-heavy.
• We’re sharded and partitioned.
• We run our systems on just a few low-end EC2 machines.
• Go is a huge part of our speed to market and cost efficiency.
• We use a “just enough micro-” …

I wrote a guest post for High Scalability about how we scale our backend systems at VividCortex. It’s heavy on MySQL, sprinkled with a little bit of Redis’s magic pixie dust, and Kafka is also a key part of the architecture.

Important takeaways:

• Our workload is unusual in that some use cases require reading huge amounts of data with interactive response times. We have lots of time-series data, but not a typical time-series workload.
• Our data distribution is also weird.
• Read optimization is vital, but we are extremely write-heavy.
• We’re sharded and partitioned.
• We run our systems on just a few low-end EC2 machines.
• Go is a huge part of our speed to market and cost efficiency.
• We use a “just enough micro-” …

I wrote a guest post for High Scalability about how we scale our backend systems at VividCortex. It’s heavy on MySQL, sprinkled with a little bit of Redis’s magic pixie dust, and Kafka is also a key part of the architecture.