Recently Google announced, that the second generation of Cloud SQL left the beta state and it is available. I decided to take a look, because last time when I checked it, it looked good, but I couldn’t take it seriously because of the nonexistent SLA.
Earlier this week we had a discussion with fellow DBAs about our mysql prompts, and at the end of the day it showed up, that a lot of us hit the same problem.
The problem is, that when you set up your mysql prompt then ‘\h’ will be resolved to ‘localhost’ when you connect locally – instead the name of your host as you expect it. It always bugs me, and once I spent a good afternoon figuring out how to workaround this.
Well, the workaround is not a big deal, because you can insert any text into your mysql prompt, and after you realise that you can do it, then it is easy: just put the hostname into your prompt with your chosen provisioning tool and that will do.
For example in my puppet installations I use the following setting in the template file from I generate the /etc/my.cnf file:
prompt = "\u@<%= @fqdn %> (\h) [\d]> "
It says: “username@hostname (connected_host) [database_name]” which is really informative. Let me show you this on live servers!
[email@example.com /home/banyek]# mysql -s firstname.lastname@example.org (localhost) [(none)]> \q [email@example.com /home/banyek]# mysql -s -h db-dev.xyz.kinja-ops.com firstname.lastname@example.org (db-dev.xyz.kinja-ops.com) [(none)]> \q [email@example.com /home/banyek]#
You can see that looking at this prompt I am able to say that which username I used, which host I am running the mysql command, what server will I run my commands and in which database I am.
There is also one more thing I want to show you, and that is colorising!
This is not my idea, so here’s the link the superuser article where I’ve read about that, but the idea is simple, use the ANSI escape sequences to colorise your mysql prompt. This could not be done inside a ‘prompt’ setting, but you can to this as creating an alias and echo the whole mysql command line out – where you can use the terminal control sequences.
For example here is an alias which you could check out:
$ alias colormysql=$(echo -e 'mysql --prompt="\x1B[31m\\u\x1B[34m@\x1B[32m\\h\x1B[0m:\x1B[36m\\d>\x1B[0m "')
But I am not really sure if this is generally a good idea. What do you think about that?
Saturday I was in my favourite grocery store, standing in the line, browsing the net on my phone. I read Vadim Tkachenko‘s blog post about Measuring Percona Server Docker CPU/network overhead and his findings were the opposite than mine – he didn’t found any measurable difference. Reading his post, he did found huge impact in networking which I didn’t checked, so I was re-run my checks again, but now with paying attention for network configuration.
I won’t lingering this more: he’s correct, I was wrong. After I start to use the host’s network directly – the performance degradation went away.
Yay, for Vladim!
Back in October I have write about possible ways of running multiple MySQL instances on the same hardware. As the months passing by, the project of splitting our database schemas into standalone instances is closing in, so I started to check the different ways.
EDIT: This post is outdated, here is the follow up.
I am always fascinated about the cleanliness of UNIX . One tool only should do one thing, but it has to be the best in that way. The operating system itself will glue all the modules together and give you a complex feel of a system, you don’t have to take care of huge, bloated software, don’t have to deal with mysterious bugs, which are appearing random. Just small bricks of clever software, and the rest is on you.
With MySQL it is relatively easy to create point in time restores. All you need is a recent(ish) backup, and a bunch of saved binary logs. You can restore the backup you have, and when it is completed, you can use mysqlbinlog utility to apply your saved binary logs to the desired state of your database.
Currently we have one database cluster with 15 different schemas – these schemas could be either schemas which contain “real” data, or just schemas with metadata.
I guess the next evolutionary step of our database stack would be to split up the database cluster vertically along these schemas. All the data schemas should be moved to standalone mysql instances, and put the metadata schemas next to them. This also could be a good project for prepare to move a certain part of database for example to a cloud provider while other parts are still kept on bare metal.
Well, it was ended a week ago, but I had too many errands to run, so I couldn’t post anything about it.
It was really great, again.This was the third time I attended (2013 London, 2015 Santa Clara) so now I have met with a lot of familiar people – it is true that MySQL has a great community. The chosen city was great, Amsterdam is one of the coolest places of Europe, the hotel was neat, and the programs were also astounding.
(Originally posted in kinja ops blog)
Last time I was checked, how can TokuDB be used as a drop in replacement of InnoDB. The first impressions were jolly good; way less disk space usage, and the TokuDB host can be a part of the current replication cluster.
So far so good.