Деякі таблиці Magento не є InnoDB, чи безпечно конвертувати всі таблиці в InnoDB?


16

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

Крім того, я отримую таке попередження від AWS:

Базовий екземпляр DB magento-monin-prod-db містить таблиці MyISAM, які не були переміщені до InnoDB. Ці таблиці можуть вплинути на вашу здатність виконувати відновлення часу. Подумайте про перетворення цих таблиць у InnoDB. Зверніться до http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#MySQL.CommonDBATasks.Tables

Правдоподібна відповідь

Ще цікавлять відгуки. Я додам це як відповідь, якщо протягом найближчих 24 годин я не знайду жодних проблем. Наведені нижче кроки здаються безпечними. Моє найбільше занепокоєння викликало таблиці пам'яті Magento Memory Engine (таблиці, що закінчуються in_tmp) та вплив, який він може мати на індексацію.

Ось що я зробив:

  1. SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE (ENGINE = 'Memory' OR ENGINE='MyIsam') AND TABLE_SCHEMA='magento_db'

    • Для мене це повернуло здебільшого тимчасові таблиці індексів та таблиці модулів magento, тому не так багато критичних ядерних таблиць, про які слід турбувати, і мало таблиць, які я можу легко виконати іншу таблицю змін, якщо матеріал потрапить у вентилятор.
  2. Для кожної поверненої таблиці я виконав: Alter table {table-name} ENGINE=InnoDB;

Я б нервував спробувати це, якщо жодна з ваших таблиць не є InnoDB. Але, як я вже говорив раніше, у моєму екземплярі було лише кілька основних таблиць, які потрібно було змінити.


Ви давно керуєте цим виробництвом? Якщо так, як це відбувається - це викликало у вас якісь проблеми? Думаю в першу чергу про таблиці індексів * _tmp, які є двигуном ПАМ’ЯТЬ.
Майкл Паркін

1
Я не помітив нічого незвичайного.
TylersSN

Чудово, дякую за підтвердження - ми будемо дуже цікавими і повідомимо.
Майкл Паркін

@michael parkin майте на увазі, що ми використовуємо пошук Solr. Дивіться інші відповіді, які говорять про те, як це може вплинути на пошук.
TylersSN

1
Ми працювали над цим на більшості наших виробничих майданчиків (MariaDB 10.0), усі таблиці (включаючи пам'ять) працюють як InnoDB - прекрасно працює
Майкл Паркін

Відповіді:


11

Добре змінити тип даних на InnoDB, якщо припустити одне з наступних:

  1. Ви використовуєте MySQL 5.6.4+, де система зберігання InnoDB підтримує пошук у повному обсязі
  2. Ви не використовуєте функцію пошуку Magento за замовчуванням, яка покладається на основні можливості пошуку в повному обсязі MyISAM. Цей функціонал скрутний для початку, і набір функцій, що надаються в Magento Search за замовчуванням, залишає бажати кращого, тому я б запропонував використовувати Lucene або Сфінкс або найкраще ще розміщений пошук в Algolia .

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


1
Ми використовуємо Сонячний пошук. Отже, ми повинні бути чіткими, що стосується пошуку.
TylersSN

Я б взагалі не вважав InnoDB ідеальним двигуном. Це надзвичайно повільно порівняно з MyISAM, якщо у вас є багато пошукових запитів. Я часто чую, що InnoDB швидше робить оновлення, а більшість запитів - це оновлення. Я бачу повне протилежне. Для кожного веб-сайту у мене є набагато більше пошукових запитів, які оновлюють / додають запити. Я спробував переключити всі свої таблиці на InnoDB, і час завантаження сторінки в основному пішов від затримки (можливо, 0,1 секунди) до 10 секунд! Я перетворив все назад на MyISAM, тому що це ідеальний двигун для швидкості (і він підтримує повнотекстовий пошук).
Тім Еккель

Тім, я "НАПРАВЛІ" згоден, здебільшого тому, що я бачив раз і знову, що @ ben-lessani-sonassi - це просто виправдане перевірене правильність, а MySQL рідко справжнє перетягування на загальну перф у / з ІНШИХ систем, які потрібна оптимізація для відповідей до 800 мс навіть при завантаженні, але ІноДБ є ключовим b / c Mage Core пише в DB ~ 10X, щоб увійти в дію для кожного користувача "перегляд" плюс Solr найкраще шукати в першу чергу і кваліфіковано :)
Bryan 'BJ' Hoffpauir Молодший

1
Отже, як перетворення того, що повинно бути InnoDB, обробляє всі ці стосунки із зовнішніми ключами та наскільки повно завершені видалення, які залежать від видалення на каскаді з цих відносин fkey? Іншими словами, як ви поводитесь з туалетом, який залишиться, не маючи стосунків?
Лабораторії Фіаско

@FiascoLabs Минув час, коли я перевірив цей потік коментарів, але основна увага Q / A полягає в перетворенні з MyISAM в InnoDB. Я здогадуюсь, що ті, у яких є реляційні функції, про які ви згадуєте, мабуть, є InnoDB. MyISAM не підтримує FK ні транзакції, як MySQL 5.7, хоча InnoDB робить, хоча він трохи відхиляється від стандарту SQL
Брайан 'BJ' Hoffpauir Jr.

2

Afaik, ви не повинні перетворювати всі таблиці в InnoDB.

catalogsearch_fulltext повинен залишатися MyISAM, оскільки InnoDB не має підтримки пошуку в повному обсязі, принаймні не до MySQL 5.6 (iirc).

Для всіх інших таблиць він повинен бути безпечним.



2

Я щойно змінив двигун MySQL за замовчуванням на InnoDB, і більшість моїх таблиць Magento просто дивом перетворилися на InnoDB (деякі з них все ще є MyISAM, а деякі - пам'яттю).

Просто думав, що поділюсь цим ...

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.