Jak zoptymalizować architekturę bazy danych pod kątem dużych witryn?

Pytanie mniej dotyczy konkretnych elementów konfiguracji MySQL, ale więcej informacji o obsłudze wielu baz danych, dzieleniu odczytu i zapisu na wiele serwerów baz danych, master + master? Mistrz + wielu niewolników?

Z czym ludzie mieli najlepsze doświadczenia i czy są jakieś przykłady, jak to osiągnąć?

Mamy dość duże doświadczenie w zakresie klastrów MySQL - a Percona wielokrotnie z nami współpracowała, przekraczając granice skomplikowanych konfiguracji.

Czy Magento ma wbudowaną obsługę niewolników tylko do odczytu

Magento jest natywnie zdolny do dzielenia odczytów / zapisów na różne serwery baz danych (z wyjątkiem kilku uszkodzonych wydań, np. EE 1.11) - pozwalając na przesunięcie selectobciążenia na dodatkowy (lub więcej) serwer (y); i przesyłanie wszystkich update/writezapytań do jednego wzorca.

Kiedy powinienem to zrobić

To jest bardziej odpowiednie pytanie. Dzięki dedykowanym systemom operacyjnym Magento, takim jak MageStack - coraz częściej stosowane są wbudowane zaawansowane techniki buforowania po stronie serwera, które są dostępne i łatwe w użyciu (takie jak buforowanie frontonu Varnish i buforowanie back-endu Redis).

Historycznie Magento nigdy nie był związany MySQL - a raczej PHP. Jednak w miarę częstszego korzystania z Varnish i Full Page Caching (FPC) obciążenie związane z powtarzaniem zadań (ładowanie kategorii / produktów, częste wyszukiwanie) jest nagle absorbowane, a PHP staje się mniej obciążający. W rzeczywistości naprawdę dopiero zaczyna się generowanie treści lub ukończenie scenariuszy niemożliwych do buforowania (dodanie do koszyka, realizacja zamówienia itp.); w celu wyjaśnienia celowo ignorujemy obciążenie administracyjne .

Zawsze utrzymywaliśmy, że MySQL nie jest przedmiotem zainteresowania większości sprzedawców detalicznych, co widać zarówno tutaj, jak i tutaj . Ale jeśli jesteś w regionie przetwarzania setek zamówień na godzinę, a nie pojedynczych lub podwójnych cyfr - wkrótce stanie się obszarem do optymalizacji.

Ostatecznie dla mniejszych sklepów (<25 000 unikalnych odwiedzających dziennie)

Twoje wysiłki byłyby znacznie lepiej skoncentrowane na po prostu znalezieniu odpowiedniego hosta, który może zasugerować odpowiedni sprzęt do przesunięcia i który skonfigurował maszynę w najbardziej optymalny sposób dla twojego sklepu . Nie marnuj czasu na konfiguracje Master / Slave lub Master / Master - które nie przyniosą korzyści w zakresie wydajności i ostatecznie będą wymagały ciągłej uwagi i zaawansowanej wiedzy na temat MySQL.

Ostatecznie zmiana rozmiaru i wybór sprzętu będzie odgrywać większą rolę niż optymalizacja MySQL.

Ale dla większych sklepów

Gdy sklep zaczyna się rozwijać, konwersja lub obciążenie transakcyjne stają się coraz większym obciążeniem w związku z powtarzającym się zadaniem wykonania skomplikowanych insertsi updates. Dodanie każdego nowego zamówienia spowoduje zmniejszenie zapasów w katalogu, wywołania zwrotne z bramek płatności i aktualizacje z systemów EPOS / ERP. Połącz to z powiązanym czyszczeniem pamięci podręcznej odpowiednich produktów / kategorii, a wkrótce zobaczysz, że obciążenie MySQL wzrośnie nieproporcjonalnie.

Multi-master nigdy nie jest rozwiązaniem, które zalecamy lub uważamy za realną opcję, ale Master / Slave może przynieść korzyści (podkreślamy, w sklepach o rozmiarach Enterprise) poprzez przesunięcie obciążenia odczytu do węzłów drugorzędnych / trzeciorzędnych.

Ale nadal chcę to zrobić

Najpierw skonfiguruj swoich niewolników. Jesteśmy wielkimi zwolennikami tych narzędzi Percona i oddziałów MySQL - mają one narzędzie idealne do robienia gorących kopie zapasowe istniejących DB - innobackupex. Jest dobry napisać tutaj .

Na mistrzu

Zastąp $ TIMESTAMP lub kartę zakończoną.

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

Na niewolniku

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

Potem, kiedy twój slave zacznie działać, w praktyce potrzeba tylko kilku dodatkowych wierszy kodu.

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

Źródła

Ogólnie rzecz biorąc, Magento jest związane z procesorem, a nie z bazą danych, a większość aktywności procesora można buforować, dlatego znajdziesz tak wiele samouczków na temat konfiguracji lakieru / nginx. Możesz także przenieść swojego administratora do oddzielnego węzła internetowego, jak opisano tutaj .

Jeśli chodzi o ogólną niezawodność, absolutnym najlepszym hukiem dla złotówki będzie zarządzana usługa MySQL.

Mam tylko doświadczenie z Amazon RDS, ale automatyzują one przełączanie awaryjne, kopie zapasowe, aktualizacje, skalowanie w górę / w dół, a także tworzenie replik odczytu. Możesz więc mieć węzeł główny o wysokiej dostępności, który ma automatyczne przełączanie awaryjne - Amazon używa dostosowanej replikacji dziennika binarnego, aby utrzymać synchronizację slave, przełączanie awaryjne zajmuje zwykle mniej niż 2 minuty, a następnie możesz utworzyć tyle replik odczytu, ile musisz skalować według potrzeb związanych z raportowaniem / integracją.

Przyglądałem się podziałowi odczytów / zapisów, co jest bardzo wykonalne w architekturze Magento, ale baza danych nie jest wąskim gardłem w moim przypadku użycia. Zdecydowanie zalecam korzystanie z profilowania takiego jak xhprof / xhgui zamiast zgadywania, co należy zoptymalizować. Pierwszą zasadą profilowania jest pomiar.

Nie miałem z tym żadnego doświadczenia produkcyjnego, ale po kilku kopaniach znalazłem ten artykuł. W tym artykule ktoś wyjaśnia, jak skonfigurować replikację master-slave dla Magento, więc może ci się przydać.

Najważniejszy 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> 

Konfiguracja głównego serwera MySQL (/etc/mysql/my.cnf) dodaj poniżej zawartość w pliku:

[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 

Konfiguracja podrzędnego serwera MySQL (/etc/mysql/my.cnf) dodaj poniżej zawartość w pliku:

[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 

Zrestartuj oba serwery MySQL później

Jednym z pomysłów jest podzielenie odczytów katalogu na serwer (y) podrzędne za pomocą round-robin dns .

Zatem ustaw normalną replikację master -> slave (s) w MySQL.

Następnie w konfiguracji Magento możesz skonfigurować katalog, aby dokonywał odczytów z hosta dns skonfigurowanego w trybie round-robin. Zapisy pozostaną w głównej bazie danych.

Możesz to zrobić w 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>

Możesz przekierować dowolny moduł podstawowy (i zewnętrzny), aby użyć innej instancji MySQL w ten sam sposób.