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

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

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

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

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


mysql database innodb drupal-7 myisam
person MiBerG    schedule 29.01.2013    source источник
comment
Какой именно этап миграции занимает эти 20 часов? Если это изменение механизма хранения, то вы бы просто отложили это время, не так ли?   -  person a_horse_with_no_name    schedule 29.01.2013
comment
@a_horse_with_no_name Для каждого объекта данных для миграции - в данном случае пользовательских объектов - класс миграции, который наследуется от базового модуля миграции, должен быть разработан в отдельном модуле. Затем этот класс должен быть адресован и выполнен модулем миграции (и соответствующими вспомогательными модулями). Процесс миграции этого класса запускается командой оболочки с использованием модуля drush. Эта процедура позволяет другим установленным модулям вызывать обработчики импортированных данных в процессе миграции. Непонятно, какие подпроцессы занимают столько времени.   -  person MiBerG    schedule 29.01.2013
comment
Может быть, я не прояснил это: процесс миграции не работает на месте. Он не изменяет ни данные в базе данных D6, ни механизм хранения указанной базы данных. Даны две базы данных: база данных A, содержащая данные сайта D6 и использующая MyISAM в качестве механизма хранения, и база данных B, новый сайт D7, использующий InnoDB. Модули, отвечающие за процесс миграции, устанавливаются на сайте D7 и извлекают данные, которые предполагается перенести на сайт D7, из базы данных D6. Процесс миграции не влияет на механизмы хранения двух баз данных.   -  person MiBerG    schedule 29.01.2013
comment
Так почему вы думаете, что все будет быстрее, если вы потом поменяете хранилище? Это определенно добавит дополнительное время к миграции, тогда как я сомневаюсь, что миграция будет намного быстрее, если целью является MyISAM.   -  person a_horse_with_no_name    schedule 29.01.2013
comment
Уже доказано, что миграция выполняется быстрее, @a_horse_with_no_name. Если база данных A использует MyISAM, а база данных B использует InnoDB, обрабатывается около 100 записей в минуту. Если база данных B настроена на использование MyISAM, пропускная способность увеличивается примерно до 1100 в минуту. У меня вопрос, может ли переключение целевой БД с InnoDB на MyISAM и после перехода обратно на InnoDB нанести какой-либо вред данным, структуре или индексам БД.   -  person MiBerG    schedule 29.01.2013

Ответы (2)


arrow_upward
4
arrow_downward

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

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

person jeremycole    schedule 30.01.2013
comment
Спасибо за ваш вклад, Джереми. Я уже оптимизировал сервер для этого процесса. Установка переменной innodb_flush_log_at_trx_commit на «0» была одной из настроек, которые я использовал для улучшения среды MySQL. Производительность увеличилась на 40% (с 70 до 100 в минуту). Прорыв был достигнут путем установки механизма хранения с InnoDB на MyISAM (более 1000 в минуту), что заставляет меня подозревать, что может быть проблема с подпрограммами модуля или даже Drupal для обработки запросов к базам данных InnodDB. Мой вопрос в том, может ли смена механизмов хранения испортить мою базу данных. - person MiBerG; 31.01.2013

arrow_upward
0
arrow_downward

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

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

person user2656474    schedule 14.08.2013