Atualmente tenho um Master com 2 slaves, todos rodando MySql 5.5.
Quais são as limitações na quantidade de escravos que posso conectar a um único mestre? quais parâmetros devem ser levados em consideração?
relate perguntas
-
Onde posso encontrar o log lento do mysql?
-
Como posso otimizar um mysqldump de um banco de dados grande?
-
Quando é o momento certo para usar o MariaDB em vez do MySQL e por quê?
-
Qual é a diferença entre a replicação do PostgreSQL 9.0 e o Slony-I?
-
Como um grupo pode rastrear alterações no esquema do banco de dados?
Não há limites em termos de configurações, mas você precisa estar ciente de alguns aspectos.
Você pode usar a replicação semi-síncrona, pois ela usa um bom algoritmo para enviar SQL para escravos, certificando-se de que pelo menos um servidor tenha todo o SQL mais recente nos logs de retransmissão dos escravos. (Veja minha postagem de 5 de agosto de 2011 A replicação do MySQL é afetada por uma interconexão de alta latência? )
No entanto, a replicação semi-síncrona só é boa para um dos N escravos.
Quer você tenha replicação semissíncrona ou não, basta dizer que quanto mais Escravos você tiver, mais processamento de CPU um Mestre terá que fazer para manter seus Escravos atualizados.
Para um mestre com N escravos, isso é...
Com replicação semi-síncrona, não é muito melhor porque Para um Master com N Slaves, isso é...
Se você tem que ter muitos Slaves, pense em usar um Distribution Master em uma topologia em estrela
Se você não pode configurar um mestre de distribuição em uma topologia em estrela, aqui está minha regra simples: use a replicação semissíncrona, mas use o mínimo possível de escravos.
Não há limite rígido para o número de escravos que você pode anexar a um mestre, mas há um limite prático e é baseado em sua carga de trabalho e hardware. Vamos supor que você tenha um "grupo" de máquinas idênticas que deseja unir em uma topologia em estrela (1 mestre, muitos escravos). Neste cluster hipotético, vamos supor que seu mestre ficou sobrecarregado porque atingiu sua capacidade máxima de 2.000 operações por segundo, onde 1.000 delas são escritas e 1.000 são lidas (para simplificar, assumiremos que 1 leitura e 1 gravação têm um equivalente "custo").
Então, adicionamos um escravo e movemos todas as leituras para o escravo. Na prática, é impossível mover todas as leituras para um escravo, mas isso é apenas um exercício. Lembre-se, você não pode escalar gravações com replicação porque as gravações ainda precisam acontecer em cada nó.
Hmm...Adicionamos um escravo, mas não aumentamos nossa capacidade. O escravo já está na capacidade máxima. Então, adicionamos outro escravo e balanceamos a carga das leituras
Agora estamos chegando a algum lugar e temos um pouco de espaço para crescer. Mas, uh-oh, chegamos à primeira página do slashdot, então, de repente, nosso tráfego dobrou e agora estamos fazendo 2.000 wps e 2.000 rps!
Isso está ok. Teremos algumas caixas extras por aí, então adicionaremos mais alguns escravos
Ei, oi. Não importa o que façamos, não podemos melhorar essa situação sem sharding para reduzir as gravações ou escalar TODOS os servidores para que tenham maior capacidade de operações por segundo.
Outra consideração é que seu mestre está recebendo várias leituras simultaneamente, mas elas são serializadas no log binário e, em seguida, reproduzidas em um único thread no escravo. Portanto, embora você consiga acompanhar 1000 wps no mestre, o escravo pode lidar apenas com 250 wps sem ficar seriamente atrasado. Isso significa que em ambientes de alta gravação, os escravos podem realmente precisar ser mais poderosos (em termos de CPU e capacidade de E/S) do que o mestre para acompanhar.
Eu lido com sistemas com mais de uma dúzia de Escravos pendurados em um Mestre. Sem problemas.
A sobrecarga no mestre é muito baixa - coloque coisas em um soquete (por escravo).
É possível "se espalhar", mas os "relés" se tornam "pontos únicos de falha". Ou seja, o Mestre poderia enviar para alguns Relays (tanto Escravo quanto Mestre), cada um enviando para alguns Escravos.
Mova a maioria das leituras para os Escravos. Isso é "escala de leitura". Isso ajudará a descarregar o Master.
Escala de gravação requer sharding. (Aaron faz alusão a isso.)
"Dual Master" são duas máquinas que são mestre e escrava entre si. É útil para failover, mas não é útil para dimensionamento de gravação. Não grave em ambas as máquinas em uma configuração de mestre duplo; você está procurando problemas. Em vez disso, faça as leituras irem para o 'mestre de backup'.
Comente sobre os números de Aaron -- O mestre raramente tem "0 rps". Geralmente, algumas leituras são necessárias para preparar as gravações. Estes são chamados de "leituras críticas" e não podem ser movidos para o(s) escravo(s).