Як оптимізувати архітектуру баз даних для сайтів з великим обсягом?

Питання менше про конкретні елементи конфігурації Mysql, а більше про обробку кількох баз даних, розділення читання та запису на кілька серверів баз даних, master + master? Майстер + кілька рабів?

З чим люди мали найкращий досвід, і чи є приклади, як цього досягти?

У нас є досить великий досвід кластерів MySQL - і Percona неодноразово працювали з нами, коли розсовували межі складних конфігурацій.

Чи може Magento по-справжньому поводитися з рабами, які лише читають

Magento в основному здатний розділяти читання / запис на різні сервери баз даних (за винятком декількох вирваних випусків, наприклад, EE 1.11) - дозволяє компенсувати selectнавантаження на додатковий (або більше) сервер (и); і пересилання всіх update/writeзапитів одному майстру.

Коли я повинен це зробити

Це більш відповідне питання. З спеціалізованими операційними системами Magento, такими як MageStack - це стає все більш поширеним, щоб вбудовані серверні вдосконалені методи кешування були доступні та прості у використанні (наприклад, керування переднім кінцевим кешуванням та кешування Redis back end).

Історично Magento ніколи не пов'язувався MySQL - скоріше PHP. Але в міру частішого керування лаком та керування сторінками (FPC), тягар повторних завдань (завантаження категорії / продукту, часті пошуки) раптово поглинається і PHP стає меншим тягарем. Насправді, це дійсно реально грає для того, щоб спочатку генерувати вміст або завершувати непридатні сценарії (додавання в кошик, завершення замовлення тощо); з метою пояснення ми свідомо ігноруємо адміністративне навантаження .

Ми завжди стояли за тим, що MySQL не є проблемою для більшості підприємств роздрібної торгівлі, як це спостерігається і тут, і тут . Але якщо ваш у регіоні обробляє сотні замовлень на годину, а не одно- чи двозначні - це незабаром стане областю для оптимізації.

У кінцевому рахунку для менших магазинів (<25 тис. Унікальних відвідувачів щодня)

Ваші зусилля будуть набагато краще зосереджені на тому, щоб просто знайти відповідного господаря, який може запропонувати встановити правильне обладнання з компенсації, і це налаштувало машину найкращим чином для вашого магазину . Не витрачайте час на пошук конфігурацій Master / Slave або Master / Master - це не принесе користі від продуктивності і, в кінцевому рахунку, вимагатиме постійної уваги та передових знань MySQL.

В остаточному підсумку розміри та вибір обладнання відіграватимуть більшу роль, ніж оптимізація MySQL.

Але для більших магазинів

У міру того, як ваш магазин починає зростати, конвертація або транзакційний навантаження стає більше тягарем при повторному завданні завершення складних insertsі updates. Додавання кожного нового замовлення призведе до зменшення запасів каталогу, зворотних дзвінків із платіжних шлюзів та оновлень із систем EPOS / ERP. Комбінуйте це з пов'язаною очищенням кешу відповідних продуктів / категорій, і незабаром ви побачите, що завантаження MySQL непропорційно збільшується.

Multi-master ніколи не є рішенням, яке ми рекомендуємо або розглядаємо як життєздатний варіант, але Master / Slave може принести переваги (ми наголошуємо, на магазинах розміру Enterprise) шляхом зміщення завантаження зчитування на вторинні / третинні вузли.

Але я все одно хочу це зробити

Спочатку налаштуйте своїх рабів. Ми великі прихильники утиліт Percona та гілок MySQL - вони мають ідеальний інструмент для гарячих резервних копій наявного БД - inabackupex. Існує хороший підправити тут .

На майстра

Замініть $ TIMESTAMP або вкладку завершено.

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

На раба

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

Тоді після того, як ваш раб працює, на практиці потрібно лише кілька додаткових рядків коду для досягнення.

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

Джерела

Загалом Magento пов'язаний з процесором, не пов'язаний з базою даних, і більшість процесорних дій можна кешувати, тому ви знайдете так багато підручників щодо налаштувань лаку / nginx. Ви також можете перемістити свого адміністратора в окремий веб-вузол, як детально описано тут .

Для загальної надійності абсолютним найкращим ударом для долара буде керований сервіс MySQL.

У мене є лише досвід роботи з Amazon RDS, але вони автоматизують відмову, резервне копіювання, оновлення, масштабування вгору / вниз, а також створення реплик для читання. Таким чином, ви можете мати головний вузол високої доступності, який має автоматичну відмову - Amazon використовує індивідуальну бінарну реплікацію журналу для того, щоб підтримувати підлеглий синхронізацію, відмову зазвичай займає менше 2 хвилин, а потім ви можете створити стільки реплік для читання потрібно розширити масштаби для потреб звітування / інтеграції.

Я роздивився розбиття читання / запису, що дуже можливо з архітектурою Magento, але база даних не є вузьким місцем у моєму випадку використання. Я настійно рекомендую використовувати профілювання на зразок xhprof / xhgui, а не здогадуватися, що потрібно оптимізувати. Перше правило профілювання - це вимірювання.

Я не мав жодного виробничого досвіду з цим, але після деякого копання я знайшов цю статтю. У цій статті хтось пояснює, як налаштувати реплікацію master-slave для Magento, щоб це могло вам стати в нагоді.

Найголовніший біт:

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

Конфігурація для головного сервера MySQL (/etc/mysql/my.cnf) додайте нижче вміст у файл:

[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 

Конфігурація для підлеглого сервера MySQL (/etc/mysql/my.cnf) додайте нижче вміст у файл:

[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 

Після цього перезавантажте обидва сервери MySQL

Одна ідея полягає в тому, що ви можете розділити зчитування вашого каталогу на підлеглому сервері, використовуючи dns round-robin .

Таким чином, встановіть нормальну реплікацію master -> slave (s) у MySQL.

Потім у налаштуваннях Magento ви можете налаштувати свій каталог, щоб він читав з вашого хост-налаштованого dns-хоста. Writes залишиться у вашій базі даних.

Це можна зробити в 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>

Ви можете переспрямовувати будь-які основні (та сторонні модулі) модулі, щоб використовувати інший екземпляр MySQL таким же чином.