Come ottimizzare l'architettura del database per siti ad alto volume?

La domanda riguarda meno elementi di configurazione specifici di Mysql, ma più informazioni sulla gestione di più database, la suddivisione di lettura e scrittura su più server di database, master + master? Master + Multiple Slaves?

Con quali persone ha avuto la migliore esperienza e ci sono esempi su come raggiungere questo obiettivo?

Abbiamo un'esperienza abbastanza vasta di cluster MySQL e Percona ha lavorato con noi in diverse occasioni spingendo i confini di configurazioni complesse.

Magento può gestire nativamente gli schiavi di sola lettura

Magento è in grado di suddividere nativamente letture / scritture su diversi server di database (ad eccezione di alcune versioni non funzionanti, ad esempio EE 1.11) - che consente di spostare il selectcarico su un (o più) server (i) aggiuntivo; e inoltrando tutte le update/writequery a un unico master.

Quando dovrei farlo

Questa è una domanda più appropriata. Con i sistemi operativi Magento dedicati come MageStack , sta diventando sempre più comune la disponibilità e l'utilizzo di tecniche di caching avanzate integrate sul lato server (come la cache front-end Varnish e la cache back-end Redis).

Storicamente, Magento non è mai stato vincolato da MySQL, ma piuttosto da PHP. Ma poiché Varnish e Full Page Caching (FPC) vengono utilizzati più frequentemente, l'onere di attività ripetute (categoria / carichi di prodotto, ricerche frequenti) viene improvvisamente assorbito e PHP diventa meno oneroso. In effetti, entra in gioco solo per generare inizialmente il contenuto o completare scenari non memorizzabili (aggiungi al carrello, completamento dell'ordine ecc.); ai fini della spiegazione stiamo deliberatamente ignorando il carico amministrativo .

Abbiamo sempre sostenuto il fatto che MySQL non è motivo di preoccupazione per la maggior parte dei rivenditori, come visto sia qui che qui . Ma se ti trovi nella zona di elaborazione di centinaia di ordini all'ora, non di singole o doppie cifre, diventerà presto un'area di ottimizzazione.

In definitiva per negozi più piccoli (<25.000 visitatori unici giornalieri)

I tuoi sforzi si concentrerebbero molto meglio sulla semplice ricerca di un host appropriato che possa suggerire l'hardware giusto per essere attivato dall'offset e che abbia configurato la macchina nel modo più ottimale per il tuo negozio . Non perdere tempo a cercare configurazioni Master / Slave o Master / Master, che non produrranno alcun vantaggio in termini di prestazioni e richiederanno in definitiva attenzione continua e conoscenza avanzata di MySQL.

In definitiva, il dimensionamento e la selezione dell'hardware avranno un ruolo maggiore rispetto all'ottimizzazione di MySQL.

Ma per i negozi più grandi

Man mano che il tuo negozio inizia a crescere, il carico di conversione o transazionale diventa più un peso con il compito ripetuto di completare complessi insertse updates. L'aggiunta di ogni nuovo ordine attiverà il decremento delle scorte di catalogo, i callback dai gateway di pagamento e gli aggiornamenti dai sistemi EPOS / ERP. Combinalo con l'eliminazione della cache associata dei rispettivi prodotti / categorie e vedrai presto aumentare il carico di MySQL in modo sproporzionato.

Il multi-master non è mai una soluzione che raccomandiamo o consideriamo come un'opzione praticabile, ma Master / Slave può produrre vantaggi (sottolineiamo, su negozi di dimensioni Enterprise) spostando il carico di lettura su nodi secondari / terziari.

Ma voglio ancora farlo

Per prima cosa configura i tuoi schiavi. Siamo grandi sostenitori delle utility Percona e delle filiali MySQL - hanno uno strumento ideale per eseguire backup a caldo del tuo database esistente - innobackupex. C'è una buona scrittura qui .

Sul maestro

Sostituisci $ TIMESTAMP o scheda completa.

mysql
> GRANT REPLICATION SLAVE ON *.*  TO 'repl'@'$slaveip' IDENTIFIED BY '$slavepass';
> quit;
innobackupex --user=username --password=password /path/to/backupdir
innobackupex --user=username --password=password /
       --apply-log /path/to/backupdir/$TIMESTAMP/

rsync -avprP -e ssh /path/to/backupdir/$TIMESTAMP TheSlave:/path/to/mysql/
scp /etc/mysql/my.cnf TheSlave:/etc/mysql/my.cnf

Sullo schiavo

/etc/init.d/mysql stop
mv /path/to/mysql/datadir /path/to/mysql/datadir_bak
mv /path/to/mysql/$TIMESTAMP /path/to/mysql/datadir
chown -R mysql:mysql /path/to/mysql/datadir
sed -i 's#server-id=1#server-id=2#g' /etc/mysql/my.cnf
/etc/init.d/mysql start
cat /var/lib/mysql/xtrabackup_binlog_info
> TheMaster-bin.000001     481

mysql
> CHANGE MASTER TO MASTER_HOST='$masterip', MASTER_USER='repl', MASTER_PASSWORD='$slavepass', MASTER_LOG_FILE='TheMaster-bin.000001', MASTER_LOG_POS=481;
> START SLAVE;

Quindi, una volta che lo slave è operativo, in pratica, bastano poche righe di codice aggiuntive per raggiungere.

Nel ./app/etc/local.xml

<default_read>
  <connection>
    <use/>
    <host><![CDATA[host]]></host>
    <username><![CDATA[username]]></username>
    <password><![CDATA[password]]></password>
    <dbname><![CDATA[dbname]]></dbname>
    <type>pdo_mysql</type>
    <model>mysql4</model>
    <initStatements>SET NAMES utf8</initStatements>
    <active>1</active>
  </connection>
</default_read>

fonti

In generale Magento è associato alla CPU, non al database e la maggior parte dell'attività della CPU può essere memorizzata nella cache, motivo per cui troverai così tanti tutorial sulle configurazioni varnish / nginx. Puoi anche spostare il tuo amministratore in un webnode separato come dettagliato qui .

Per robustezza generale, il miglior rapporto qualità-prezzo per buck sarà un servizio MySQL gestito.

Ho solo esperienza con Amazon RDS, ma automatizzano il failover, i backup, gli aggiornamenti, il ridimensionamento su / giù e la creazione di repliche di lettura. Quindi puoi avere un nodo master ad alta disponibilità con failover automatico: Amazon utilizza una replica del registro binario personalizzata per mantenere sincronizzato lo slave, il failover richiede in genere meno di 2 minuti e quindi puoi creare quante repliche di lettura è necessario ridimensionare le esigenze di reporting / integrazione.

Ho cercato di dividere letture / scritture che è molto fattibile con l'architettura di Magento, ma il database non è un collo di bottiglia nel mio caso d'uso. Consiglio vivamente di utilizzare la profilazione come xhprof / xhgui piuttosto che indovinare ciò che deve essere ottimizzato. La prima regola della profilazione è misurare.

Non ho avuto alcuna esperienza di produzione con questo, ma dopo alcuni scavi ho trovato questo articolo. In questo articolo qualcuno spiega come impostare la replica master-slave per Magento, quindi potrebbe esserti utile.

Bit più importante:

/app/etc/local.xml

<default_setup>
    <connection>
        <host><![CDATA[Master-host]]></host>
        <username><![CDATA[user]]></username>
        <password><![CDATA[pass]]></password>
        <dbname><![CDATA[magentodb]]></dbname>
        <active>1</active>
    </connection>
</default_setup>
<default_read>
    <connection>
        <use/>
        <host><![CDATA[Slave-host]]></host>
        <username><![CDATA[user]]></username>
        <password><![CDATA[pass]]></password>
        <dbname><![CDATA[magento]]></dbname>
        <type>pdo_mysql</type>
        <model>mysql4</model>
        <initStatements>SET NAMES utf8</initStatements>
        <active>1</active>
    </connection>
</default_read> 

La configurazione per il server MySQL principale (/etc/mysql/my.cnf) aggiunge il contenuto seguente nel file:

[mysqld]
server-id       = 1
log_bin         = /var/log/mysql/mysql-bin.log
expire_logs_days    = 10
max_binlog_size     = 100M
binlog_do_db        = magento_demo
binlog_ignore_db    = mysql 

La configurazione per il server MySQL slave (/etc/mysql/my.cnf) aggiunge il contenuto seguente nel file:

[mysqld]
server-id=2
log-bin=mysql-bin
master-host=192.168.1.2
master-user=username
master-password=111111
master-port=3306
replicate-do-db=magento_demo
replicate-ignore-db=mysql
master-connect-retry=60 

Riavvia successivamente entrambi i server MySQL

Un'idea è che puoi dividere le letture del tuo catalogo su server slave usando il DNS round-robin .

Quindi imposta la normale replica master -> slave (s) in MySQL.

Quindi nella tua configurazione Magento puoi configurare il tuo catalogo per fare letture dal tuo host DNS configurato round-robin. Le scritture rimarranno nel tuo database principale.

Puoi farlo in app/etc/local.xml

<catalog_read_setup>
   <connection>
      <host><![CDATA[round.robbin.dns.host]]></host>
      <username><![CDATA[USERNAME]]></username>
      <password><![CDATA[password]]></password>
      <dbname><![CDATA[DATABASE]]></dbname>
      <initStatements><![CDATA[SET NAMES utf8]]></initStatements>
      <model><![CDATA[mysql4]]></model>
      <type><![CDATA[pdo_mysql]]></type>
      <pdoType><![CDATA[]]></pdoType>
      <active>1</active>
   </connection>
</catalog_read_setup>
<catalog_read>
   <connection>
     <use>catalog_read_setup</use>
   </connection>
 </catalog_read>

Puoi reindirizzare qualsiasi modulo principale (e di terze parti) per utilizzare un'istanza MySQL diversa allo stesso modo.