I have been looking into “dolphie” lately, and have to say, “thanks Charles!”. I actually first saw dolphie via Lefred’s MySQL Belgian Days and installed it just after looking into the slidedeck. But never got around to looking further… until now.

We can use so many different observability (o11y?) tools to get notifications, alerts, react, generate reports, etc. from so many different companies, using agents, proxies, repositories, and so on and so forth. And after exchanging experiences with dolphie’s author himself, Charles, the idea here is to go that little bit further in …

Blip is a new MySQL monitor that collects and reports server metrics. But wasn’t this problem solved long ago? Not really…

Overview The Skinny

Tungsten Clustering provides high availability, disaster recovery, and a host of other benefits for MySQL / MariaDB / Percona Server databases. In this blog post we will explore some of the shell aliases I use every day to administer various Tungsten Clusters.

Shell Aliases: A Quick Review Quick and Easy

A shell alias is simply a way to create a shortcut for frequently-used command sequences.

For example, I like to shorten the command clear to cls, i.e.

shell> alias cls=clear
shell> cls

If you create an alias on the fly it will be lost when the shell exits.

To save aliases so they are available to all shell sessions, update your shell’s profile or rc script.

For example, add the below line to the bottom of …

The Question Recently, a customer asked us:

Where are the logs for a Tungsten Cluster and which are the proper log files to monitor if I do a master role switch to another node?

The Answer: Part I Both basic and advanced logs are available!

The basic logs are symbolic links into the log subdirectory for each layer of the cluster.

For example, this is the listing of the default log directory, /opt/continuent/service_logs:

connector-user.log -> /opt/continuent/tungsten/tungsten-connector/log/connector-user.log
manager-user.log -> /opt/continuent/tungsten/tungsten-manager/log/manager-user.log
mysqldump.log -> /opt/continuent/tungsten/tungsten-replicator/log/mysqldump.log
replicator-user.log -> /opt/continuent/tungsten/tungsten-replicator/log/replicator-user.log
xtrabackup.log -> /opt/continuent/tungsten/tungsten-replicator/log/xtrabackup.log

As you can see, each log file is a …

Amazon Web Services (AWS) is a cloud platform that offers a wide variety of services including computing power, database storage, content delivery and other functionality that targets businesses of all sizes. One of their database solutions includes the Amazon Relational Database Service. Amazon RDS includes a number of popular RDBMSes, including Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, and Microsoft SQL Server, as well as tools to manage your databases and monitor their performance.

Despite the wide range of metrics available within the Amazon RDS console, there are some very good reasons for using your own monitoring tool(s) instead or in addition to those offered by Amazon RDS. For example, familiarity with your own tool(s) or access to features that Amazon RDS does not provide would constitute two persuasive reasons for employing a local tool.

With traditional software monitoring platforms such as Monyog still enjoying …

In this post, we’ll address how MaxScale monitors servers. We saw in the

We saw in the previous post how we could deal with high availability (HA) and read-write split using MaxScale.

If you remember from the previous post, we used this section to monitor replication:

[Replication Monitor]
type=monitor
module=mysqlmon
servers=percona1, percona2, percona3
user=maxscale
passwd=264D375EC77998F13F4D0EC739AABAD4
monitor_interval=1000
script=/usr/local/bin/failover.sh
events=master_down

But what are we monitoring? We are monitoring the assignment of master and slave roles inside MaxScale according to the actual replication tree in the cluster using the …

I gave two monitoring related talks at OpenWorld, thanks to all that came along!

Both were monitoring related, the first an introduction to MySQL Enterprise Monitor, and the second a look at some of the new instrumentation that is getting developed, primarily within the MySQL 5.6 release. 

If you'd like to get a quick overview of how MySQL Enterprise Monitor works, then take a look through the "Getting to Know MySQL Enterprise Monitor" talk. This gives you a high level view of how the different pieces fit together, and then each of the important factors within the user interface:

Getting to Know MySQL Enterprise Monitor

And if you are interested in seeing how the instrumentation and monitoring landscape will look when 5.6 hits the streets, then you can get a sneak peak at the …

I gave two monitoring related talks at OpenWorld, thanks to all that came along!

Both were monitoring related, the first an introduction to MySQL Enterprise Monitor, and the second a look at some of the new instrumentation that is getting developed, primarily within the MySQL 5.6 release. 

If you'd like to get a quick overview of how MySQL Enterprise Monitor works, then take a look through the "Getting to Know MySQL Enterprise Monitor" talk. This gives you a high level view of how the different pieces fit together, and then each of the important factors within the user interface:

Getting to Know MySQL Enterprise Monitor

And if you are interested in seeing how the instrumentation and monitoring landscape will look when 5.6 hits the streets, then you can get a sneak peak at the …

I have released SQLStats 1.3 now, and it is available for download from sourceforge. The changes are small:

• Cleaned up the build script a bit.
• Fixed a bug that caused statements to be counted twice.
• Made statement comparison non case sensitive.
• A small fix to the normalizer, that would miss a few statements in some cases.

SQLStats is a plugin for MySQL 5.5 and up that allows live monitoring of SQL statements, without using the general query log and with the added benefit of managing statements with the literals removed. read more in my previous blog-post in the subject.

Enjoy!
/Karlsson

I was recently struck by a problem which is unusual. In order to keep an eye on the database server I use nagios, cacti, merlin and some local scripts to monitor the database instance and ensure that it is working properly.  That normally works fine.  The different monitor processes do various things, one of which is to monitor the replication status of a slave, and warn me if the replication is not working or if it’s behind. This is done with the command SHOW SLAVE STATUS.

The server I was looking at runs some large local batch jobs aggregating data. Unfortunately, I was experiencing that replication was interfering with these batch jobs so decided to see if things would perform better if I stopped replication and let the batch …