Некоторые таблицы Magento не являются InnoDB, безопасно ли конвертировать все таблицы в InnoDB?

Я использую AWS RDS Read Replica. У него постоянно возникают проблемы с таблицами движка памяти Magento. За резервное копирование и чтение реплик RDS любит InnoDB. Могу ли я смело менять все таблицы на InnoDB?

Кроме того, я получаю следующее предупреждение от AWS:

Инстанс БД magento-monin-prod-db содержит таблицы MyISAM, которые не были перенесены в InnoDB. Эти таблицы могут повлиять на вашу способность выполнять восстановление на определенный момент времени. Рассмотрите возможность преобразования этих таблиц в InnoDB. Пожалуйста, обратитесь к http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#MySQL.CommonDBATasks.Tables

Правдоподобный ответ

Еще интересует обратная связь. Я добавлю это как ответ, если я не найду никаких проблем в течение следующих 24 часов. Шаги, которые я предпринял ниже, пока что безопасны. Больше всего меня беспокоили таблицы подсистемы памяти Magento (таблицы, заканчивающиеся на in_tmp) и их влияние на индексирование.

Вот что я сделал:

SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE (ENGINE = 'Memory' OR ENGINE='MyIsam') AND TABLE_SCHEMA='magento_db'
- Для меня это возвращало в основном временные таблицы индексов и таблицы модулей magento, так что не так много критических основных таблиц, о которых нужно беспокоиться, и достаточно мало таблиц, чтобы я мог легко выполнить другую таблицу изменения, если что-то попало в вентилятор.
Для каждой возвращенной таблицы я выполнил: Alter table {table-name} ENGINE=InnoDB;

Я бы нервничал, чтобы попробовать это, если ни один из ваших столов не InnoDB. Но, как я уже говорил, в моем экземпляре было только несколько основных таблиц, которые нужно было изменить.

— TylersSN
источник

Вы долго работали над этим? Если так, как дела - это вызвало у вас какие-либо проблемы? Думая прежде всего о индексных таблицах * _tmp, которые в настоящее время являются механизмом MEMORY.

— Майкл Паркин

Я не заметил ничего необычного.

— TylersSN

Отлично, спасибо за подтверждение - мы тоже попробуем и сообщим.

— Майкл Паркин

@Michael Parkin Имейте в виду, что мы используем поиск Solr. Посмотрите другие ответы, которые говорят о том, как это может повлиять на поиск.

— TylersSN

Мы выполняли это на большинстве наших производственных площадок (MariaDB 10.0), все таблицы (включая память), работающие как InnoDB - прекрасно работают

— Майкл Паркин

Ответы:

Можно изменить тип данных на InnoDB, предполагая, что выполняется одно из следующих условий:

Вы используете MySQL 5.6.4+, где механизм хранения InnoDB поддерживает полнотекстовый поиск
Вы не используете функцию поиска Magento по умолчанию, которая опирается на базовые возможности полнотекстового поиска MyISAM. Эта функциональность хлопотно для начала и набор функций при условии , по умолчанию в Magento поиска оставляет желать лучшего , так что я предложил бы использовать Lucene или Sphinx или еще лучше Algolia организовано поиск.

Лично я бы порекомендовал сделать это с помощью Magento DB Repair Tool, чтобы минимизировать риск, а также проверить наличие любых других проблем с конфигурацией БД. InnoDB - идеальный движок, несмотря на полнотекстовые ограничения .

— Брайан 'BJ' Хоффпауир младший
источник

Мы используем Солнечный поиск. Итак, мы должны быть в курсе, что касается поиска.

— TylersSN

Я бы не стал считать InnoDB идеальным двигателем. Это очень медленно по сравнению с MyISAM, если у вас много поисковых запросов. Я часто слышу, что InnoDB быстрее выполняет обновления, и большинство запросов являются обновлениями, поэтому это быстрее. Я вижу полную противоположность. Для каждого сайта у меня есть гораздо больше поисковых запросов, которые обновляют / добавляют запросы. Я попытался переключить все свои таблицы на InnoDB, и время загрузки страницы практически не изменилось (возможно, 0,1 секунды) до 10 секунд! Я преобразовал все обратно в MyISAM, потому что это идеальный движок для скорости (и он поддерживает полнотекстовый поиск).

— Тим Экель

Тим, я "ВИДЕ" согласен, в основном потому, что я снова и снова видел, что @ ben-lessani-sonassi просто доказал свою правоту, а MySQL редко является РЕАЛЬНЫМ тормозом для всех систем с # ДРУГИМИ системами, которые нужна оптимизация для ответов менее 800 мс даже при загрузке, НО InnoDB является ключевым, поскольку Mage Core записывает в БД ~ 10X для регистрации действий каждого пользователя «просмотра», плюс Solr лучше всего подходит для поиска и качества :)

— Bryan 'BJ' Hoffpauir Младший

Итак, как преобразование того, что должно быть InnoDB, обрабатывает все эти отношения внешнего ключа и насколько полными являются удаления, которые зависят от удаления на каскаде из этих отношений fkey? Другими словами, как вы справляетесь с мусором, который останется без наличия отношений?

— Fiasco Labs

@FiascoLabs Прошло много времени с тех пор, как я проверил эту ветку комментариев, но основная задача Q / A - конвертировать из MyISAM в InnoDB. Я предполагаю, что те, которые имеют реляционные функции, о которых вы упомянули, вероятно, уже являются InnoDB. MyISAM не поддерживает ни FK, ни Транзакции с MySQL 5.7, хотя InnoDB делает, хотя и немного отклоняется от стандарта SQL

— Брайан 'BJ' Хоффпауир-младший,

Afaik вы не должны конвертировать все таблицы в InnoDB.

catalogsearch_fulltext должен остаться MyISAM, потому что InnoDB не имеет поддержки полнотекстового поиска, по крайней мере, до MySQL 5.6 (iirc).

Однако для всех остальных таблиц это должно быть безопасно.

— simonthesorcerer
источник

Это поддерживается в MySQL 5.6.4+

— Брайан 'BJ' Хоффпауир-младший

Я просто изменил движок MySQL по умолчанию на InnoDB, и большинство моих таблиц Magento просто чудесным образом превратились в InnoDB (некоторые из них все еще MyISAM, а некоторые - Memory).

Просто подумал, что поделюсь этим ...

— Рой Толедо
источник