Alcune tabelle Magento non sono InnoDB, è sicuro convertire tutte le tabelle in InnoDB?


16

Sto usando AWS RDS Leggi Replica. Ha costantemente problemi con le tabelle del motore di memoria di Magento. Per le copie di backup e di lettura RDS ama InnoDB. Posso cambiare in sicurezza tutte le tabelle in InnoDB?

Inoltre, ricevo il seguente avviso da AWS:

L'istanza DB magento-monin-prod-db contiene tabelle MyISAM che non sono state migrate su InnoDB. Queste tabelle possono influire sulla tua capacità di eseguire ripristini temporizzati. Valuta la possibilità di convertire queste tabelle in InnoDB. Fare riferimento a http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#MySQL.CommonDBATasks.Tables

Risposta plausibile

Ancora interessato al feedback. Aggiungerò questo come risposta se non trovo problemi entro le prossime 24 ore. I passaggi che ho seguito di seguito sembrano essere sicuri, finora. La mia più grande preoccupazione erano le tabelle del motore di memoria di Magento (tabelle che terminano in_tmp) e l'impatto che potrebbe avere sull'indicizzazione.

Ecco cosa ho fatto:

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

    • Per me questo ha restituito principalmente tabelle di indici temporanee e tabelle di moduli magento, quindi non ci sono molte tabelle fondamentali critiche di cui preoccuparsi e poche tabelle sufficienti che posso facilmente eseguire un'altra tabella altera se roba colpisce la ventola.
  2. Per ogni tabella restituita ho eseguito: Alter table {table-name} ENGINE=InnoDB;

Sarei nervoso per provare questo se nessuno dei tuoi tavoli è InnoDB. Ma, come ho detto prima, c'erano solo alcune tabelle di base sulla mia istanza che dovevano essere modificate.


Hai gestito questo in produzione a lungo? In tal caso, come sta andando - ti ha causato problemi? Pensando principalmente alle tabelle di indice * _tmp che sono attualmente il motore MEMORY.
Michael Parkin,

1
Non ho notato nulla di insolito.
TylersSN,

Fantastico, grazie per la conferma - ci proveremo e riporteremo anche questo.
Michael Parkin,

@michael parkin tieni presente che stiamo usando la ricerca Solr. Vedi le altre risposte che parlano di come ciò potrebbe influire sulla ricerca.
TylersSN,

1
Abbiamo eseguito questo nella maggior parte dei nostri siti di produzione (MariaDB 10.0), tutti i tavoli (compresa la memoria) in esecuzione come InnoDB - funzionano alla grande
Michael Parkin

Risposte:


11

È possibile modificare il tipo di dati in InnoDB, presupponendo che sia vera una delle seguenti condizioni:

  1. Stai utilizzando MySQL 5.6.4+ in cui il motore di archiviazione InnoDB supporta la ricerca full-text
  2. Non stai utilizzando la funzionalità di ricerca Magento predefinita che si basa sulle funzionalità di ricerca full-text MyISAM sottostanti. Quella funzionalità è problematica per cominciare e il set di funzionalità fornito in Magento Search predefinito lascia molto a desiderare, quindi suggerirei di usare Lucene o Sphinx o la migliore ricerca ospitata dell'Algolia .

Personalmente consiglierei di farlo con Magento DB Repair Tool per ridurre al minimo i rischi e anche verificare eventuali altri errori o problemi di configurazione del DB. InnoDB è il motore ideale, nonostante le limitazioni full- text.


1
Stiamo usando la ricerca solare. Quindi, dovremmo essere in chiaro per quanto riguarda la ricerca.
TylersSN,

Non considererei affatto InnoDB il motore ideale. È estremamente lento rispetto a MyISAM se hai molte query di ricerca. Ho sentito spesso che InnoDB sta eseguendo gli aggiornamenti più velocemente e la maggior parte delle query sono aggiornamenti, quindi è più veloce. Vedo il contrario totale. Per ogni sito che ho, ho molte più query di ricerca che aggiornano / aggiungono query. Ho provato a cambiare tutte le mie tabelle in InnoDB e il tempo di caricamento della pagina è passato da praticamente nessun ritardo (forse 0,1 secondi) a 10 secondi! Ho riconvertito tutto in MyISAM perché è il motore ideale per la velocità (e supporta la ricerca full-text).
Tim Eckel,

Tim, sono "gentile" di essere d'accordo, soprattutto perché ho visto più volte che @ ben-lessani-sonassi è semplicemente dimostrato provato e MySQL raramente è un vero freno alla perf complessiva con il numero di ALTRI sistemi che bisogno di ottimizzazione per le risposte al di sotto di 800 ms anche a carico MA INnoDB è la chiave b / c Mage Core sta scrivendo su DB ~ 10X per registrare ogni azione "view" di ogni utente più Solr è la cosa migliore per ricerca perf & qualilty :)
Bryan 'BJ' Hoffpauir Jr.

1
Quindi, in che modo la conversione di ciò che dovrebbe essere InnoDB gestisce tutte quelle relazioni di chiave esterna e quanto sono complete le eliminazioni che dipendono dall'eliminazione in cascata da quelle relazioni chiave? In altre parole, come gestisci i rifiuti che rimarranno non avendo le relazioni in atto?
Fiasco Labs,

@FiascoLabs È passato un po 'di tempo da quando ho controllato questo thread di commenti, ma l'obiettivo del Q / A è convertire DA MyISAM a InnoDB. Immagino che quelli che hanno le caratteristiche relazionali che probabilmente menzioni siano già InnoDB. MyISAM non supporta FK né Transazioni a partire da MySQL 5.7 anche se InnoDB lo fa anche se si discosta un po
'


2

Ho appena cambiato il motore predefinito di MySQL in InnoDB e la maggior parte dei miei tavoli Magento si sono semplicemente trasformati miracolosamente in InnoDB (alcuni sono ancora MyISAM e alcuni sono Memory).

Ho pensato di condividere questo ...

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.