UPDATE: agora sei que o meu problema era corrupção de banco de dados, mas discernir que era um pouco complicado - apparmor parecia ser a causa por mais tempo do que deveria.
Eu não notei quando publiquei pela primeira vez que, mesmo depois de colocar o mysql no modo de reclamar e enviar os comandos stop e teardown , meu syslog ainda mostrava a mensagem do apparmor ... alimentando meu medo irracional da camada de proteção. Ainda não sei como isso aconteceu. Eu finalmente consegui mysql separado do apparmor, mas ainda não consegui bloquear seus próprios arquivos. Ergo banco de dados corrupção - dang. Meus backups funcionaram bem em um novo servidor.
INICIAL POST:
O servidor mysql está sendo bloqueado por (eu acho ) apparmor, mas estou no fim para determinar por que / como. Eu não estou muito familiarizado com apparmor.
Eu sei que não devo desinstalar o apparmor - por pelo menos duas razões - mas eu usei palavrões o suficiente (e dei a esta questão muito tempo) para não considerá-lo. Espero que eu esteja apenas sentindo falta de algo simples e aprenda aqui.
A falha começou hoje e não segue mudanças no sistema. O log de erros do MySQL lamenta as permissões
Can't open and lock privilege tables: Table 'servers' is read only
Não consegui encontrar ninguém com esse problema que não esteja movendo atualmente o armazenamento de banco de dados padrão. Eu mudei o meu também - dois anos atrás. A configuração apparmor está inalterada desde 2014/04/21 :
/files/bak/tmp/ rw,
/files/bak/tmp/* rwk,
/files/bak/mysql/ rw,
/files/bak/mysql/** rwk,
Eu verifiquei as permissões do sistema de arquivos:
# find mysql/ -type d -exec chmod 700 {} \;
# find mysql/ -type f -exec chmod 660 {} \;
# chown -R mysql: mysql
Eu recarreguei o apparmor, instalei o apparmor-utils, empurrei o mysql para reclamar
# aa-complain mysql
# apparmor_status
apparmor module is loaded.
5 profiles are loaded.
4 profiles are in enforce mode.
/sbin/dhclient
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/connman/scripts/dhclient-script
/usr/sbin/tcpdump
1 profiles are in complain mode.
/usr/sbin/mysqld
1 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
1 processes are unconfined but have a profile defined.
/sbin/dhclient (495)
... mas a visualização do syslog ainda sugere que o apparmor está bloqueando o mysql após service mysql start :
apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=13899 comm="apparmor_parser"
Antes de encontrar o problema do apparmor, tentei restaurar os DBs dos backups, que também falharam com as permissões de gravação:
Can't create/write to file '/files/bak/mysql/dbCooper/wp_cb_contact_form.MYI'
Eu verifiquei que o sistema de arquivos é 'rw' (mesmo que o find -exec acima tenha falhado):
mount
/dev/xvdf on /files/bak type ext4 (rw,noatime)
Eu até tentei parar o apparmor, mas o syslog ainda mostra can't open and lock privilege tables depois disso:
# service apparmor stop
[...redacted teardown msg...]
# /etc/init.d/apparmor teardown
* Unloading AppArmor profiles
# service apparmor status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
É possível que o mysql bloqueie arquivos de banco de dados e não os desbloqueie quando o daemon falha? Se sim, como eu limparia a fechadura?
Atualmente estou executando meu banco de dados com
mysqld --skip-grant-tables
... então sei que o executável pode ser executado e os bancos de dados são pelo menos um pouco válidos (todos os sites parecem normais). Eu estou sentindo falta de algo idiota?
Eu tentei aparar este post para informações relevantes - feliz em postar todo (cfg | log) onde for útil.
Obrigado pela leitura
Se este post deve ser movido para outro Stack Exchange (ServerFault?) peço desculpas - e mods sinta-se livre para corrigi-lo.