Recently Google announced, that the second generation of Cloud SQL left the beta stage 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.
I just created the Budapest MySQL Meetup group. I hope there will be interest for that, the first event is under organising. Check it if you are near Budapest!
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.
I was on the quest of searching the Holy Grail of Go programming, and I found something, which I doubt that it is, but close enough – for the first sight.
I have several problems with GO, first, that I write my code on an OSX box, and I’ll run the programs on Linux hosts, so I have to solve the cross compilation; my second problem with Go, that I don’t really like the “There is a GO project folder, and all the GO projects are relying on” approach. It makes using GitHub painful.
Saturday I was in my favorite 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 opposite than mine – he didn’t found any measurable difference. Reading his post, he did found huge impact in networking which I didn’t check, so I was re-run my checks again, but now with paying attention to network configuration.
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.
This one really was a pain in the ass for a long time.
Jenkins is great, not only for building projects, but I start the most of the ops related tasks here. All the projects have their own workspace, I can browse the previous outputs, see if a task failed or not, and I can easily share the results at the end of the task.
I had only one problem with that: the long-running tasks weren’t shown on console output until they finished. I tried to solve that, but it was only annoying, not a showstopper, so I let that go, because it didn’t look like an easy win, and I didn’t want to spend too much time on that.
But last week I created a job for online altering the database and – surprise! – pt-online-schema-change was continuously updated the console log screen, so I started to google out what is happening.
I am always fascinated by 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 are on you.
Recently I broke this, and frankly, I am not sure if it was a bad decision, or not.
With MySQL, it is relatively easy to create “point in time” restores. All you need is 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.
I have created a simple go application to make your life easier. You can find it on my GitHub page.
I am fascinated. Maybe that should be enough, but I guess I have to write a bit more here because we are not on twitter.
I spent a few days to get know Go language, and now I am more than satisfied. I mean, all the project ideas which are floating in my head should be written in Go.
First of all, I have rewritten Mambo-collector to go (https://github.com/banyek/mambo) because I have faced some serious errors when I used it on CentOS 7 – I blame systemd -: If the process was running as root then after a few days of data collecting, killing that process was lead to restart the entire system, which is not a bug, it is a catastrophe. I tried to debug it several ways, but I am not sure where the problem is, it could be at the ‘loghandler’ redirection or any other place in python-daemon, or it is simply there is a buffer inside which overflows – I don’t really care, because mambo was just a proof of concept – what I used in production. I decided to abandon the project, and rewrite it in a language, what is designed for what mambo is: a system process with a high amount of parallel data processing. In the original version, I spawned an os thread for every query which will run (and we know that there is no real multithreading in python because of the global interpreter lock, at the end, building a multithreaded application in python is just an illusion. It is good for helping you to imagine what will happen inside your the computer, but you cannot expect real multithreading. It wasn’t a real problem because I only ran/run a few queries with mambo – replication lag, all processes inside mysql, active processes inside mysql – but if there would be a need to increase the number of queries that could lead to trouble. And it’s needless to say if you have a lot of time.sleep in your program, that is not the wisest use of your CPU resources: if a CPU is sleeping, then you waste resources.I have enough resources to let waste a bit, but it always disturbed me.
At the end, I decided to rewrite mambo in go.