I had to install Percona XtraDB Cluster, I think for the first time since it was announced stable. I remembered many problems I faced with beta releases, which was understandable given they were only for a preview, but this time I hoped for significant improvements.
I have to say I am generally quite sensitive about simple problems that could/should be easily discovered and corrected. Well, it didn't take five minutes to see a few of such problems. These minutes I spent installing the database binaries from Percona Yum repository. It turned out that was enough to see a lot of errors for no reason. Not a good thing.
[..] Installing : 1:Percona-XtraDB-Cluster-server-5.5.23-23.5.333.rhel6.x86_64 5/5 ls: cannot access /var/lib/mysql/*.err: No such file or directory ls: cannot access /var/lib/mysql/*.err: No such file or directory [Note] Flashcache bypass: disabled
Why does it matter that ls: cannot access /var/lib/mysql/*.err: No such file or directory? Assuming in many cases I will be installing on a clean system I wouldn't even expect /var/lib/mysql should exist first thing after installing the binaries.
A bit more silly was the following error:
WSREP: Failed to read output of: '/sbin/ifconfig | grep -m1 -1 -E '^[a-z]?eth[0-9]' | tail -n 1 | awk '{ print $2 }' | awk -F : '{ print $2 }''
[Warning] WSREP: Failed to autoguess base node address
[Note] WSREP: Service disconnected.
[Note] WSREP: Some threads may fail to exit.
It seems to be an element of some network interface discovery system, which is cool that somebody thought of that. But why does it limit the search to eth* devices and then it fails? Who actually uses raw eth0 device in a database cluster? The common practice is to create link aggregation for redundancy, which Linux provides through its bonding driver. The cluster software should look for /proc/net/bonding/ and check its contents first and only if it finds nothing there, it should try to locate any other usable devices. And even that last part should never crash like that. I would completely understand a simple message that auto-discovery failed and I should provide the valid network address myself, but not a pile of unhandled problems.
Then... another random error:
Percona recommends that all production deployments be protected with a support contract (http://www.percona.com/mysql-suppport/) to ensure the highest uptime, be eligible for hot fixes, and boost your team's productivity. /var/tmp/rpm-tmp.6TRZxd: line 82: x1: command not found
What is the mysterious x1 command? Is the support missing after all?
I do not think these are big problems at all. I could point out much worse problems in a lot less complex programs, but on the other hand it may indicate lack of proper testing, which given the nature of this particular piece of software, doesn't sound right.