If you are using SElinux, you should know that it’s advised to disable it to avoid issue with PXC. Generally the communication between your nodes doesn’t work properly and a node having SElinux enabled won’t be able to join the cluster.
So when a node doesn’t join the cluster where it should, my first reflex is to have a look at audit.log. But recently I faced another problem: the node joined the cluster but SST failed (whatever which method was used, discarding skip).
I checked SElinux and it was of course disabled, then I add some debug information in the SST script but it seemed that the script was never launched. And this time the culprit is called : AppArmor !
Percona doesn’t provide any AppArmor profile for PXC, but it seems that on this server (Ubuntu TLS), a previous version of MySQL was installed and then removed but the AppArmor profile was still present.
So if you use apparmor (or if you don’t know) and you want to check is there is a profile for mysql, you can run the following command :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | root@testmachine:~# apparmor_status apparmor module is loaded. 7 profiles are loaded. 7 profiles are in enforce mode. /sbin/dhclient /usr/lib/NetworkManager/nm-dhcp-client.action /usr/lib/connman/scripts/dhclient-script <strong>/usr/sbin/mysqld</strong> /usr/sbin/named /usr/sbin/ntpd /usr/sbin/tcpdump 0 profiles are in complain mode. 2 processes have profiles defined. 2 processes are in enforce mode. /usr/sbin/named (1205) /usr/sbin/ntpd (1347) 0 processes are in complain mode. |
You can disable a profile easily by running
1 2 | sudo ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/ sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.mysqld |
For more information related to AppArmor, you can refer to Ubuntu’s wiki
So now if you run ubuntu, you have two things to check first : SElinux and AppArmor !
Note: We often advise to disable SElinux and AppArmor on dedicated MySQL servers to avoid the performance overhead
I wold suggest to extend the profile instead of disabling the profile :/
Hi Erkan,
Sure this is a possibility, but don’t forget the overhead caused by AppArmor, they already claim 2% and it seems that for some operation like simple open/close it could raise to more than 110%
By the way, I will see with our engineer responsible of packaging if we could also provide the needed profile with PXC. If you have one to share with me feel free 😉 Thank you
SELinux is like windows ACLs bolted onto linux. both should die.
I disabled SELinux everywhere, always have. There are much better, less frustrating means to secure a system against most threats. I really rarely come across a senior engineer/admin who does not turn off SElinux entirely. I suppose if you operate a public SSH server, it’d be useful. My systems operate in much more controlled environments.
@Nate–
SELinux is used more widely than you might think, particularly in industries that are subject to significant governmental regulation, such as healthcare and banking/finance, and even on servers that have no direct connection to the public internet.
I agree that SELinux configuration can be quite frustrating, but I think the learning curve is worthwhile. Even if you don’t make any tweaks besides adjusting the security context to keep your MySQL data files somewhere other than /var/lib/mysql, understanding SELinux gives you an extremely fine-grained level of control over your system, and IMHO, that’s really cool.
If you want to have an idea of the cost of SELinux on MySQL, you can read this blog post:
http://www.dbasquare.com/2012/05/01/the-cost-of-improved-security-on-a-mysql-server/
So all depends on what you are looking for, security or performance ?
Happy New Year 😉
I would recommend to “complain” instead of “disable/remove : https://blogs.oracle.com/jsmyth/entry/apparmor_and_mysql