Quali sono le complicazioni se cambio Mysql a MariaDB? Qualche problema con Drush?

Ho un pesante sito Mysql drupal 7 e stavo pensando di passare Mysql a Mariadb , ma non ero sicuro di quali problemi avrei incontrato. Da quello che sto leggendo Mariadb sembra essere solo una goccia in sostituzione di Mysql e non sembra molto da giocherellare. Mi chiedevo se Mariadb avrebbe influenzato i comandi drush?

7 drush database

— Patoshi パトシ
fonte

ok ho i miei server tecnici per passare a mariadb. finora non abbiamo notato nulla di grave, ma dalla nostra esperienza abbiamo avuto molti problemi durante l'aggiornamento. Dato che eravamo su una versione precedente di cpanel, dovevamo prima aggiornare cpanel all'ultima versione, quindi aggiornare PHP, quindi aggiornare Mysql, quindi riportare la versione PHP su 5.2 per mantenere i problemi di compatibilità. Ora installiamo MariaDB. Ci sono volute 13 ore per questa transizione! Una lezione costosa devo dire, pensando che ci sarebbe voluta solo meno di un'ora. Prova prima la messa in scena! speriamo che questo abbia aiutato qualcuno, + rep se lo ha fatto! Grazie!

— Patoshi パトシ

Ci sono diversi problemi a cui pensare. Debian unix_socket predefinito è uno di questi. Mi chiedo che questi problemi non siano discussi molto. Presumo che molti abbiano i loro flussi di lavoro e continuino a seguire MySQL, ecco perché non è ben documentato. Permettetemi di collegarmi a un nuovo numero pubblicato per raccogliere alcune riflessioni su questo: drupal.stackexchange.com/questions/242634/…

— nilsun,

@nilsun Al contrario, praticamente tutti usano MariaDB in questi giorni. Ecco l'articolo canonico del Pantheon sul perché lo usano per centinaia di migliaia di siti Drupal, ad esempio: pantheon.io/blog/using-mariadb-mysql-replacement . I problemi di cui parli sembrano essere di nicchia, probabilmente è per questo che non riesci a trovare molte discussioni su di essi

— Clive

@Clive Grazie. Sono parzialmente d'accordo. Ma conti i grandi giocatori. Una piccola squadra di sviluppo è un'altra situazione. Se non c'è nessuno nel team con le competenze per correlare il comportamento del packaging Debian e le filosofie di MariaDB, PUOI (non è necessario) affrontare alcune piccole sfide dovute ai cambiamenti. E soprattutto quando si utilizza software di terze parti, che non dispone di messaggi di errore preparati per tali scenari.

— nilsun,

Risposte:

Volevo solo parlarne (anche se con mesi di ritardo) ... In passato hanno creato molti siti Drupal, questa volta ho deciso di fare le cose "meglio" e MariaDB era installato.

Tutto funziona meravigliosamente (più veloce, più pulito, ecc.) Con Drupal 7 EXCEPT per il backup / ripristino: / Devi sempre andare direttamente nel db (tramite PHPMyAdmin, Heidi o riga di comando) e copiare / esportare tutte le tabelle.

A parte questo, che potrebbe esserci una serie di ragioni per accadere, consiglio vivamente MariaDB. Meno risorse del server utilizzate, D7 è molto più veloce, ecc. Ecc.

— greysweatshirt
fonte

Ma questo thread non riguarda i pro e i contro di MariaDB e quanto è buono. Si tratta di domande ben ponderate sulle modifiche al flusso di lavoro di produzione da discutere con Drush. E ce ne sono diversi.

— nilsun,

Come dici tu, Maria DB è un sostituto drop-in completamente trasparente per MySQL. Le sue versioni coincidono con la stessa versione principale / secondaria di MySQL, quindi è praticamente sempre in tandem per quanto riguarda le funzionalità. Legge i file di dati binari standard di MySQL, utilizza lo standard my.cnf systen e ha persino un sostituto drop-in per InnoDB.

L'idea è che, per quanto riguarda la tua applicazione, pensa che si stia collegando a un server MySQL. Utilizza driver MySQL, rilascia dichiarazioni MySQL complete e riceve risposte esattamente come invierebbe il server MySQL. Le tue app non conosceranno la differenza.

Sto usando Maria da un po 'di tempo per i siti Drupal (anche usando ampiamente Drush) e finora non ho avuto un singolo problema. Se stai eseguendo * nix l'aggiornamento è solo un lavoro di due minuti.

— Clive
fonte

eccezionale. proprio quello che dovevo sapere. grazie!

— Patoshi パトシ

un'altra cosa è che faccio occasionalmente query sql tramite il terminale. quale sarebbe l'equivalente di fare un msyqldump? o trascina query sql 'seleziona * dagli utenti'

— Patoshi パトシ

Penso che mysqldump usi / usr / bin / mysql (o equivalente) internamente, e poiché Maria collega simbolicamente quel percorso alla sua stessa implementazione non avresti bisogno di apportare modifiche, semplicemente continua a usare mysqldump normalmente. Immagino che lo stesso valga per Drush. Potrebbe essere utile verificarlo, anche se per essere sicuri

— Clive

Google per "Problemi di accesso a Debian unix_socket MariaDB" ... Ci sono ancora cose da discutere e da documentare.

— nilsun,

@nilsun Non ho avuto esperienza di questi problemi: ho eseguito Drupal 7 su dozzine (probabilmente centinaia) di server supportati da MariaDB per anni senza problemi. Il Pantheon gestisce l'intera infrastruttura Drupal / Drush su MariaDB, e penso che anche Acquia. Potresti semplicemente utilizzare la versione / configurazione errata o avere un requisito di nicchia che provoca comportamenti strani. Tutti gli sviluppatori di agenzie che conosco usano anche MariaDB, non si sognerebbero di usare il semplice vecchio MySQL, quindi non sembrerebbe essere un problema comune (almeno nella mia esperienza)

— Clive

Ci sono diversi problemi di cui preoccuparsi. Il unix_socket problema di accesso alla radice Debian è solo uno di questi. Mi chiedo che questi problemi non siano discussi molto. Presumo che molti abbiano i loro flussi di lavoro e continuino a seguire MySQL . Ecco perché molti di questi problemi non sono ben documentati.

Correlati: MariaDB unix_socket causa problemi di accesso in Debian - Drush non riesce ad accedere (un nuovo post ha iniziato a raccogliere pensieri su questo.)

— nilsun
fonte