Revisit - MySQL 5.1 vs 5.5

1

Muitos meses atrás, enquanto o MySQL 5.5 ainda estava na versão beta, essa pergunta foi feita antes. Agora que foi lançado e há algumas atualizações de manutenção, o que todos pensam?

    
por Zak 07.04.2011 / 01:15

2 respostas

2

EDIÇÃO # 1) Replicação semissíncrona

Um mestre com múltiplos escravos não é tão bom porque somente o primeiro escravo replicaria rapidamente e todos os escravos subseqüentes às vezes mudavam para o modo assíncrono dependendo de quanto tempo uma consulta demorava para ser executada. Em termos do primeiro escravo, isso é por design. Eu acho que não há garantias para escravos subseqüentes correndo em tempo hábil.

Por outro lado, simples mestre-escravo, representante circular e multimaster trabalham dinamite rápido IMHO.

EDIÇÃO # 2) Vários pools de buffers InnoDB

Eu tenho um cliente com 3 DB Server configurado como segue:
Dual HexaCore (12 CPUs)
192GB RAM
SAS RAID10 de 2 TB

O cliente tem 480 GB de dados espalhados por 780 bancos de dados. A replicação circular está sendo executada entre os três servidores de banco de dados.

Definitivamente, um dos recursos mais poderosos que eu tenho ativado para o InnoDB é o seguinte:

innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_io_capacity = 65536
innodb_buffer_pool_instances = 1
(padrão) innodb_bufer_pool_size = 162G

O MySQL 5.5 funciona como um sonho para este cliente. Todos os dados do cliente do cliente são virtualmente armazenados em cache na memória. Todos os 12 CPUs estão totalmente envolvidos devido à intensa atividade do InnoDB. Tudo dinamite rápido. Páginas sujas do InnoDB para o Buffer Pool são tão baixas e paginadas tão rapidamente.

Eu tentei configurar o pool de buffer assim primeiro (160 GB)

innodb_buffer_pool_instances = 64 (valor máximo)
innodb_buffer_pool_size = 2560M (2,5 GB)

Isso criou muito bloqueio de thread. Eu suspeito que isso é devido a ter dados relacionados armazenados em cache em diferentes pools de buffer. Tentar acessar esses segmentos de dados resultou em algum tipo de mutexing entre os buffer pools. Um colega de trabalho no meu trabalho (que é um Oracle Certified Master) me disse que o Oracle tem uma infraestrutura semelhante que você pode usar e o travamento de thread também é um problema, portanto eles não comercializam seu uso.

Todos os problemas de bloqueio de encadeamento do cliente desapareceram totalmente quando defini o seguinte:

innodb_buffer_pool_instances = 1
(padrão) innodb_bufer_pool_size = 162G

Minha conclusão em vários pools de buffers InnoDB

Eu estava ansioso para usar esse recurso, mas fiquei desapontado. Ter vários pools de buffers não o comprará muito se você tiver grandes conjuntos de dados relacionados mas espalhados pelos pools de buffer, introduzindo maior bloqueio de threads. Eu gostaria que você pudesse atribuir dados a buffer pools específicos, assim como você poderia pré-carregar caches de chaves MyISAM. Somente então múltiplos buffer pools seriam muito úteis.

Se você tiver bancos de dados de inquilino muito pequenos, mas muitos deles, vários buffer pools estarão OK. Ainda haveria problemas de bloqueio de thread, mas não tão graves.

IMHO gostaria de fugir de vários buffer pools para grandes instalações. Um gigantesco buffer pool com muitos threads trabalha mais eficientemente. Eu definitivamente focaria em usar mais threads de innodb e envolver mais CPUs, o que é uma vantagem sobre o MySQL 5.0 / 5.1.

    
por 07.04.2011 / 06:55
2

Re: problemas com innodb_buffer_pool_size e innodb_buffer_pool_instances:

Acho que há uma desconexão de como essas variáveis estão relacionadas. innodb_buffer_pool_size é o conjunto de buffers total disponível. Isso é então dividido entre o número de encadeamentos referenciados em innodb_buffer_pool_instances.

No exemplo de desempenho ruim acima, 2,5 GB foi dividido entre 64 instâncias, o que deixa 40 MB por instância. O mínimo recomendado (se você estiver usando essas opções) é de 1 GB por instância. Eu pude ver como 40MB por instância resultariam em desempenho ruim.

Em nosso ambiente de produção, estamos executando servidores com 3 instâncias, pool de 3 GB, para 1 GB por instância, sem paginação excessiva. Também estamos executando 4 instâncias, 10GB pool, também sem paginação excessiva (hardware mais novo, por que não aproveitar essa memória).

Espero que ajude.

    
por 21.10.2011 / 21:41