Каковы последствия преобразования механизма хранения базы данных MySQL из InnoDB в MyISAM и обратно (для Drupal 7)?

Я занимаюсь модернизацией среднего масштаба (пользователи 200k +) Drupal 6 CMS для Drupal 7. Перенос данных будет обрабатывается с помощью Миграция модуля . До и включая Drupal версии 6 MyISAM был механизмом хранения MySQL по умолчанию для базы данных Drupal. С версии Drupal 7 рекомендуется InnoDB. В соответствии с этим, классы миграции, которые я разработал, должны перенести данные из старой D6 MyISAM DB в новую D7 InnoDB DB.

У меня возникают серьезные проблемы с производительностью при запуске сценариев миграции: миграция профилей пользователей 200k + займет более 20 часов на «большом» экземпляре сервера Amazon Web Services, который фактически оптимизирован для этой цели. Такие проблемы с производительностью не являются редкостью для миграций с использованием указанного модуля миграции, как я узнал из чтения трекера по проблемам модуля. Тем не менее, я нашел решение увеличить производительность в десять раз, преобразовывая D7 DB из InnoDB в MyISAM.

Теперь вот вопрос: так как мне придется запускать D7 DB с помощью механизма хранения InnoDB, как только он снова будет использоваться пользователями, интересно, может ли это означать любой вред для БД, если я установил механизм хранения в MyISAM для продолжительность процесса миграции, а затем обратно в InnoDB?

Спасибо за вашу помощь.

1
nl ja de
Какой именно шаг миграции занимает эти 20 часов? Если это изменение механизма хранения, то вы просто отложите это время, не так ли?
добавлено автор a_horse_with_no_name, источник
Итак, почему вы думаете, что все это будет быстрее, если вы впоследствии измените хранилище? Это определенно добавит дополнительное время для миграции, тогда как я сомневаюсь, что миграция будет намного быстрее, если целью является MyISAM
добавлено автор a_horse_with_no_name, источник
@a_horse_with_no_name Для каждого объекта данных для переноса - объекты пользователя в этом случае - класс переноса, который наследуется от базового модуля миграции, должен быть разработан в отдельном модуле. Затем этот класс должен быть адресован и выполнен модулем миграции (и связанными вспомогательными модулями). Процесс миграции в отношении этого класса запускается командой оболочки с помощью drush module . Эта процедура позволяет другим установленным модулям вызывать зависания импортированных данных во время процесса миграции. Неясно, какие подпрограммы (ses) занимают много времени.
добавлено автор MiBerG, источник
Возможно, я не сделал этого ясно: процесс миграции не работает на месте. Он не изменяет данные в базе данных D6 или механизм хранения указанной базы данных. Даны две базы данных: База данных A, содержащая данные сайта D6 и использование MyISAM в качестве механизма хранения, и база данных B, новый сайт D7 с использованием InnoDB. Модули, ответственные за процесс миграции, устанавливаются на сайте D7 и извлекают данные, которые должны быть перенесены на сайт D7, из базы данных D6. Процесс миграции не влияет на механизмы хранения данных двух баз данных.
добавлено автор MiBerG, источник
Уже доказано, что миграция выполняется быстрее, @a_horse_with_no_name. Если база данных A использует MyISAM, в то время как база данных B использует InnoDB, обрабатывается около 100 записей в минуту. Если в базе данных B установлено значение MyISAM вместо этого, пропускная способность увеличивается примерно до 1100/мин. Мой вопрос заключается в том, переключается ли целевая БД с InnoDB на MyISAM, а после перехода обратно в InnoDB может нанести какой-либо вред данным, структуре или индексам БД.
добавлено автор MiBerG, источник

2 ответы

Если вы видите очень большую разницу в производительности между InnoDB и MyISAM, очень вероятно, что причина связана с транзакционными гарантиями, которые делает InnoDB. Установка переменной innodb_flush_log_at_trx_commit в 0 во время миграции должна позволить вам достичь очень хорошей производительности на время миграции, а затем вы можете вернуть ее обратно в 1 после завершения миграции.

Безопасно менять «на лету»; однако, вы должны заметить, что если сервер выходит из строя, когда он установлен в 0 , вы можете потерять некоторые транзакции (но для вашей миграции я бы предположил, что оговорка в порядке).

4
добавлено
Спасибо за ваш вклад, jeremy. Я уже оптимизировал сервер для этого процесса. Установка переменной 'innodb_flush_log_at_trx_commit' в '0' была одним из параметров, которые я использовал для улучшения среды MySQL. Пропускная способность была улучшена на 40% (от 70/мин до 100/мин). Прорыв был достигнут путем установки механизма хранения от InnoDB до MyISAM (более 1000/мин), что приводит меня к подозрению, что может возникнуть проблема с модулями модуля или даже с Drupal для обработки запросов в базах данных InnodDB. Мой вопрос заключается в том, может ли изменение движка хранения испортить мою базу данных.
добавлено автор MiBerG, источник

вы также можете изменить переменную sync_binlog до 0 ant, а также увеличить скорость до 20%, а после миграции вы можете установить ее на 1.

но между ними, если между процессом будет некоторый сбой питания, вы можете потерять некоторые данные. но я думаю, что вы просто переносите данные, тогда это не займет много времени, и вероятность сбоя питания будет очень низкой.

0
добавлено
DBA - русскоговорящее сообщество
DBA - русскоговорящее сообщество
1 345 участник(ов)

Общаемся и обсуждаем темы, посвященные DBA, PostgreSQL, Redis, MongoDB, MySQL, neo4j, riak и т.д. См. также: @devops_ru, @kubernetes_ru, @docker_ru, @nodejs_ru Рекомендуем сразу отключить уведомления, чтобы пребывание здесь было полезным и комфортным.

MySQL
MySQL
995 участник(ов)

The group is about MySQL. For code use hastebin.com. Admin: @smlkw

dbGeeks
dbGeeks
545 участник(ов)

Чат про базы данных, их устройство и приемы работы с ними. Разрешаются любые адеватные дискуссии в рамках тематики чата.

Разработка СУБД
Разработка СУБД
143 участник(ов)