Как оптимизировать архитектуру базы данных для больших объемов сайтов?

Вопрос не столько в конкретных элементах конфигурации Mysql, сколько в обработке нескольких баз данных, разделении чтения и записи на несколько серверов баз данных, master + master? Мастер + несколько рабов?

С чем люди имели лучший опыт, и есть ли примеры того, как этого добиться?

У нас достаточно обширный опыт работы с кластерами MySQL, и Percona неоднократно работала с нами, когда раздвигала границы сложных конфигураций.

Может ли Magento работать с рабами только для чтения?

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

Когда я должен это сделать

Это более подходящий вопрос. Благодаря выделенным операционным системам Magento, таким как MageStack, становится все более распространенным доступное и простое использование встроенных расширенных методов кэширования на стороне сервера (таких как кэширование внешнего интерфейса Varnish и внутреннее кэширование Redis).

Исторически, Magento никогда не был связан MySQL - скорее PHP. Но поскольку Varnish и Full Page Caching (FPC) используются чаще, бремя повторяющихся задач (загрузка категорий / продуктов, частые поиски) внезапно поглощается, и PHP становится меньше бремени. На самом деле, он действительно вступает в игру только для первоначальной генерации контента или выполнения сценариев без кэширования (добавление в корзину, завершение заказа и т. Д.); с целью объяснения мы намеренно игнорируем административную нагрузку .

Мы всегда придерживались того факта, что MySQL не является проблемой для большинства компаний розничной торговли, как видно здесь и здесь . Но если вы в регионе обрабатываете сотни заказов в час, а не однозначные или двузначные цифры - это скоро станет областью для оптимизации.

В конечном счете, для небольших магазинов (<25 000 ежедневных уникальных посетителей)

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

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

Но для крупных магазинов

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

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

Но я все еще хочу сделать это

Сначала настройте своих рабов. Мы большие сторонники утилит Percona и филиалы MySQL - у них есть идеальный инструмент для принятия горячей подпорки существующей БД - innobackupex. Существует хороший подправить здесь .

На мастера

Замените $ 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, сконфигурированного для циклического перебора. Пишет, останется в вашей главной базе данных.

Вы можете сделать это в 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 таким же образом.