We know you are busy, and checking the VividCortex interface is not always on the top of your priority list. That’s why we implemented our proactive reporting feature.

Each day, your team will receive a recap of the top ten queries of each environment from the day prior. You can see at a glance whether systems were running smoothly or if you need to look into performance.

If daily reports are creating too much noise, you can subscribe to weekly reports instead. These will show the top ten queries of each environment from the week prior.

Of course, if you do not wish to receive the reports, simply unsubscribe.

This is the first of many proactive features to bring database monitoring to everyone on your team. Stay tuned for more, and sign up for a free trial if you are interested in a monitoring solution that …

There are plenty of storage engines out there, but none of them seem to offer fast and efficient time series storage and indexing. The existing options like RRDtool and Whisper aren’t very fast, and the fast options like LevelDB aren’t specifically made for time series and can lead to harsh operational issues. Instead of hacking on something like LevelDB to suit his needs, Preetam Jinka, one of the team’s brainiacs, decided to write his own storage engine.

Join us Tuesday, June 2nd at 2 PM EST (6 PM GMT), as Preetam Jinka covers the unique characteristics of time series data, time series indexing, and the basics of log-structured merge (LSM) trees and B-trees. After establishing some basic concepts, he will explain how Catena’s design is inspired by many of the existing systems today and why it works much better than its present alternatives.

Designing a storage engine is the easy part. Implementation is …

Introduction

Systemd is a management and configuration platform available in all major Linux distributions. It provides infrastructure for service start, stop, restart and several other novel functionalities to manage services. Systemd replaces SysV and upstart initialization systems and is the default init system in most modern Linux distributions including Red Hat Enterprise Linux, Oracle Linux, Debian, Ubuntu, Fedora, SLES and openSUSE.

Preliminary support for systemd was introduced in earlier versions of MySQL. However, it had the following limitations and disadvantages:

1. Use of ping tricks to check whether mysqld is ready to serve client connections.
2. Though systemd had superior process control for automatic restarts, mysqld_safe was still used to identify abnormal mysqld termination and do automatic restarts.
…

This tutorial shows how to prepare a Debian Jessie server (with Apache2, BIND, Dovecot) for the installation of ISPConfig 3 and how to install ISPConfig 3. The webhosting control panel ISPConfig 3 allows you to configure the following services through a web browser: Apache web server, Postfix mail server, Dovecot IMAP/POP3 server, MySQL, BIND nameserver, PureFTPd, SpamAssassin, ClamAV, and many more.

This post will answer how to extract database, tables etc from mysqldumpsplitter utility.

The post How-to extract from mysqldump | mysql-dump-splitter recipes first appeared on Change Is Inevitable.

I often talk with people who are very interested in the features of Percona XtraDB Cluster (PXC) such as synchronous and parallel replication, multi-node writing and high availability. However some get confused when operating a real PXC cluster because they do not fully realize the implications of these features. So here is a fun way to test your PXC knowledge: try to solve these 12 questions related to PXC! (you will find the answers at the end of the post.)

Workload

1. With Galera 3.x, support for MyISAM is experimental. When can we expect to have full MyISAM support?
a. This will never happen as Galera is designed for transactional storage engines.
b. This is planned for Galera 4.0.

2. Why aren’t all workloads a good fit for PXC?
a. Execution plans can change compared to a regular MySQL server, so performance is sometimes not as good as with a regular MySQL server.
b. Large …

The mantra of the day is – performance, performance, performance! It is clear that everything needs to be totally available all of the time, function at the fastest speeds and performance as close to perfect as is possible. In all the business discussions swirling around us we hear the words; application performance, website performance, transaction performance, server performance and on and on in regards to virtually everything digital that we live and breath with. Performance is no longer just one of the items we need to be paying attention to, it is THE item we need to be critically aware of every minute of every day! No longer are the words “it’s good enough” acceptable. The impacts to business can be catastrophic if the digital performance of your business is not at the highest levels. So the question we are all challenged with is how can we be sure that the performance levels we need are actually what we are …

So, on a large IBM POWER8 system I was recently running the newly coined “yesmark” benchmark, which is best translated as this:

Benchmark (N for concurrency): for i in {1..N}; do yes "DO 0;" | mysql > /dev/null & done
Live results: mysqladmin -ri 1 extended-status | grep Questions

Which sounds all fun until you realize that it’s *amazingly* close in results to a sysbench point select benchmark these days (well, with MySQL 5.7.7).

Since yesmark doesn’t use InnoDB though, MariaDB is back in the game.

I don’t think it matters between MariaDB and MySQL at this point for yesbench. With MySQL in a KVM guest on a shared 2 socket POWER8 I could get 754kQPS and on a larger system, I could get 1.3 million / sec.

1.3 Million queries / sec is probably the highest number anybody has ever seen out of MySQL or MariaDB, so …

At VividCortex, the algorithm our agents use to digest queries needs to be fast and reliable. Accurately digesting queries into logical groups is important to providing a useful view of data in the UI - digest too few or too many and it becomes difficult to understand what the Top-Queries view is showing.

Though our algorithm is sophisticated, one of our PostgreSQL clients experienced an issue with query digestion. They had many queries of the form “select a,b,c from table where c = any(values (1), (2), (3)…)” which were not being collapsed correctly.

We recently improved our digest code to correctly digest queries of this form.

In both MySQL and PostgreSQL, “SELECT * FROM t WHERE a IN (SELECT aa FROM tt)” was incorrectly collapsed to SELECT * FROM t WHERE a IN (?). Now, the digest is the lowercased original query text, as there is nothing to collapse or conceal.

These are improvements that help our …

TEXT fields are a nightmare. For you and for your server. It is slow to retrieve, and if you are doing searches on it, be prepared, things are going to get bumpy.

If you use MySQL with a MyISAM engine, this may not be an issue for you, you can create a FULLTEXT index, your only problem is if you want to add a new column, an alter table can take forever, since MySQL creates a new table and copies the old data to the new table. For those who uses MySQL with an InnoDB engine, prepare because, you’ll have more issues. Indexes can’t be FULLTEXT and if you do need an index you must inform the length of it. It defeats the purpose of you doing the search in that field.

The observation above is only true for MySQL 5.5 or below, since version 5.6 MySQL does support FULLTEXT indexes on InnoDB – thanks Davey …