Нажмите "Enter" для перехода к содержанию

MySQL Enterprise Backup: Backup Fails since 2013 year. Восьмилетний баг на авторизованном курсе Oracle в 2021 году.

И смешно и плакать хочется, хотя в этом весь Oracle!

Авторизованный курс Oracle MySQL for Database Administrators в Москве, октябрь 2021 года. На практическом занятии необходимо сделать бэкап БД с помощью MySQL Enterprise Backup (коммерческий продукт). Вся среда, в которой выполняется практика, подготовлена, согласно требованиям Oracle — Oracle Linux 7.5, MySQL Server 8.0.18, MySQL Enterprise Backup 8.0.18. В группе нас 4 и все поймали ошибку выполнения бэкапа — данные повреждены.

...
180824 11:52:00 PCR3    INFO: Re-reading page at offset 8110080 in /var/log/mysql/db1/t1.ibd
180824 11:52:00 PCR3    INFO: Re-reading page at offset 8126464 in /var/log/mysql/db1/t1.ibd
180824 11:52:00 PCR3    INFO: Re-reading page at offset 8142848 in /var/log/mysql/db1/t1.ibd
180824 11:52:00 PCR3    INFO: Re-reading page at offset 8159232 in /var/log/mysql/db1/t1.ibd
180824 11:52:00 PCR3    INFO: Re-reading page at offset 8175616 in /var/log/mysql/db1/t1.ibd
180824 11:52:00 PCR3    INFO: Re-reading page at offset 8192000 in /var/log/mysql/db1/t1.ibd
...

180824 11:52:00 PCR3 ERROR: Page at offset 8192000 in /var/log/mysql/db1/t1.ibd seems corrupt!

Проверил данные, MySQL говорит, что все ОК, нет повреждений. Удалил БД и восстановил из скрипта — ошибка. Откатил виртуалку на предыдущий день и заново из скрипта восстановил БД, но бэкап все равно не снимается, данные повреждены :0 На автомате, я полез на меташланг. Нравится это название, которое позаимствовал у trueDBA, когда начинал только сопровождать БД. Нашлась нотка по данной проблеме — MySQL Enterprise Backup (MEB) Fails With : «mysqlbackup: ERROR: Page at offset XXXX in /path/to/ibdata1 seems corrupt!» (Doc ID 1644743.1)

Данный баг — не баг, а набор багов, а может фича (почитайте сами ноту), тянущаяся с 2013 года с версии MySQL Enterprise Backup 3.8. Предоставленное решение в ноте не помогло снять бэкап. Не помогло решение из документации innochecksum —no-checksum. Так и чесались руки завести SR, но предвидел ответ: «Поставьте последние обновления на все что можно и попробуйте еще раз». Стандартный ответ, что для Oracle, что для MySQL.

В главном авторизованном учебном центре Oracle в России, в авторизованной среде выполнения, мы ловим баг при бэкапе коммерческим продуктом, выполняя авторизованное практическое задание. Бэкап так и не сделали, решение из ноты не работает. Ну а преподаватель…. не будем об этом, я знал куда лечу учиться, надежда была на авторизованный курс.

Явно никто не прогонял лабораторные занятия, иначе этого бы не случилось. Короче фиаско. Везде безалаберность. Морали и выводов никаких нет, просто забавный случай и еще один баг, который нашел меня. В оправдание MySQL, как-то с Кротовым Костей нашли баг в Oracle GoldenGate, который лежал на поверхности многие годы и его никто не находил. Там еще была эпопея с тем как Oracle на*бывает пользователей, выпуская исправление бага, которые исправляют баг только в pdf к очередному релизу GG. Но это другая история.