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.