Como escalar o mySQL com muitos servidores de banco de dados (digamos, 20 servidores de banco de dados)

Question

Escalar de 1 servidor de banco de dados MySQL para servidor 4-5 é muito claro na documentação do site oficial do desenvolvedor do MySQL: link

Que tal escalar de 4 servidores para 20 servidores? nós apenas adicionamos como salves também? Significado 19 escravos com apenas 1 mestre? Isso significa que a velocidade de inserção será a mesma, independentemente de quantos servidores de banco de dados nós colocamos.

Existe uma maneira melhor de escalar para o MySQL, onde, quanto mais servidor nós colocamos, mais rápida será a velocidade de leitura e velocidade de gravação. Nós vemos que é uma necessidade, porque este é um sistema para empresa de transações pesadas (site A Trading)

Ah, evite armazenamento SAN, se possível. Se a SAN for necessária, também pode migrar o MySQL para o Cassandra.

    

Answer 1

Existem várias soluções.

Para obter o melhor desempenho de inserção com impacto mínimo em seu código, dê uma olhada nos clusters do mysql . Eles vão muito além da replicação e implementam transparentemente sharding. Eu acredito (mas precisaria pesquisar para verificar) que um cluster mysql pode atuar como um mestre na replicação master / slave. Então, por exemplo. você pode ter um cluster de 4 nós manipulando gravações replicando para uma dúzia de escravos.

Note que você pode implementar a replicação master / master - você pode efetivamente ter qualquer número de nós organizados em um anel - o que também lhe dará o benefício do desempenho do insert - mas com um número tão grande de nós, há risco aumentado de atrasos na propagação de atualizações.

Se você tem um esquema complexo, então você pode obter grandes benefícios usando o mecanismo de armazenamento federado para dividir os dados, embora mysql nem sempre otimizar consultas, tanto quanto possível neste cenário.

Você deve definitivamente estar a olhar para mysqlproxy ou alguma outra camada de abstração se você estiver indo para baixo a maioria dessas rotas.

    

Answer 2

Confira o armazenamento em cluster mysql-mmm ou ndb se você estiver lidando com muitos nós, mas esteja ciente de que, se você usar o MySQL Cluster (ndb), precisará alterar seu código de acordo.

O MySQL-MMM pode ser encontrado no link e o material ndb é parte do MySQL Cluster Server de mysql.com

    

Answer 3

Você pode querer examinar uma configuração do Distribution Master.

Isso envolveria a criação de um Escravo (chamado de Mestre de Distribuição) que possui três (3) características:

• log-bin Ativado
• log-slave-updates Ativado
• Todo banco de dados (exceto information_schema e mysql) possui tabelas BLACKHOLE somente

Que bem isso faria?

Imagine este cenário

• 26 instâncias do MySQL
  • ServerA é Write Master
  • ServerB é mestre de distribuição
  • ServerC ... ServerZ são Read Slaves of ServerB

Aqui está o que acontece quando um INSERT é executado no ServerA

• Registros do ServidorA Entrada para o INSERT em seu Log Binário Atual
• Thread de E / S do ServerB importa INSERT do Log binário do ServerA
• Registros de thread de E / S do ServerB INSERT em seus Logs de relay
• SQL Thread do ServerB lê INSERT de seus Logs de Relay
• ServerB processa o SQL
• Registros ServerB Entrada para o INSERT em seu log binário atual
• ServerB serve o INSERT de seu Log binário para o Log de retransmissão do ServerC ... ServerZ

Isso fornece os seguintes benefícios

1. O ServerA (Write Master) não fica atolado executando tarefas de replicação
2. ServerB (Distribution Master) não armazena dados localmente. Ele fornece apenas um canal para passar entradas de log binárias para todos os escravos de leitura. Assim, nenhuma E / S de gravação pesada.

Isso foi tentado por outras pessoas. Na verdade, eu respondi uma pergunta para alguém na DBA StackExchange e StackOVerflow . É uma opção viável para alguém disposto a fazer o trabalho de perna, mas tem uma boa distribuição de E / S de leitura em dois ou mais escravos.

Se você está preocupado com a alta disponibilidade, não há problema. Você tem duas opções:

OPÇÃO 1

Refaça a configuração da seguinte forma

• 26 instâncias do MySQL
  • ServerA é o Active Write Master
  • ServerB é mestre de gravação passiva
  • ServerC é o mestre de distribuição
  • ServerD ... ServerZ são Read Slaves of ServerC
  • ServerA e ServerB são pares de replicação circular
  • Backups para dados podem ser feitos no ServerB

OPÇÃO 2: Use MySQL e DRBD

Apresente redundância em nível de disco por meio de DRBD e ucarp

• 26 instâncias do MySQL
  • ServerA é o DRBD Primary com o MySQL sendo executado como Write Master
  • ServerB é DRBD secundário com o MySQL Down
  • ServerB fornece réplica em nível de disco do volume de dados do ServerA
  • Execute o ucarp para o DB VIP apontando para o DRBD Primário
  • ServerC é mestre de distribuição cujo mestre é o principal DRBD
  • ServerD ... ServerZ são Read Slaves of ServerC