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

28

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ąć?

waskoizm
źródło

Odpowiedzi:

18

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

Ben Lessani - Sonassi
źródło
„Historycznie Magento nigdy nie był związany MySQL - a raczej PHP”. Nie jestem pewien, o czym mówisz Magento, ale EAV zawsze było problemem z wydajnością. :)
B00MER,
1
Odnoszę się do ponad 400 serwerów Magento, którymi zarządzamy ... Z reguły większość innych wąskich gardeł stanowi MySQL. W gruncie rzeczy najlepszym przykładem jest jeden z naszych klientów. Przy 15 000 unikalnych odwiedzających na godzinę, przetwarzanie 200 zamówień na godzinę na jednym serwerze (32 rdzenie, 64 GB pamięci RAM). Dla typowego czytelnika tego pytania jest bardzo mało prawdopodobne, aby robili nawet ten tom. Tak więc na poziomie ruchu i transakcji, które napotkają, MySQL nie jest wąskim gardłem.
Ben Lessani - Sonassi
1
@Brandon. Chcę tylko dodać. Nie przeczę, że strojenie MySQL nie jest wymogiem - oczywiście jest. Ale konfiguracja konfiguracji Master / Master lub Master / Slave w celu poprawy wydajności nie jest wymagana, dopóki nie osiągniesz pewnego punktu krytycznego - i to jest dość wysoka. Ponadto jest o wiele bardziej możliwe spowodowanie wąskiego gardła w wydajności lub ryzyko integralności danych, próbując zrobić coś takiego.
Ben Lessani - Sonassi
5

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.

Ralph Tice
źródło
Nie jesteśmy tutaj, aby zbudować stronę z zakładkami, na której odpowiedzi na pytania będą zawierać linki. Podaj tutaj podstawowe części odpowiedzi i podaj link w celach informacyjnych.
j0k
@ j0k Linki są podane w celach informacyjnych, a odpowiedź jest samodzielna - jeśli się nie zgadzasz, prosimy o bardziej szczegółowe informacje.
Ralph Tice
Tak, przynajmniej twoja odpowiedź jest lepsza niż druga. Chodzi mi o to, że OP może potrzebować więcej technicznych informacji na temat tego, co skonfigurować, dlaczego nie schemat architektury itp. ... Nawet jeśli doświadczenie jest świetne!
j0k
5

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

Kenny
źródło
1
Samotny link jest uważany za kiepską odpowiedź, ponieważ sam w sobie jest bez znaczenia, a zasoby docelowe nie są gwarantowane w przyszłości . Lepiej byłoby zawrzeć tutaj istotne części odpowiedzi i podać odnośnik.
j0k
@ j0k, wykonane zgodnie z prośbą;)
Kenny
3

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.

ProxiBlue
źródło
1
Okrągły robin DNS nie jest żadnym rozwiązaniem. Serwer proxy MySQL lub HAProxy to znacznie bardziej zaawansowane rozwiązania równoważenia obciążenia odczytu MySQL.
Ben Lessani - Sonassi