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.
fonte
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
A configuração do servidor MySQL principal (/etc/mysql/my.cnf) adiciona o conteúdo abaixo no arquivo:
A configuração do servidor MySQL escravo (/etc/mysql/my.cnf) adiciona o conteúdo abaixo no arquivo:
Reinicie os dois servidores MySQL posteriormente
fonte
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.xmlVocê pode redirecionar qualquer módulo principal (e de terceiros) para usar uma instância MySQL diferente da mesma maneira.
fonte