Первоначально написано Майкл Коберн
Привет, недавно у меня был опыт оказания помощи в миграции клиентской установки MySQL на Amazon RDS (Relational Database Service). Amazon RDS является отличной платформой для размещения вашей установки MySQL и предлагает следующий список плюсов и минусов:
- С помощью Amazon RDS вы можете отдельно масштабировать ваш ЦП, IOPS и пространство хранения. В противном случае вам потребуется сократить время простоя и обновить физические компоненты сервера, монтируемого в стойку.
- Резервное копирование, исправление версий программного обеспечения, обнаружение сбоев и (некоторые) восстановление автоматизируются с помощью Amazon RDS.
- Вы теряете доступ оболочки к вашему экземпляру БД
- Вы теряете привилегию SUPER для постоянных пользователей. Многие операторы и команды типа SUPER представлены как хранимая процедура.
- Легко настроить несколько реплик чтения (ведомые в режиме READ_ONLY = 1).
- Вы можете настроить вторичный синхронный экземпляр для отработки отказа в случае сбоя основного экземпляра.
Хотя эта статья написана специально для Amazon RDS, она также имеет значение для любого вида миграции.
- Единственный способ взаимодействия с RDS — через клиент mysql, что означает, что загрузка данных должна выполняться с использованием SQL. Это означает, что вам нужно использовать mysqldump или mydumper, что может быть большим усилием, если ваш набор данных будет к северу от 500 ГБ — это много однопоточных действий! Подумайте не только о том, сколько времени займет дамп и загрузка, но и о том, сколько времени потребуется репликации, чтобы наверстать упущенное в часах / днях / неделях, которые занимала процедура дампинга и загрузки. Возможно, вам придется выделить больше дискового пространства и выделенных IOPS для вашего узла RDS, чтобы повысить пропускную способность диска, а также изменить innodb_flush_log_at_trx_commit и sync_binlog.
- RDS установлен в UTC (system_time_zone = UTC), и его нельзя изменить, так как в группах параметров вы увидите, что default_time_zone имеет значение Modifiable = false. Это может вас укусить, если вы планируете использовать RDS в качестве ведомого в течение короткого времени, прежде чем переключать приложение на Amazon RDS. Если вы настроили binlog_format = STATEMENT на своем мастере и у вас есть столбцы TIMESTAMP, это приведет к различиям в наборе данных RDS для абсолютных значений «2014-07-24 10:15:00» против «NOW» (). Разработчик также обеспокоен тем, что, возможно, он явно не объявляет свои соединения MySQL для установки соответствующего часового пояса. Часто лучшим советом может быть оставить все данные базы данных в UTC независимо от того, где физически расположен сервер, и заниматься локализацией на уровне представления.
- Amazon RDS по умолчанию имеет max_allowed_packet = 1 МБ. Это довольно мало, так как большинство других конфигов имеют размер 16 МБ, поэтому, если вы используете extended-insert (по умолчанию это так), размер каждого оператора вставки будет близок к 16 МБ, что может привести к ошибкам, связанным с «слишком большим пакетом». ”На стороне Amazon RDS, таким образом, проваливая импорт.
- Amazon RDS не поддерживает привилегию SUPER для обычных пользователей. Например, это становится довольно сложной задачей, так как многие инструменты (Percona Toolkit) созданы для того, чтобы предполагать, что у вас есть доступ уровня SUPER ко всем узлам — простые задачи значительно усложняются, так как вам нужно подумать об умных обходных путях (я смотрю на вас) пт-таблицы синхронизации!).
- Таким образом, триггеры и представления не могут быть применены с использованием синтаксиса mysqldump по умолчанию, который включает в себя записи SQL DEFINER — эти строки существуют для того, чтобы пользователь с SUPER мог «предоставить» другому пользователю возможность выполнить триггер / представление. Ваша загрузка потерпит неудачу, если вы забудете это.
- Попробуйте запустить загрузку с помощью –force для клиента mysql и зарегистрируйтесь на диске stderr / stdout, чтобы позже можно было просмотреть ошибки. Больно тратить 4 дня на загрузку базы данных объемом 500 ГБ, только чтобы она частично провалилась, потому что вы забыли о проблеме SQL DEFINER.
- Рассмотрите возможность разделения mysqldump на две фазы: –no-data, чтобы вы выгружали только схему, а затем –data-only, чтобы получить только строки. Таким образом, вы можете локализовать ошибки и устранить их по пути.
- Пропуск событий репликации медленный. У вас нет возможности использовать sql_slave_skip_counter (поскольку для этого требуется SUPER), вместо этого вам нужно использовать функцию Amazon RDS mysql.rds_skip_repl_error. К сожалению, эта хранимая процедура не принимает аргументов и, следовательно, пропускает только одно событие за раз. Это занимает около 2-3 секунд для каждого выполнения, поэтому, если у вас есть много пропущенных событий, это проблема. Отсутствие пропуска НИЧЕГО указывает на то, что в процессе что-то пошло не так, поэтому, если вы оказались в незавидном положении пропуска событий, знайте, что pt-таблица-контрольная сумма должна дать вам представление о том, насколько широко распространена проблема расхождения данных.
- pt-table-sync не работает с Amazon RDS, так как он написан для ожидания SUPER, потому что он хочет выполнить binlog_format = STATEMENT в сеансе, но это не разрешено. Кенни Грип взломал мне версию, чтобы просто пропустить эту проверку, и Кенни также сообщил о ней для включения в будущий выпуск Percona Toolkit, но в то же время вам нужно обойти отсутствие привилегии SUPER.
- pt-table-sync является медленным против RDS. Поскольку pt-table-sync не регистрирует много подробностей о том, на что тратится время, я не полностью изолировал источник задержки, но я подозреваю, что это больше касается обхода сети, чем чего-либо еще.
- innodb_log_file_size is hardcoded to 128MB in Amazon RDS, you can’t change this. innodb_log_files_in_group is not even showing up in Parameter Groups view but SHOW GLOBAL VARIABLES reports as 2. So you’re cookin’ on 256MB, if your writes are heavy this may become a bottleneck with little workaround available in MySQL.
- CHANGE MASTER isn’t available in RDS. You define RDS as a slave by calling a stored procedure where you pass the appropriate options such as CALL mysql.rds_set_external_master.
For those of you wondering about the SUPER-privilege, I was fortunate that Bill Karwin from Percona’s Support team took the time to review my post and suggested I dig into this deeper, turns out that Amazon didn’t hack MySQL to remove the SUPER privilege, but instead run the Stored Procedures with security_type of DEFINER:
mysql> select db,name,type,language,security_type,definer from proc where name = 'rds_external_master' G *************************** 1. row *************************** db: mysql name: rds_external_master type: PROCEDURE language: SQL security_type: DEFINER definer: rdsadmin@localhost 1 row in set (0.08 sec)
mysql> show grants for 'rdsadmin'@'localhost'; +------------------------------------------------------------------------------------------------------+ | Grants for rdsadmin@localhost | +------------------------------------------------------------------------------------------------------+ | GRANT ALL PRIVILEGES ON *.* TO 'rdsadmin'@'localhost' IDENTIFIED BY PASSWORD 'XXX' WITH GRANT OPTION | +------------------------------------------------------------------------------------------------------+ 1 row in set (0.07 sec)
So for those of you working with Amazon RDS, I hope that this list saves you some time and helps our your migration! If you get stuck you can always contact Percona Consulting for assistance.