After the GitHub MySQL Failover incident a lot of blogs/people have explained that fully automated failover might not be the most optimal solution. Fully automated failover is indeed dangerous, and should  be avoided if possible. But a complete manual failover is also dangerous. A fully automated manually triggered failover is probably a better solution. A synchronous replication solution is also not a complete solution. A split-brain situation is a good example of a failure which could happen. Of course most clusters have all kinds of safe guard to prevent that, but unfortunately also safe guards can fail. Every failover/cluster should be considered broken unless: You've tested the failover scripts and procedures You've tested the failover scripts and procedures under normal load You've tested the failover scripts and procedures under high load You've tested it since the last change in the setup and/or application Someone else tested the failover scripts an...

I'm using a very small MariaDB instance as a datastore for my YouLess energy monitor , my own mail server (postfix, roundcube). It's a virtual machine from a commercial VPS provider. All data fits in memory and the overhead of running with performance_schema on is not an issue. While I was reading a blog post about performance_schema by Mark Leith I wanted to see what P_S could tell me about my own server. This is the output from the first query: mysql> select * from file_summary_by_event_name order by count_read desc,count_write desc limit 10; +--------------------------------------+------------+-------------+--------------------------+---------------------------+ | EVENT_NAME | COUNT_READ | COUNT_WRITE | SUM_NUMBER_OF_BYTES_READ | SUM_NUMBER_OF_BYTES_WRITE | +--------------------------------------+------------+-------------+--------------------------+---------------------------+ | wait/io/file/sql/FRM | 25387 | ...

When computers were still using large black text oriented screens or no screens at all, a computer only knew how to store a limited set of characters. Then it was normal to store a name with the more complicated characters replaced by more basic characters. The ASCII standard was used to make communication between multiple systems (or applications) easier. Storing characters as ASCII needs little space and is quite strait forward. Then DOS used CP850 and CP437 and so on to make it possible to use language /location specific characters. Then ISO8859-1 , ISO8859-15 and more of these character sets were defined as standard. And now there is Unicode: UTF-8, UTF-16, UCS2, etc. which allow you to store many different kinds of characters in the same character set. But all those character sets only work correctly if you configure all applications correctly. Many of the character sets are very similar and seem to work correctly even if one of the systems is not correctly configured. If...

The recently released TokuDB brings many features. One of those features is support for XA Transactions. InnoDB already has support for XA Transactions. XA Transactions are transactions which span multiple databases and or applications. XA Transactions use 2-phase commit, which is also the same method which MySQL Cluster uses. Internal XA Transactions are used to keep the binary log and InnoDB in sync. Demo 1: XA Transaction on 1 node: mysql55-tokudb6> XA START 'demo01'; Query OK, 0 rows affected (0.00 sec) mysql55-tokudb6> INSERT INTO xatest(name) VALUES('demo01'); Query OK, 1 row affected (0.01 sec) mysql55-tokudb6> SELECT * FROM xatest; +----+--------+ | id | name | +----+--------+ | 3 | demo01 | +----+--------+ 1 row in set (0.00 sec) mysql55-tokudb6> XA END 'demo01'; Query OK, 0 rows affected (0.00 sec) mysql55-tokudb6> XA PREPARE 'demo01'; Query OK, 0 rows affected (0.00 sec) mysql55-tokudb6> XA COMMIT 'demo01...

After reading www.postgresq.org now active over IPV6 by default I quickly tried some other host to see what the current state of IPv6 is for some known database websites. $ getent hosts mysql.com percona.com askmonty.org postgresql.org oracle.com sqlite.org code.openark.org skysql.com drizzle.org 156.151.63.6    mysql.com 74.121.199.234  percona.com 173.203.202.13  askmonty.org 2a02:16a8:dc51::50 postgresql.org 137.254.16.101  oracle.com 67.18.92.124    sqlite.org 69.89.31.240    code.openark.org 94.143.114.49   skysql.com 173.203.110.72  drizzle.org So only postgresql.org supports IPv6 right now. On the MySQL side Facebook is one of the known IPv6 users. Are there any IPv6  database websites I forgot to include? The World IPv6 Launch is June 6 2012, so there are still a few days left to enable IPv6!

As most people still do I learned to read using books. WhooHoo! Books are nice. Besides reading them they are also a nice decoration on your shelf. There is a brilliant TED talk by Chip Kidd on this subject. But sometimes books have drawbacks. This is where I have to start the comparison with vinyl records (Yes, you're still reading a database oriented blog). Vinyl records look nice and are still being sold and yes I also still use them. The drawback is that car dealers start to look puzzeled if you ask them if your new multimedia system in your car is able to play your old Led Zeppelin records. The market for portable record players is small, and that's for a good reason. The problem with books about databases is that they get old very soon. The MySQL 5.1 Cluster Certification Study Guide was printed by lulu.com which made it possible to quickly update the material. This made sure that the material wasn't outdated when you bought it. I like to use books as refere...

Last Friday the Dutch TV program Zembla aired part two of the "verzuimpolitie" series. The first part was mainly about how employers could access medical information about employees. There is a news article about the second part here (with google translate). The second part is about the security of the IT system which is used to record medical information about employees. They give this information to the company to which the company they're working for is outsourcing everything related to workplace absenteeism. After the first part of the series some viewer reported that the website contained SQL injections. The creators of the program verified this and tried to report it to VCD (The company which offers the software as a service). Then VCD called to police to remove them from the VCD office. Then Zembla contacted the Radboud University and asked them to assist with this issue. The University verified the SQL Injection and confirmed that this was a serious sec...