Formas de dimensionar automaticamente os servidores MySQL?

Question

Eu gerencio um site que possui altos picos de tráfego e, por causa disso, as soluções de escalonamento automático são muito lucrativas para esse caso. Atualmente, o servidor da Web é capaz de dimensionar automaticamente na horizontal, mas o gargalo está no servidor MySQL.

• Já experimentei o Amazon RDS Multi-AZ, mas leva 15 minutos para o banco de dados de 12 GB ser atualizado com alguns minutos de inatividade. Ajudou muito quando eu já sabia que uma onda de tráfego iria acontecer em algum momento específico.
• Eu também considerei Xeround. Esta é provavelmente a melhor solução, embora seja bastante cara para bancos de dados deste porte. De qualquer forma, não é uma opção, porque legalmente preciso que a base de dados esteja na União Europeia.
• Eu li sobre o Scalr, mas não tenho certeza se isso poderia ser útil e como.
• Vi que muitos provedores de hospedagem na nuvem oferecem soluções de dimensionamento vertical, que eu acho que tem 0 tempo de inatividade (não tenho certeza se isso é realmente possível, até onde eu sei, eles usam o hipervisor Xen). Isso poderia ser uma solução, mas eu me pergunto se não tem tempo de inatividade e como a configuração do MySQL (e muitas outras coisas no sistema operacional) é capaz de atualizar também sem tempo de inatividade.
• Eu tentei com servidores escravos do MySQL, mas não ajudou em nada.
• Estou usando o memcache, que ajuda muito, mas não é suficiente. Eu preciso atualizar por causa de gravações, não apenas por causa das leituras.

Alguma sugestão? Obrigado antecipadamente

    

Answer 1

Na verdade, uma solução mais simples seria tentar adicionar o Memcached à sua pilha para economizar no carregamento do DB. Isso pode economizar drasticamente a carga e é muito mais simples do que tentar resolver rapidamente o problema de ficar em pé nos servidores (baixa dificuldade) e, em seguida, descobrir uma sincronização rápida do MySQL (dificuldade muito maior).

link

Para resolver o problema de muitas gravações, a correção mais comum é adicionar memória ao servidor (um conjunto maior de trabalho pode ser mantido na RAM), colocando o banco de dados em discos mais rápidos (os SSDs são uma boa solução, mas são caros) ou sharding (que é caro em servidores adicionais e complexidade).

Outra maneira de reduzir a carga de gravação do banco de dados seria incorporar um armazenamento de dados na memória (como Redis) para manipular dados que mudam com frequência e, se necessário, gravar periodicamente as alterações no banco de dados principal.

    

Answer 2

Você deve considerar o uso de uma topologia em estrela

Aqui está o que estou propondo

• One Write Master (também conhecido como WM)
• Um Mestre de distribuição (também conhecido como DM)
• Cinco (5) Leia Servidor Escravo (também conhecido como RSS)

Prepare a topologia como esta

Passo 01: Configurar 5 RSS com estas opções comuns

[mysqld]
skip-innodb
key_buffer_size=1G

Isso fará com que todas as tabelas sejam criadas como MyISAM Storage Engine

Passo 02: Setup DM e todos os servidores RS

• mysqldump o esquema de todas as tabelas do WM para um arquivo schemadump
• carrega o arquivo schemadump no DM e todos os 5 RSS
• execute ALTER TABLE tblname ROW_FORMAT=Fixed; em todas as tabelas no RSS
• execute ALTER TABLE tblname ENGINE=BLACKHOLE; em todas as tabelas no DM
• apenas dados do mysqldump (usando --no-create-info) para um datadump
• carrega o datadump em todos os 5 RSS

Passo 03: Replicação de configuração do DM para todos os 5 RSS

Passo 04: Replicação do Setup do WM para o DM

END OF SETUP

Veja como funciona o seu mecanismo de leitura / gravação

• Todas as suas gravações (INSERTs, UPDATEs, DELETEs) ocorrem no WM
• O SQL é registrado nos logs binários do DM (Nenhum dado real reside no DM)
• Cada RSS é um escravo de leitura para o DM
• Todas as suas leituras ocorrem no RSS

Agora aqui está o problema ...

• Você usa o RSS 1-4 para leituras inicialmente
• Use o 5º RSS para acelerar outros RSS
  • Você executa service mysql stop no quinto RSS
  • Aumente outro RSS
  • Copie / var / lib / mysql e /etc/my.cnf do 5º RSS para o RSS recém-criado
  • Você executa service mysql stop no quinto RSS
  • Você executa service mysql stop no novo RSS

Você pode usar o RSS # 5 para gerar novos servidores várias vezes

Em um sidenote, por favor, não use o XEROUND para o WM ou DM porque eles não suportam o mecanismo de armazenamento InnoDB ou BLACKHOLE.

Espero que essas ideias ajudem.

    

Answer 3

Se você usar Innodb, você deve considerar Mestres multi-idiomas do Mysql gerenciado por Galera . Isso facilita a configuração do multi-master do mysql, e deve facilitar a auto-escala "semi".

Se este é um aplicativo que você ou sua empresa está escrevendo, você pode considerar a mudança para um design particionado para o aplicativo. Mas o sharding pode ficar complicado. Aqui está um link para você começar.

Estou assumindo que você "ajustou" os arquivos de configuração do mysql, como na memória apropriada alocada, etc.

    

Answer 4

Isso está em um rack que você controla ou está na nuvem? O 12GB é um pequeno banco de dados muito relativo ao tamanho dos discos disponíveis. Coloque-o em um array RAID1 ou RAID10 de SSDs pequenos do SLC e sua latência de gravação desaparecerá.

O SSD SSD da série Intel 311 20GB (US $ 120 cada) faria o trabalho de forma brilhante.

Se o banco de dados fosse maior, você poderia obter resultados igualmente espetaculares movendo seu banco de dados para um destino iSCSI em um servidor SAN ZFS (construído em hardware de servidor de commodity usando Nexenta, OpenIndiana, FreeNAS ou qualquer outro) e configurando um espelho de SSDs semelhantes para o seu cache de gravação ZIL. Em todas as circunstâncias, exceto as mais extraordinárias, o Gigabit Ethernet é mais que suficiente para mover o tráfego iSCSI do banco de dados.