Como otimizar a arquitetura do banco de dados para sites de alto volume?

A questão é menos sobre itens de configuração específicos do Mysql, mas mais sobre o manuseio de vários bancos de dados, a divisão de leitura e gravação em vários servidores de banco de dados, master + master? Mestre + vários escravos?

Com o que as pessoas tiveram a melhor experiência e existem exemplos de como conseguir isso?

Temos uma experiência bastante vasta de clusters MySQL - e a Percona trabalhou conosco em várias ocasiões ao ultrapassar os limites de configurações complexas.

O Magento pode lidar nativamente com escravos somente leitura

O Magento é nativamente capaz de separar leituras / gravações em diferentes servidores de banco de dados (com exceção de algumas versões quebradas, por exemplo, EE 1.11) - permitindo compensar a selectcarga em um ou mais servidores; e encaminhando todas as update/writeconsultas para um único mestre.

Quando devo fazê-lo

Esta é uma pergunta mais apropriada. Com sistemas operacionais Magento dedicados, como o MageStack - é cada vez mais comum que as técnicas avançadas de armazenamento em cache do lado do servidor estejam disponíveis e sejam facilmente usadas (como o cache de front-end do Varnish e o cache de back-end do Redis).

Historicamente, o Magento nunca foi vinculado pelo MySQL - mas pelo PHP. Porém, à medida que o Varnish e o Full Page Caching (FPC) são usados ​​com mais freqüência, o ônus de tarefas repetidas (cargas de categoria / produto, pesquisas frequentes) é subitamente absorvido e o PHP se torna um fardo menor. De fato, ele só entra em jogo para gerar o conteúdo inicialmente ou para completar cenários não capturáveis ​​(adicionar ao carrinho, concluir o pedido etc.); para fins de explicação, ignoramos deliberadamente a carga administrativa .

Sempre defendemos o fato de o MySQL não ser uma área de preocupação para a maioria dos varejistas, como visto aqui e aqui . Mas se você estiver na região de processar centenas de pedidos por hora, e não um dígito ou dois dígitos - em breve se tornará uma área de otimização.

Por fim, para lojas menores (<25k visitantes únicos diários)

Seus esforços seriam muito mais concentrados em simplesmente encontrar um host apropriado que possa sugerir o hardware certo a partir do offset e que tenha configurado a máquina da maneira mais ideal para sua loja . Não perca seu tempo buscando configurações Master / Slave ou Master / Master - que não trarão benefícios de desempenho e acabarão exigindo atenção contínua e conhecimento avançado do MySQL.

Por fim, o dimensionamento e a seleção de hardware terão um papel maior do que a otimização do MySQL.

Mas para lojas maiores

À medida que sua loja começa a crescer, a carga transacional ou de conversão se torna um fardo com a tarefa repetida de concluir tarefas complexas insertse updates. A adição de cada novo pedido acionará a diminuição do estoque do catálogo, retornos de chamada dos gateways de pagamento e atualizações dos sistemas EPOS / ERP. Combine isso com a limpeza de cache associada dos respectivos produtos / categorias e em breve você verá o carregamento do MySQL aumentar desproporcionalmente.

O mestre múltiplo nunca é uma solução que recomendamos ou consideramos uma opção viável, mas o Mestre / Escravo pode gerar benefícios (enfatizamos, em lojas de tamanho Enterprise), compensando a carga de leitura para os nós secundários / terciários.

Mas eu ainda quero fazer isso

Primeiro configure seus escravos. Somos grandes defensores dos utilitários Percona e dos ramos do MySQL - eles têm uma ferramenta ideal para fazer backups quentes do seu banco de dados existente - innobackupex. Há uma boa redação aqui .

No mestre

Substitua $ TIMESTAMP ou guia concluída.

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

No escravo

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

Então, quando o seu escravo estiver operacional, na prática, serão necessárias apenas algumas linhas de código adicionais.

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

Fontes

Em geral, o Magento é vinculado à CPU, não ao banco de dados, e a maior parte da atividade da CPU pode ser armazenada em cache, e é por isso que você encontrará tantos tutoriais sobre configurações de verniz / nginx. Você também pode mover seu administrador para um nó da web separado, conforme detalhado aqui .

Para uma robustez geral, o melhor retorno absoluto será um serviço MySQL gerenciado.

Eu só tenho experiência com o Amazon RDS, mas eles automatizam failover, backups, atualizações, redimensionamento para cima / baixo, além de ler a criação de réplicas. Para que você possa ter um nó mestre de alta disponibilidade com failover automático - a Amazon usa uma replicação de log binária personalizada para manter o escravo sincronizado, o failover leva menos de 2 minutos normalmente e, em seguida, você pode criar quantas réplicas de leitura desejar. precisa ser dimensionado para atender às suas necessidades de relatórios / integração.

Eu procurei dividir leituras / gravações, o que é muito viável com a arquitetura do Magento, mas o banco de dados não é um gargalo no meu caso de uso. Eu recomendo utilizar perfis como xhprof / xhgui em vez de adivinhar o que precisa ser otimizado. A primeira regra de criação de perfil é medir.

Eu não tive nenhuma experiência de produção com isso, mas depois de algumas escavações, encontrei este artigo. Neste artigo, alguém explica como configurar a replicação mestre-escravo para Magento, para que possa ser útil para você.

Parte mais importante:

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

A configuração do servidor MySQL principal (/etc/mysql/my.cnf) adiciona o conteúdo abaixo no arquivo:

[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 

A configuração do servidor MySQL escravo (/etc/mysql/my.cnf) adiciona o conteúdo abaixo no arquivo:

[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 

Reinicie os dois servidores MySQL posteriormente

Uma idéia é que você pode dividir as leituras de seu catálogo em servidores escravos usando o round-robin do dns .

Assim, configure a replicação normal de mestre -> escravo (s) no MySQL.

Em sua configuração do Magento, você pode configurar seu catálogo para fazer leituras do host DNS configurado round-robin. As gravações permanecerão no seu banco de dados mestre.

Você pode fazer isso em 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>

Você pode redirecionar qualquer módulo principal (e de terceiros) para usar uma instância MySQL diferente da mesma maneira.