Comment optimiser l'architecture de base de données pour les sites à volume élevé?

La question est moins sur les éléments de configuration Mysql spécifiques, mais plus sur la gestion de plusieurs bases de données, le fractionnement de la lecture et de l'écriture sur plusieurs serveurs de base de données, maître + maître? Maître + esclaves multiples?

Avec quoi les gens ont-ils eu la meilleure expérience et existe-t-il des exemples sur la façon d'y parvenir?

Nous avons une assez grande expérience des clusters MySQL - et Percona a travaillé avec nous à plusieurs reprises pour repousser les limites des configurations complexes.

Magento peut-il gérer nativement les esclaves en lecture seule

Magento est nativement capable de séparer les lectures / écritures sur différents serveurs de base de données (à l'exception de quelques versions cassées, par exemple EE 1.11) - vous permettant de compenser la selectcharge sur un ou plusieurs serveurs supplémentaires; et transmettre toutes les update/writerequêtes à un seul maître.

Quand dois-je le faire

C'est une question plus appropriée. Avec les systèmes d'exploitation Magento dédiés comme MageStack - il est de plus en plus courant que les techniques de mise en cache avancées côté serveur soient disponibles et facilement utilisables (telles que la mise en cache frontale Varnish et la mise en cache backend Redis).

Historiquement, Magento n'a jamais été lié par MySQL - mais plutôt PHP. Mais comme le vernis et la mise en cache pleine page (FPC) sont utilisés plus fréquemment, la charge des tâches répétées (charges de catégorie / produit, recherches fréquentes) est soudainement absorbée et PHP devient moins lourd. En fait, il n'entre vraiment en jeu que pour générer le contenu initialement, ou pour compléter des scénarios non cachable (ajout au panier, finalisation de la commande, etc.); à des fins d'explication, nous ignorons délibérément la charge administrative .

Nous avons toujours soutenu le fait que MySQL n'est pas un sujet de préoccupation pour la plupart des détaillants, comme on le voit ici et ici . Mais si vous êtes dans le domaine du traitement de centaines de commandes par heure, pas de chiffres simples ou doubles - cela deviendra bientôt un domaine d'optimisation.

En fin de compte pour les petits magasins (<25 000 visiteurs uniques quotidiens)

Vos efforts seraient bien mieux concentrés sur la simple recherche d'un hôte approprié qui peut suggérer le bon matériel à utiliser à partir du décalage et qui a configuré la machine de la manière la plus optimale pour votre magasin . Ne perdez pas votre temps à rechercher des configurations maître / esclave ou maître / maître, ce qui n'apportera aucun avantage en termes de performances et nécessitera en fin de compte une attention continue et des connaissances avancées en MySQL.

En fin de compte, le dimensionnement et la sélection du matériel auront un rôle plus important à jouer que l'optimisation MySQL.

Mais pour les grands magasins

Au fur et à mesure que votre magasin commence à croître, la conversion ou la charge transactionnelle devient de plus en plus un fardeau avec la tâche répétée de terminer des tâches complexes insertset updates. L'ajout de chaque nouvelle commande entraînera la diminution du stock de catalogue, les rappels des passerelles de paiement et les mises à jour des systèmes EPOS / ERP. Combinez cela avec la purge du cache associée des produits / catégories respectifs et vous verrez bientôt la charge MySQL augmenter de manière disproportionnée.

Le multi-maître n'est jamais une solution que nous recommandons ou considérons comme une option viable, mais maître / esclave peut générer des avantages (nous insistons sur les magasins de taille entreprise) en compensant la charge de lecture sur les nœuds secondaires / tertiaires.

Mais je veux toujours le faire

Configurez d'abord vos esclaves. Nous sommes de grands défenseurs des utilitaires Percona et des branches MySQL - ils ont un outil idéal pour effectuer des sauvegardes à chaud de votre base de données existante - innobackupex. Il y a une bonne écriture ici .

Sur le maître

Remplacez $ TIMESTAMP ou tab complete.

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

Sur l'esclave

/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;

Ensuite, une fois que votre esclave est opérationnel, en pratique, il suffit de quelques lignes de code supplémentaires pour y parvenir.

Dans ./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>

Sources

En général, Magento est lié au CPU, pas à la base de données, et la plupart des activités du CPU peuvent être mises en cache, c'est pourquoi vous trouverez autant de tutoriels sur les configurations de vernis / nginx. Vous pouvez également déplacer votre administrateur vers un nœud Web distinct, comme indiqué ici .

Pour une robustesse générale, le meilleur rapport qualité / prix sera un service MySQL géré.

Je n'ai qu'une expérience avec Amazon RDS, mais ils automatisent le basculement, les sauvegardes, les mises à niveau, la montée / descente, ainsi que la création de réplicas en lecture. Vous pouvez donc avoir un nœud maître à haute disponibilité doté d'un basculement automatique - Amazon utilise une réplication de journal binaire personnalisée afin de maintenir l'esclave synchronisé, le basculement prend généralement moins de 2 minutes, puis vous pouvez créer autant de réplicas en lecture que vous. besoin d'évoluer pour vos besoins de reporting / d'intégration.

J'ai étudié le fractionnement des lectures / écritures, ce qui est très faisable avec l'architecture de Magento, mais la base de données n'est pas un goulot d'étranglement dans mon cas d'utilisation. Je recommande fortement d'utiliser le profilage comme xhprof / xhgui plutôt que de deviner ce qui doit être optimisé. La première règle du profilage est de mesurer.

Je n'ai eu aucune expérience de production avec cela, mais après quelques recherches, j'ai trouvé cet article. Dans cet article, quelqu'un explique comment configurer la réplication maître-esclave pour Magento, donc cela pourrait vous être utile.

Bit le plus important:

/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 configuration du serveur maître MySQL (/etc/mysql/my.cnf) ajoute le contenu ci-dessous dans le fichier:

[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 configuration du serveur MySQL esclave (/etc/mysql/my.cnf) ajoute le contenu ci-dessous dans le fichier:

[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 

Redémarrez ensuite les deux serveurs MySQL

Une idée est que vous pouvez diviser vos lectures de catalogue en serveur (s) esclave (s) en utilisant le round robin DNS .

Configurez donc la réplication normale maître -> esclave (s) dans MySQL.

Ensuite, dans votre configuration Magento, vous pouvez configurer votre catalogue pour effectuer des lectures à partir de votre hôte DNS configuré à tour de rôle. Les écritures resteront dans votre base de données principale.

Vous pouvez le faire dans 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>

Vous pouvez rediriger n'importe quel module principal (et tiers) pour utiliser une instance MySQL différente de la même manière.