Wie kann die Datenbankarchitektur für Websites mit hohem Datenvolumen optimiert werden?

Die Frage bezieht sich weniger auf bestimmte Mysql-Konfigurationselemente als vielmehr auf den Umgang mit mehreren Datenbanken, die Aufteilung von Lese- und Schreibvorgängen auf mehrere Datenbankserver, Master + Master? Master + Mehrere Slaves?

Was haben die Menschen am besten erlebt, und gibt es Beispiele, wie dies erreicht werden kann?

Wir haben eine ziemlich große Erfahrung mit MySQL-Clustern - und Percona hat bereits mehrfach mit uns zusammengearbeitet, um die Grenzen komplexer Konfigurationen zu erweitern.

Kann Magento nativ mit schreibgeschützten Slaves umgehen

Magento ist von Haus aus in der Lage, Lese- / Schreibzugriffe auf verschiedene Datenbankserver aufzuteilen (mit Ausnahme einiger fehlerhafter Versionen, z. B. EE 1.11). Auf diese Weise können Sie die selectLast auf einen zusätzlichen (oder mehrere) Server verteilen. und Weiterleiten aller update/writeAbfragen an einen einzelnen Master.

Wann soll ich es tun?

Dies ist eine angemessenere Frage. Mit dedizierten Magento-Betriebssystemen wie MageStack wird es immer üblicher, dass integrierte, serverseitige, erweiterte Caching-Techniken zur Verfügung stehen und einfach verwendet werden (wie Varnish-Front-End-Caching und Redis-Back-End-Caching).

In der Vergangenheit war Magento nie an MySQL gebunden, sondern an PHP. Durch die häufigere Verwendung von Varnish und Full Page Caching (FPC) wird die Belastung durch wiederholte Aufgaben (Laden von Kategorien / Produkten, häufiges Suchen) plötzlich aufgehoben und PHP wird weniger belastet. Tatsächlich kommt es nur dann wirklich ins Spiel, wenn der Inhalt anfänglich generiert wird oder wenn nicht zwischengespeicherte Szenarien abgeschlossen werden (in den Warenkorb legen, Bestellung abschließen usw.). zum Zwecke der Erklärung ignorieren wir absichtlich den Verwaltungsaufwand .

Wir haben immer daran festgehalten, dass MySQL für die meisten Einzelhändler hier und hier kein Problem darstellt . Aber wenn Sie in der Region Hunderte von Bestellungen pro Stunde abwickeln, nicht einstellige oder zweistellige, wird dies bald zu einem Bereich für die Optimierung.

Letztendlich für kleinere Geschäfte (<25.000 tägliche Besucher)

Ihre Bemühungen konzentrieren sich vielmehr darauf, einen geeigneten Host zu finden, der die richtige Hardware für den Offset-Druck vorschlägt und die Maschine optimal für Ihr Geschäft konfiguriert hat . Vergeuden Sie nicht Ihre Zeit damit, Master / Slave- oder Master / Master-Konfigurationen zu verfolgen - dies bringt keinen Leistungsvorteil und erfordert letztendlich kontinuierliche Aufmerksamkeit und fortgeschrittenes MySQL-Wissen.

Letztendlich wird die Dimensionierung und Auswahl der Hardware eine größere Rolle spielen als die MySQL-Optimierung.

Aber für größere Läden

Als Ihr Geschäft beginnt oder Transaktionslast wird mit der wiederholten Aufgabe eher eine Belastung zu wachsen, Umwandlung Komplex abgeschlossen insertsund updates. Das Hinzufügen jeder neuen Bestellung löst das Verringern des Katalogbestands, Rückrufe von Zahlungs-Gateways und Aktualisierungen von EPOS / ERP-Systemen aus. Wenn Sie dies mit der zugehörigen Cache-Bereinigung der jeweiligen Produkte / Kategorien kombinieren, wird die MySQL-Last in Kürze überproportional ansteigen.

Multi-Master ist niemals eine Lösung, die wir empfehlen oder als praktikable Option in Betracht ziehen, aber Master / Slave kann Vorteile bringen (wir betonen dies bei Speichern in Unternehmensgröße), indem die Leselast auf sekundäre / tertiäre Knoten verschoben wird.

Aber ich will es trotzdem tun

Konfigurieren Sie zuerst Ihre Slaves. Wir sind große Befürworter der Percona-Dienstprogramme und der MySQL-Zweige - sie bieten ein ideales Tool für die Erstellung von Hot- Backups Ihrer vorhandenen DB - innobackupex. Es gibt eine gute aufzuschreiben hier .

Auf den Meister

Ersetzen Sie $ TIMESTAMP oder die Registerkarte ist vollständig.

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

Auf den Sklaven

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

Sobald Ihr Slave betriebsbereit ist, sind in der Praxis nur wenige zusätzliche Codezeilen erforderlich, um dies zu erreichen.

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

Quellen

Im Allgemeinen ist Magento CPU-gebunden, nicht datenbankgebunden, und der Großteil der CPU-Aktivität kann zwischengespeichert werden, weshalb Sie so viele Tutorials zu Lack- / Nginx-Setups finden. Sie können Ihren Administrator auch auf einen separaten Webknoten verschieben, wie hier beschrieben .

Für die allgemeine Robustheit ist ein verwalteter MySQL-Service das absolut beste Preis-Leistungs-Verhältnis.

Ich habe nur Erfahrung mit Amazon RDS, aber sie automatisieren Failover, Backups, Upgrades, Up / Down-Skalierungen sowie die Erstellung von Lesereplikaten. Sie können also einen Hochverfügbarkeits-Masterknoten mit automatischem Failover haben. Amazon verwendet eine angepasste binäre Protokollreplikation, um den Slave synchron zu halten. Das Failover dauert in der Regel weniger als 2 Minuten. Anschließend können Sie so viele Leserepliken erstellen, wie Sie möchten müssen für Ihre Berichterstellungs- / Integrationsanforderungen skaliert werden.

Ich habe mir die Aufteilung von Lese- / Schreibvorgängen angesehen, die mit Magentos Architektur sehr gut möglich ist, aber die Datenbank ist in meinem Anwendungsfall kein Engpass. Ich empfehle dringend, ein Profil wie xhprof / xhgui zu verwenden, anstatt zu erraten, was optimiert werden muss. Die erste Regel für die Profilerstellung ist das Messen.

Ich habe keine Produktionserfahrung damit, aber nach einigem Graben habe ich diesen Artikel gefunden. In diesem Artikel wird erläutert, wie Sie die Master-Slave-Replikation für Magento einrichten.

Wichtigstes Bit:

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

Konfiguration für den Master-MySQL-Server (/etc/mysql/my.cnf) Fügen Sie den folgenden Inhalt in die Datei ein:

[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 

Konfiguration für Slave-MySQL-Server (/etc/mysql/my.cnf) Fügen Sie den folgenden Inhalt in die Datei ein:

[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 

Starten Sie anschließend beide MySQL-Server neu

Eine Idee ist, dass Sie Ihre Kataloglesevorgänge mit DNS Round-Robin auf Slave-Server aufteilen können .

Richten Sie daher die normale Master -> Slave-Replikation in MySQL ein.

Anschließend können Sie in Ihrem Magento-Setup Ihren Katalog so konfigurieren, dass Lesevorgänge von Ihrem Round-Robin-konfigurierten DNS-Host ausgeführt werden. Schreibvorgänge bleiben in Ihrer master-Datenbank.

Sie können dies in tun 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>

Sie können beliebige Kernmodule (und Module von Drittanbietern) umleiten, um auf dieselbe Weise eine andere MySQL-Instanz zu verwenden.