Não é aconselhável executar a replicação no mesmo servidor físico?

Estou pensando em configurar uma replicação Master-Slave 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 com os quais me deparo é que já estamos esgotados em nosso data center. Portanto, adicionar outro servidor físico não é uma opção.

Nosso servidor de banco de dados existente é bastante subutilizado na CPU (as médias de carga nunca são realmente superiores a 1 em um quad-core). Portanto, a idéia 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 recuperar. Mas imaginei que ter 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 sair).

Quanto ao aspecto do relatório, quaisquer tabelas das quais reportaríamos são MyIsam. Portanto, fazer leituras caras nas mesmas tabelas que estão sendo gravadas pode atolar o servidor. Minha suposição era que ter um servidor escravo para reportar não afetaria o servidor principal enquanto 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 nada). Se algo ruim o suficiente para derrubar o mestre acontecer, provavelmente também derrubará o escravo.

Para usuários puramente segregados por razões de direitos de acesso, um bom RDBMS oferecerá maneiras mais eficazes de fazer isso.

A execução dos 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 vários buffers e caches. Pode haver um benefício de desempenho através da segregação de carga de E / S, se os arquivos de dados para o escravo estiverem em unidades físicas diferentes das do mestre. Nesse caso, você pode executar relatórios complexos que exigiram muitas leituras de disco contra o escravo sem competir pelo mestre pela largura de banda de E / S da unidade.

Edit: como o DTest menciona em seu comentário abaixo, outro outro benefício possível de um banco de dados escravo (mesmo que nas mesmas unidades do mestre) é que consultas complexas de longa duração no escravo podem causar problemas de bloqueio no dia a dia as consultas de execução diária no mestre são mais seguras. Embora você ainda esteja melhor com o escravo em unidades diferentes, é provável que consultas significativas causem problemas de contenção de E / S.

Não está claro para mim como isso resolve seu problema. Não há redundância, pois ele 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 energia 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, talvez, mas, novamente, eu pensaria que isso poderia ter sido feito GRANT.

É realmente considerado imprudente, você está apenas tentando tirar proveito de mais núcleos? Quais são os objetivos da nova consideração de design?

(publicado como resposta e não como comentário para manter o foco da conversa

Esta 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 vantagem de múltiplos 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 múltiplos 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. Quaisquer picos na carga do servidor podem afetar todas as instâncias do MySQL em execução por causa de consultas ruins, consultas lentas, muitas conexões, uso de memória excedente, memória insuficiente do servidor, interrupção do cache e assim por diante, em qualquer instância do MySQL. Isso também aumenta a complexidade do aplicativo, tendo que acessar as diferentes instâncias do MySQL através do número da porta e você também estará à mercê do TCP / IP.

Eu cruzaria a replicação em um servidor diferente, ou seja, o escravo de A no escravo de B e o escravo de B em A. Nós 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 a restauração de um backup.