Estou pensando em configurar uma replicação mestre-escravo para meu banco de dados. O servidor escravo será usado para redundância e possivelmente um servidor de relatórios. No entanto, um dos maiores problemas que estou enfrentando é que já estamos esgotando a energia em nosso datacenter. Portanto, adicionar outro servidor físico não é uma opção.
Nosso servidor de banco de dados existente é bastante subutilizado no que diz respeito à CPU (as médias de carga nunca ficam acima de 1 em um quad-core). Portanto, a ideia principal é lançar algumas novas unidades e dobrar a memória (de 8 GB para 16) e executar uma segunda instância mysql na mesma máquina física. Cada instância teria discos separados para o banco de dados.
Há algo de errado com essa ideia?
Editar (mais informações): (felizmente) nunca tive nada ruim o suficiente para derrubar o servidor, mas estou tentando planejar com antecedência. É claro que temos backups noturnos dos quais poderíamos nos recuperar. Mas imaginei que ter os dados redundantes em discos separados forneceria uma solução mais rápida se as unidades do servidor mestre falhassem (obviamente não se a máquina inteira falhasse).
Quanto ao aspecto de relatório, todas as tabelas das quais relataríamos são MyIsam. Portanto, fazer leituras caras nas mesmas tabelas que estão sendo gravadas pode sobrecarregar o servidor. Minha suposição era que ter um servidor escravo para relatar não afetaria o servidor principal, desde que jogássemos RAM suficiente nele (já que a carga da CPU ainda não foi um problema).
Para redundância em termos de confiabilidade do sistema e segurança de dados, executar um escravo na mesma máquina que o mestre não oferece nada (ou quase). Se algo ruim o suficiente para derrubar o mestre acontecer, provavelmente derrubará o escravo também.
Para segregar usuários puramente por motivos de direitos de acesso, um bom RDBMS oferecerá maneiras mais eficazes de fazer isso.
Executar os dois bancos de dados na mesma máquina exigirá mais RAM para executar com a mesma eficiência, pois os dois bancos de dados competirão por espaço para manter seus vários buffers e caches. Pode haver um benefício de desempenho por meio da segregação de carga de E/S, se os arquivos de dados do escravo estiverem em unidades físicas diferentes do mestre. Nesse caso, você pode executar relatórios complexos que exigiam muitas leituras de disco no escravo sem competir pelo mestre pela largura de banda de E/S do drive.
Editar: como DTest menciona em seu comentário abaixo, um outro benefício possível de um banco de dados escravo (mesmo que nas mesmas unidades que o mestre) é que consultas complexas de longa duração no escravo que poderiam causar problemas de bloqueio para o dia-a-dia -day-running consultas no mestre são mais seguras. Embora ainda seja melhor ter o escravo em unidades diferentes, pois essas consultas significativas provavelmente causarão problemas de contenção de E/S.
Não está claro para mim como isso resolve seu problema. Não há redundância, pois está no mesmo hardware físico, no mesmo kernel do sistema operacional, nos mesmos binários do MySQL, talvez em discos diferentes, mas no mesmo controlador de armazenamento etc. está tudo no mesmo kit, de onde vem a potência extra? Ou há algo mais que você está tentando obter dessa configuração?
Um uso concebível para isso seria segregar os usuários de alguma forma, mas, novamente, eu teria pensado que isso poderia ter sido feito com
GRANT.De fato, é considerado imprudente, você está apenas tentando tirar proveito de mais núcleos? Quais são os objetivos da nova consideração de design?
(postado como uma resposta, não um comentário para manter o foco da conversa)
Isso pode ser uma faca de dois gumes
Você pode executar várias instâncias do mysql como escravos somente leitura no mesmo servidor que o mestre, desde que cada instância do MySQL resida em um disco diferente. Isso só é desejável se você estiver executando versões mais antigas do MySQL que não tiram proveito de vários núcleos (CPUs). As versões mais recentes do MySQL podem ser ajustadas para realmente usar as CPUs múltiplas, tornando desnecessário o acesso a vários núcleos executando várias instâncias do MySQL.
Ao mesmo tempo, também é uma péssima ideia. Muitos clientes meus fizeram isso para economizar dinheiro na compra de servidores bare metal ou VM. Qualquer pico na carga do servidor pode afetar todas as instâncias do MySQL em execução devido a consultas inválidas, consultas lentas, muitas conexões, uso de memória saturado, memória insuficiente do servidor, cache thrashing e assim por diante, em qualquer instância do MySQL. Isso também aumenta a complexidade do aplicativo por ter que acessar as diferentes instâncias do MySQL por meio de seu número de porta e também você estaria à mercê do TCP/IP.
Eu cruzaria a replicação em um servidor diferente, ou seja, escravo de A em B e escravo de B em A. Executamos várias instâncias em nossos servidores e não tivemos problemas, pois nossos servidores MySQL não estavam em capacidade. O failover para um servidor em execução é muito mais rápido do que fazer uma restauração de um backup.