Percona XtraDB Cluster: SElinux is not always the culprit !

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 :

You can disable a profile easily by running

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

Share this post

Comments (6)

  • erkan

    I wold suggest to extend the profile instead of disabling the profile :/

    December 21, 2012 at 4:09 am
  • lefred

    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

    December 21, 2012 at 4:31 am
  • nate

    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.

    January 2, 2013 at 3:33 pm
  • Ernie Souhrada


    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.

    January 3, 2013 at 12:18 am
  • Frederic Descamps

    If you want to have an idea of the cost of SELinux on MySQL, you can read this blog post:

    So all depends on what you are looking for, security or performance ?

    Happy New Year 😉

    January 3, 2013 at 3:52 am
  • Carlos Ferreira

    I would recommend to “complain” instead of “disable/remove :

    October 19, 2016 at 8:30 am

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.