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 |
root@testmachine:~# apparmor_status<br>apparmor module is loaded.<br>7 profiles are loaded.<br>7 profiles are in enforce mode.<br>/sbin/dhclient<br>/usr/lib/NetworkManager/nm-dhcp-client.action<br>/usr/lib/connman/scripts/dhclient-script<br><strong>/usr/sbin/mysqld</strong><br>/usr/sbin/named<br>/usr/sbin/ntpd<br>/usr/sbin/tcpdump<br>0 profiles are in complain mode.<br>2 processes have profiles defined.<br>2 processes are in enforce mode.<br>/usr/sbin/named (1205)<br>/usr/sbin/ntpd (1347)<br>0 processes are in complain mode. |
You can disable a profile easily by running
|
1 |
sudo ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/<br>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
Resources
RELATED POSTS
