Configuração do MySQL para High Connections, High Writes

3

Minha caixa está sendo divulgada. Estou tentando configurar uma caixa do MySQL em execução para:

  • 3000 conexões (3 trabalhadores para 1000 caixas) (caixa no máximo em 700 conexões, já)
  • Gravações pesadas

Configuração atual:

A configuração é: my-innodb-heavy-4G.cnf . Modificações específicas são:

  • max_connections = 65000
  • innodb_buffer_pool_size = 5G

Caso contrário, tudo é padrão. Quais recomendações vocês têm para uma configuração diferente do MySQL?

As considerações são:

  1. Cluster do MySQL
  2. Replicação Mestre / Escravo (não sei se haverá muitos ganhos aqui.)

Já estamos usando a caixa mais potente que a AWS tem disponível, então, de forma realista, parece que um sistema distribuído é possivelmente o caminho que deveríamos seguir. Hardware dedicado pode ser uma possibilidade, mas é uma chance muito longa.

O que você recomenda / pensa como devemos proceder? Existe uma configuração mágica que está faltando?

Obrigado em avançado, Justin

    
por Justin 13.12.2011 / 04:01

2 respostas

2

O MySQL Cluster raramente se aplica em uma configuração acessível pela web. Este produto está disponível principalmente para data warehousing em ambiente de cluster dedicado.

A replicação do MySQL (master / slave, dual master, etc.) não ajudará se você estiver inclinado a escrever. Para que a replicação aconteça, uma gravação deve ser 'encaminhada / executada' em todos os sistemas ... isso reduzirá facilmente seu desempenho global. Nota: a replicação pode ser útil se você tiver contenção de tabela (bloquear na tabela inteira), mas se você estiver usando innodb, eu ficaria surpreso que isso acontece com frequência. Além disso, o custo de desempenho de ter um escravo poderia ser mitigado pelo tempo economizado em um cenário de crise / recuperação - mas essa não é a pergunta feita.

Você pode examinar o conceito de fragmentação. Aliado ao MySQL-Proxy e a um script LUA cuidadosamente elaborado, você pode reescrever automaticamente suas consultas SQL para dividir a gravação em um cluster do sistema MySQL (cuidado com a taxa de falhas de instâncias da AWS).

Embora você diga que esse é um longo caminho, a opção de hardware dedicado deve ser cuidadosamente estudada. A maioria dos ambientes IAAS (como o AWS / EC2) estão preparados para uma tendência muito pesada em direção à leitura IO. No hardware dedicado, você pode aproveitar o cache SSD e / ou a classificação por níveis de armazenamento. Você também pode aproveitar a SAN dedicada, onde a capacidade de E / S OPS é adaptada para o seu requisito específico.

    
por 13.12.2011 / 04:16
2

Divulgação - Eu trabalho como parte da equipe de produtos do MySQL Cluster

Apenas para corrigir o ponto acima, o MySQL Cluster é comumente usado em aplicações web para escalar operações de escrita - o auto-sharding acoplado à replicação multimestre gera um alto throughput de gravação, ou seja, 2,5 milhões de gravações por segundo em um cluster de 8 commodities. Servidores Intel: link

Por outro lado, o data warehousing realmente não é uma carga de trabalho de destino

Recomendaria dar uma olhada no MySQL Performance Guide (reg obrigatório) que discute as diferentes estratégias de sharding: link

    
por 16.12.2011 / 16:59