Installation Problems from Scracth on ubuntu 12

Hi!
I am following the installation instructions on your site to get a xtradb cluster up and running over three ubuntu machines, but, when it comes to the part of stopping the server when the installation finishes (as on ubuntu installation the server is started automatically) I get an error of:
Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’
This happens when i try to stop the server following your instructions [URL]http://www.percona.com/doc/percona-xtradb-cluster/howtos/ubuntu_howto.html[/URL]

If I manually stop the server throuhg command line using mysqladmin shutdown and stopping the service mysql running, and then I try to launch the server again from your script as commanded in the tutorial, the same error comes again.

I have no mysql.sock at all in my system, and I have checked the permissions on all the directories involved in the installation.

¿Could I get a hand, here?

Thank you!!

Hi!

After messing around a bit, I get the first node up and running, but, when I try to start the second, I can’t start the service due to this error:

131019 5:07:34 [Note] WSREP: wsrep_load(): loading provider library ‘/usr/lib/libgalera_smm.so’
131019 5:07:34 [Note] WSREP: wsrep_load(): Galera 2.7(r157) by Codership Oy <info&#64;codership.com> loaded succesfully.
131019 5:07:34 [Note] WSREP: Found saved state: 00000000-0000-0000-0000-000000000000:-1
131019 5:07:34 [ERROR] WSREP: Failed to open file ‘/var/lib/mysql//galera.cache’: 1 (Operation not permitted)
at gcache/src/gcache_fd.cpp:constructor_common():88
131019 5:07:34 [ERROR] WSREP: wsrep::init() failed: 6, must shutdown
131019 5:07:34 [ERROR] Aborting

131019 5:07:34 [Note] /usr/sbin/mysqld: Shutdown complete

Any clues?

Hi dravencrow,

Did you check permissions for your datadir & for this file please ?

Regards,

Laurent

Hi!
Yes, I had the right permissions on the directories but, after fighting a little more over the issue (and reinstalling from scratch everything again because for sure I have touched something I shouldn’t touch) I have it working properly. Despite of being a newbie to Linux (this is my first linux install ever) and Percona cluster, I will leave my conclusion here for it could be useful to somebody with my same problems (and probably will make the experts laugh at me :P):

  • It’s important (at least in my case, with a fresh Ubuntu Server installation with no added packages or further configuration) to launch the commands to start and stop the percona cluster from the /etc/init.d/ directory with the absolute path, I mean: I was obtaining the first error I posted when launching:
    sudo mysql stop OR sudo mysql start

That it’s not the same than launching “sudo ./mysql stop” or “sudo ./mysql start”. The right option for me is launching with the “./” and the “sudo”. Of course this is a matter of permissions and shell bash or something, but the first error with the “can’t connect through socket” it’s gone (the socket created is the one on the debian.cnf file). The script by percona (./mysql) is not the same (at least it seems to me not to be the same) than “mysql” native command and that was my first mistake (sorry for having bothered you).

After that, I have found a pair of problems with the debian.cnf file in the path /etc/mysql/debian.cnf. I could’nt start the second node due to an error of user/pass in the MySQL Server. Searching through the forum I found a bug that remarks that, sometimes, the password on the debian.cnf file of the second and further nodes has to be changed to the password on the debian.cnf file from the first node.

At last, I have found that changing the line on the my.cnf of each node regarding “Authentication SST” to the user root worked, while creating the new user in MySQL won’t (maybe because I have created it only on the first node, and logically it seems that it has to be created on the three nodes, I don’t know).

At the moment I have three nodes up, and a HAProxy load balancing the connections. In further days I will try to adjust and tune the security issues of having the user “root” as the user for SST Authentication.