Certaines tables Magento ne sont pas InnoDB, est-il sûr de convertir toutes les tables en InnoDB?


16

J'utilise AWS RDS Read Replica. Il a constamment des problèmes avec les tables du moteur de mémoire de Magento. Pour les répliques de sauvegarde et de lecture, RDS adore InnoDB. Puis-je changer toutes les tables en toute sécurité en InnoDB?

De plus, je reçois l'avertissement suivant d'AWS:

L'instance DB magento-monin-prod-db contient des tables MyISAM qui n'ont pas été migrées vers InnoDB. Ces tableaux peuvent affecter votre capacité à effectuer des restaurations ponctuelles. Pensez à convertir ces tables en InnoDB. Veuillez vous référer à http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#MySQL.CommonDBATasks.Tables

Réponse plausible

Toujours intéressé par les commentaires. J'ajouterai ceci comme réponse si je ne trouve aucun problème dans les prochaines 24 heures. Jusqu'à présent, les mesures que j'ai prises semblent être sûres. Ma plus grande préoccupation était les tables Memory Engine de Magento (tables se terminant par_tmp) et l'impact que cela pourrait avoir sur l'indexation.

Voici ce que j'ai fait:

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

    • Pour moi, cela a renvoyé principalement des tables d'index temporaires et des tables de modules magento, donc pas beaucoup de tables de base critiques à craindre et peu de tables que je peux facilement exécuter une autre table alter si des trucs frappent le ventilateur.
  2. Pour chaque table retournée, j'ai exécuté: Alter table {table-name} ENGINE=InnoDB;

Je serais nerveux d'essayer ceci si aucune de vos tables n'est InnoDB. Mais, comme je l'ai déjà dit, il n'y avait que quelques tables de base sur mon instance qui devaient être modifiées.


L'utilisez-vous depuis longtemps en production? Si oui, comment ça se passe - cela vous a-t-il causé des problèmes? Penser principalement aux tables d'index * _tmp qui sont actuellement le moteur MEMORY.
Michael Parkin

1
Je n'ai rien remarqué d'inhabituel.
TylersSN du

Super, merci d'avoir confirmé - nous allons essayer et faire un rapport aussi.
Michael Parkin

@michael parkin gardez à l'esprit que nous utilisons la recherche Solr. Consultez les autres réponses qui expliquent comment cela pourrait potentiellement affecter la recherche.
TylersSN

1
Nous l'avons exécuté dans la plupart de nos sites de production (MariaDB 10.0), toutes les tables (y compris la mémoire) fonctionnant en tant qu'InnoDB - fonctionne très bien
Michael Parkin

Réponses:


11

Il est correct de changer le type de données en InnoDB, en supposant que l'une des conditions suivantes est vraie:

  1. Vous utilisez MySQL 5.6.4+ où le moteur de stockage InnoDB prend en charge la recherche plein texte
  2. Vous n'utilisez pas la fonctionnalité de recherche par défaut de Magento qui repose sur les capacités de recherche sous-jacentes de MyISAM en texte intégral. Cette fonctionnalité est gênante au départ et l'ensemble des fonctionnalités fournies dans la recherche par défaut de Magento laisse beaucoup à désirer, je suggère donc d'utiliser Lucene ou Sphinx ou la meilleure recherche hébergée en Algérie .

Personnellement, je recommanderais de le faire avec l' outil de réparation Magento DB pour minimiser les risques et vérifier également toute autre dérive ou problème de configuration DB. InnoDB est le moteur idéal, malgré ses limitations fulltext .


1
Nous utilisons la recherche solaire. Donc, nous devons être clairs en ce qui concerne la recherche.
TylersSN

Je ne considérerais pas du tout InnoDB comme le moteur idéal. C'est extrêmement lent par rapport à MyISAM si vous avez beaucoup de requêtes de recherche. J'entends souvent que InnoDB est plus rapide à faire des mises à jour et la plupart des requêtes sont des mises à jour, donc c'est plus rapide. Je vois le contraire. Pour chaque site que j'ai, j'ai beaucoup plus de requêtes de recherche qui mettent à jour / ajoutent des requêtes. J'ai essayé de passer toutes mes tables à InnoDB et le temps de chargement des pages est passé de pratiquement aucun délai (peut-être 0,1 seconde) à 10 secondes! J'ai tout reconverti en MyISAM car c'est le moteur idéal pour la vitesse (et il supporte la recherche plein texte).
Tim Eckel du

Tim, je "GENRE" d'accord, principalement parce que j'ai vu maintes et maintes fois que @ ben-lessani-sonassi est tout simplement prouvé et MySQL est rarement un réel frein à la performance globale avec le nombre d'autres systèmes qui besoin d'optimisation pour les réponses inférieures à 800 ms, même à charge MAIS InnoDB est la clé b / c Mage Core écrit dans DB ~ 10X pour enregistrer chaque action "voir" de l'utilisateur, plus Solr est le meilleur pour la recherche et la qualité :)
Bryan 'BJ' Hoffpauir Jr.

1
Alors, comment la conversion de ce qui est censé être InnoDB gère-t-elle toutes ces relations de clés étrangères et à quel point les suppressions qui dépendent de la suppression en cascade de ces relations fkey sont-elles complètes? En d'autres termes, comment gérez-vous la litière qui restera en n'ayant pas les relations en place?
Fiasco Labs

@FiascoLabs Cela fait un moment que je n'ai pas vérifié ce fil de commentaires, mais l'objectif de la Q / A est de convertir FROM MyISAM TO InnoDB. Je suppose que ceux qui ont les fonctionnalités relationnelles que vous mentionnez sont probablement déjà InnoDB. MyISAM ne prend pas en charge FK ni les transactions à partir de MySQL 5.7, bien qu'InnoDB le fasse bien qu'il s'écarte un peu du standard SQL
Bryan 'BJ' Hoffpauir Jr.


2

Je viens de changer le moteur par défaut MySQL en InnoDB et la plupart de mes tables Magento se sont miraculeusement transformées en InnoDB (certains sont toujours MyISAM et certains sont Memory).

Je pensais juste partager ça ...

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.