Перша спроба міграції EC2 MySQL на Amazon RDS не проходить добре - привілеї SUPER

Я намагався перемістити існуючий db з MySQL, що працює на EC2, до нового екземпляра Amazon RDS (експеримент, щоб побачити, чи зможемо ми перейти через). Поки що це не добре. Я затримався на початковому імпорті перед налаштуванням реплікації ( тут інструкції ).

Я підготував екземпляр RDS, як описано, і можу підключитися до нього з екземпляра EC2 за допомогою mysql. Я запустив команду mysqldump як:

mysqldump --master-data --databases db1 db2 > dump.sql

Потім спробували завантажити його в RDS за допомогою:

mysql -h RDSHost -P 3306 -u rdsuser --password=rdspassword < dump.sql

Перша проблема була в рядку 22 звалища:

ЗМІНИ МАЙСТЕР НА MASTER_LOG_FILE = 'mysql-bin.000002', MASTER_LOG_POS = 106;

Цей рядок викликав помилку ERROR 1227 (42000) at line 22: Access denied; you need (at least one of) the SUPER privilege(s) for this operation. Немає проблем, просто прокоментував цей рядок і сподіваюся виправити його пізніше через mysql.rds_set_external_master (). Повторена завантаження, і отримав дуже схожу помилку: ERROR 1227 (42000) at line 7844: Access denied; you need (at least one of) the SUPER privilege(s) for this operation. Розділ навколо рядка 7844 виглядає приблизно так:

/*!50001 CREATE ALGORITHM=UNDEFINED */
/*!50013 DEFINER=`dev`@`localhost` SQL SECURITY DEFINER */
/*!50001 VIEW `jos_contributor_ids_view` AS select `jos_resource_contributors_view`.`uidNumber` AS `uidNumber` from `jos_resource_contributors_view` union select `jos_wiki_contributors_view`.`uidNumber` AS `uidNumber` from `jos_wiki_contributors_view` */;

Коментуючи перші 2 рядки та додавши «СТВОРИТИ» до третього, я зміг подолати цей. Але є тони таких розділів. Чи є спосіб обійти це питання без усієї редакції? Як варіант, щоб mysqldumpне створювати нічого, що потребує привілеїв SUPER?

Схоже, у багатьох людей виникли подібні проблеми, як, наприклад, доводиться бігати sedпроти виходу mysqldump / mysqlbinlog! Я також буду публікувати на форумі AWS - я дійсно думаю, що RDS повинен мати більш толерантний спосіб імпорту з mysqldump, або певний інструмент, який можна застосувати проти існуючого db, щоб створити дамп, який скаржиться на безпеку RDS. Просто цікаво, чи є у когось інші рецепти чи хитрощі, які можуть допомогти тут.

Спасибі,

Дейв

Вам, ймовірно, потрібно log_bin_trust_function_creators= 1 на RDS, але це не проблема.

Ви можете вказати  DEFINER значення, відмінне від вашого власного рахунку, лише якщо у вас є  SUPER привілей.

^{- http://dev.mysql.com/doc/refman/5.6/uk/stored-programs-security.html}

Коли збережена програма (proc, функція, подія чи тригер) працює, все, що вона робить, має дозволи користувача, який її визначив, або користувача, чітко зазначеного в DEFINERдекларації. Це дозволяє, серед іншого, зберігаючим програмам дозволяти іншим користувачам робити речі з даними, якими вони безпосередньо не мають дозволу на маніпулювання, доки вони мають дозвіл на використання самої збереженої програми.

Тоді це було б серйозною вразливістю, якщо SUPERнекористувач може створити процедуру з довільним визначенням, оскільки користувач може ескалацію своїх привілеїв за власним бажанням.

Це також стосується поглядів, звичайно, коли використовується визначений контекст безпеки, як у прикладі, який ви розмістили.

Одне з найбільших нарікань, які я маю з RDS, - це те, що ти не можеш мати SUPER... і тепер він теж може бути одним із твоїх :), тому що саме цей факт є причиною проблеми, яка виникає.

Звичайно, якби я працював з керованою службою MySQL, я нікому не дав би SUPER, тому їхня модель безпеки має сенс, навіть якщо це іноді непросто.

Якщо всі ваші об’єкти мають однакове визначення, вирішенням проблеми буде відновлення дампа за допомогою цього облікового запису замість того, який ви використовуєте зараз, але це здається малоймовірним.

Видалення просто рядка з DEFINERдекларацією повинно змусити dumpfile працювати в тих випадках, коли він з'являється на рядку сам по собі, або ви можете використовувати sed або perl для зміни файлу ... ідея, яку я вже знаю, що вам не подобається, але насправді в MySQL приємно, що таке хакерство є цілком законним, і це не зовсім так далеко від тих речей, які я маю робити як DBA навіть у середовищі, що не має RDS.

perl -pe 's/\sDEFINER=`[^`]+`@`[^`]+`//' < oldfile.sql > newfile.sql

... можливо, не відповідь, на яку ви сподівалися, але ви можете запустити це проти свого dumpfile, і в кінцевому підсумку вийде трохи корисніший файл.

У моєму випадку рядок "ЗМІНИ МАЙСТЕР НА MASTER_LOG_FILE = ..." на смітнику, який давав мені помилку. Цей рядок був доданий опцією mysqldump "--master-data". В Amazon AWS потрібно запустити реплікацію, встановивши основні деталі за допомогою процедури "mysql.rds_set_external_master" замість цього прочитати тут

Тож я просто зазначив примітки до цього рядка "head 22 backup.dump", де рядок 22 повідомляв про помилку. Потім видаліть його перед імпортом, для мого великого файлу я використовую: "sed '22d' backup.dump> backup_clean.dump"