LINUX.ORG.RU

apparmor не пускает к /etc/mysql/my.cnf.migrated после апдейта mysql?

 , ,


0

1

обновил дистр xUbuntu 14.04 -> xUbuntu 16.04.1
в процессе обновления mysql (5.5.50->5.7.13) вылетел с ошибкой (текст могу привести по требованию)

теперь пытаюсь перебрать все ручками по кусочкам
делаю-получаю:

~$ sudo /etc/init.d/mysql restart
[....] Restarting mysql (via systemctl): mysql.serviceJob for mysql.service failed because the control process exited with error code. See "systemctl status mysql.service" and "journalctl -xe" for details.
 failed!

ок, смотрим журнал
~$ journalctl -xe|grep mysql|  less
--блабла
-- Начат процесс запуска юнита mysql.service.
Авг 16 18:52:18 meniac kernel: audit: type=1400 audit(1471362738.568:1880): apparmor="DENIED" operation="open" prof
ile="/usr/sbin/mysqld" name="/etc/mysql/my.cnf.migrated" pid=19365 comm="mysqld" requested_mask="r" denied_mask="r"
 fsuid=116 ouid=0
--блабла

сие меня очень удивляет, ибо
в /etc/apparmor.d/usr.sbin.mysqld стоит
# Allow config access
/etc/mysql/ r,
/etc/mysql/** r,
а
~$ grep -r 'my.cnf.migrated' /etc/apparmor.d/
- не дает ничего, то есть явно он в apparmor не запрещен нигде!
(sudo /etc/init.d/apparmor reload - сделать не забыл, да)

нид хелп - что происходит и как с этим жить?



Последнее исправление: cetjs2 (всего исправлений: 1)
Ответ на: комментарий от Deleted

я поставил mysql 5.50 под ubuntu 14.04 под виртуалкой (т.е. ту версию под которой теоретически эти БД еще работали)
весь каталог /var/lib/mysql/ скопировал с заменой всех файлов в аналогичный /var/lib/mysql/ на виртуалке
ожидаемо mysql стартовать перестал!
в логе мускуля после попытки старта наблюдаю такое:
блаблабла
InnoDB: Error: log file ./ib_logfile0 is of different size 0 50331648 bytes
InnoDB: than specified in the .cnf file 0 5242880 bytes!
160826 3:47:45 [ERROR] Plugin 'InnoDB' init function returned error.
160826 3:47:45 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
160826 3:47:45 [ERROR] Unknown/unsupported storage engine: InnoDB
160826 3:47:45 [ERROR] Aborting
блаблабла

какие есть варианты, чтобы это дело починить?

MinasFilm
() автор топика
Ответ на: комментарий от MinasFilm

При попытке старта, InnoDB берет параметры из my.cnf и вдруг обнаруживает, что реальные параметры файлов другие. Он пишет, что ./ib_logfile0 имеет другой размер (48Мб), нежели указан в my.cnf (5Mb) Вариант, убрать из my.cnf строчку innodb_log_file_size закомментировав её, либо привести в соответствие с реальностью (48 Мб).

Могу сказать, что mysql-server обратно совместим по бинарным файлам. Т.Е старшая версия подцепит файлы младшей версии, но не наоборот.

rootFS
()
Ответ на: комментарий от rootFS

у меня в my.cnf вообще нет параметра innodb_log_file_size
вы считаете, что нужно его установить там на значение 50331648 (из Error-лога)?

по версиям сервера (файлов innodb соотв.), вроде бы полностью идентичны
хотя после апгрейта дистра убунты 12->14 я блин, не догадался проверить именно innodb-базы (с обычным майисамом все было ок)

MinasFilm
() автор топика
Ответ на: комментарий от rootFS

в общем поставил я в my.cnf
[mysqld]
innodb_force_recovery=4
innodb_log_file_size=50331648

теперь ошибка такая:


60826 15:59:59 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
160826 15:59:59 [Note] Plugin 'FEDERATED' is disabled.
160826 15:59:59 InnoDB: The InnoDB memory heap is disabled
160826 15:59:59 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160826 15:59:59 InnoDB: Compressed tables use zlib 1.2.8
160826 15:59:59 InnoDB: Using Linux native AIO
160826 15:59:59 InnoDB: Initializing buffer pool, size = 128.0M
160826 15:59:59 InnoDB: Completed initialization of buffer pool
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
InnoDB: You may have to recover from a backup.
160826 15:59:59 InnoDB: Page dump in ascii and hex (16384 bytes):
блаблабла
InnoDB: End of page dump
160826 16:00:01 InnoDB: Page checksum 3075225854, prior-to-4.0.14-form checksum 1828779651
InnoDB: stored checksum 2589461873, prior-to-4.0.14-form stored checksum 2589461873
InnoDB: Page lsn 0 5674517, low 4 bytes of lsn at page end 5674517
InnoDB: Page number (if stored to page already) 5,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a transaction system page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
160826 16:00:01 InnoDB: highest supported file format is Barracuda.
InnoDB: No valid checkpoint found.
InnoDB: If you are attempting downgrade from MySQL 5.7.9 or later,
InnoDB: please refer to http://dev.mysql.com/doc/refman/5.5/en/upgrading-downgrading.html
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.
InnoDB: If that is the case, please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/error-creating-innodb.html
160826 16:00:01 [ERROR] Plugin 'InnoDB' init function returned error.
160826 16:00:01 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
160826 16:00:01 [ERROR] Unknown/unsupported storage engine: InnoDB
160826 16:00:01 [ERROR] Aborting
160826 16:00:01 [Note] /usr/sbin/mysqld: Shutdown complete


какие будут варианты починки?

MinasFilm
() автор топика
Ответ на: комментарий от MinasFilm

Вообще,я бы уже накатил бы из бекапа,
(под бекапом баз всегда подразумевается SQL-дамп), пусть и с потерей данных.
Вопрос - в изначальном варианте (в старой версии системы), был ли включен параметр innodb_file_per_table?
Если нет - то единственный вариант, в зависимости от ценности данных - обратиться в саппорт ораклы.
InnoDB не переживает «файловый» бекап,
вернее переживает, только в том случае, если
mysql-сервер на момент копирования был отключен.
Или-же, перед копированием были сброшены все буфера с
полной блокировкой всех баз/таблиц до окончания копирования.
Есть инструмент для бекапа - percona-xtrabackup, который
минимизарует время блокировки базы, осуществляя бекап «живого» сервера «по кусочкам»,
параллельно мониторя загрузку сервера.
Но это «высший пилотаж».

К сожалению, в данной ситуации нужен разработчик,
знающий «внутреннюю» структуру данных в файлах InnoDB,
чтобы вытащить оттуда что-то стоящее.

rootFS
()
Ответ на: комментарий от rootFS

Есть еще вариант - «на удачу».
Может прокатит, может нет.
Попробуйте перед стартом удалить
все ib_logfile*
Но только их!

И стартовать сервер - он их создаст сам.
Это файлы содержат снимки последнего состояния - транзакции,
завершенные и нет, контрольные суммы и многое другое,
что нужно InnoDB при внезапном отключении питания,
чтобы привести базу в состояние целостности.
Если запуститься - Вам повезло.

rootFS
()
Ответ на: комментарий от rootFS

innodb_file_per_table в конфиге нет, логи удалял - не стартует

меня что смущает, что на такой же точно версии дистра (после первого апгрейта) - эти же базы ведь работали! ну всяко mysql стартовал...
то есть - возможно, в «старом» конфиге есть еще какие-то параметры, которые позволяли ему запуститься?..

MinasFilm
() автор топика
Ответ на: комментарий от MinasFilm

Если при старте, серверу не нравиться какая-либо опция - он об этом в error-лог матерится.
У нас же

InnoDB: Database page corruption on disk or a failed

К сожалению, это занавес.

rootFS
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.