O MySQL deve ser instalado sozinho

Costumo ouvir pessoas fazendo declarações como "nossa máquina servidor MySQL falhou", o que me dá a impressão de que eles dedicam uma única máquina como seu servidor MySQL (acho que eles instalam o SO e apenas o MySQL nele). Como desenvolvedor, não um administrador de sistemas, estou acostumado a instalar o MySQL como parte de uma pilha LAMP junto com o servidor da web e o PHP.

Alguém pode me explicar:

• qual é o sentido de instalar o MySQL em um servidor separado? parece um desperdício de recursos quando posso adicionar toda a pilha de lâmpadas e servidores adicionais.
• se o banco de dados estiver em uma máquina separada, como os aplicativos que precisam usar se conectam a ele?

Quando sua plataforma de aplicativos e seu banco de dados estão competindo por recursos, geralmente é a primeira indicação de que você está pronto para um servidor de banco de dados dedicado.

Em segundo lugar, alta disponibilidade: configurar um cluster de banco de dados (e geralmente por sua vez, um cluster de servidor da Web / aplicativo com balanceamento de carga).

Eu diria também que a segurança desempenha um papel importante na mudança para servidores separados, pois você pode ter políticas diferentes para acesso à rede para cada servidor (por exemplo, um servidor Web DMZ'ed com um servidor de banco de dados na LAN).

O acesso ao servidor de banco de dados é pela rede. ou seja, quando você geralmente está especificando "localhost" para o host do banco de dados, deve especificar o endereço IP / host do servidor de banco de dados. Nota: geralmente você precisa modificar a configuração do servidor de banco de dados para permitir conexões / ativar a escuta em uma interface diferente da interface de loopback.

Um servidor de banco de dados separado é apenas parte de um bom design escalável. Isso não importa se seu tráfego não é muito alto e se realmente um único servidor é suficiente.

Mas em serviços mais ocupados, isolar os serviços um do outro é uma coisa boa. Se alguém fizer DDoS no servidor da Web e consumir todos os recursos, isso não intimidará o servidor do banco de dados. Em ambientes compartilhados, mais de um servidor da Web provavelmente está usando o servidor de banco de dados; portanto, se o servidor de banco de dados contiver dados para 50 sites diferentes, apenas um site desativado devido ao DDoS é melhor do que remover tudo.

Também do ponto de vista do sysadmin, fica mais claro se existem servidores dedicados nomeados com sensatez, como "mysql-01.yourcompany.com" e "webserver-01.yourcompany.com". Quando recebem alertas, eles veem imediatamente o que está acontecendo, pelo menos no sentido de "OK, há algo errado com o banco de dados". Eu sei que esse é um argumento fraco, pois vários nomes DNS podem apontar para um único servidor, mas ainda assim.

Seus aplicativos se conectariam a um servidor de banco de dados remoto sem problemas na rede. Aieeeeeee! Como o seu navegador da web se conecta a um servidor remoto? É Magica! Erm .... mais a sério, em vez de 'localhost', você apenas fornece o endereço do servidor em $ programming_language_of_your_choice e está tudo pronto.

• Alguns sites / aplicativos usam um banco de dados com tanta intensidade que exigem um ou mais servidores dedicados ao próprio banco de dados.
• Pela rede.

LAMP é a pilha de aplicativos, mas nem todos precisam ser instalados no mesmo host. Como outros observaram para fins de desempenho, segurança ou escalabilidade, eles geralmente não são instalados no mesmo host. Você também pode descobrir que o hardware ideal para uma parte da arquitetura pode não ser para outra.

Por exemplo, os bancos de dados são todos sobre gerenciamento de armazenamento. Quanto mais rápido eu posso obter informações do disco, mais rápido posso obtê-las para o solicitante. Se estou compartilhando um subsistema de disco com vários outros membros da pilha de aplicativos, como um servidor Web, a contenção que enfrento no recurso compartilhado dos heds de leitura e gravação das unidades de disco pode realmente prejudicar meu desempenho. Além disso, dividir a RAM entre o servidor da Web e o servidor de banco de dados em um determinado host pode não fornecer um pool de recursos grande o suficiente para ser executado da maneira mais eficiente possível, capaz de armazenar em cache o máximo de informações na RAM sem precisar ir para o disco. uma imagem, uma página ou um conjunto de resultados da consulta.

Administrativamente, também existem ganhos de eficiência. Imagine se você administra sua empresa em aplicativos de código aberto que utilizam o MySQL como um back-end comum. Deseja realmente ter uma proliferação de servidores de banco de dados em cada aplicativo? Pode ser um pesadelo do DBA: "OK, qual aplicativo usa esse banco de dados?" Você teria várias versões, várias configurações de hardware / software, várias estratégias de retenção de dados. Você provavelmente também teria habilidades administrativas muito difusas. Em vez disso, agrupe as instâncias em uma peça física de hardware otimizada para a função e atribua recursos dedicados para gerenciar o servidor e seus dados.

As consultas MySQL têm o potencial de consumir muitos recursos, o que pode desacelerar o servidor LAMP.

Quando você estiver executando um site grande, complicado e com muitos recursos, é aconselhável mover o banco de dados para outro servidor dedicado. Dessa forma, você tem dois servidores, um dedicado à Web e outro dedicado ao processamento de banco de dados. Isso tem o potencial de liberar recursos e acelerar as consultas ao site e ao banco de dados.

O servidor da Web simplesmente precisa se conectar ao endereço do servidor de banco de dados, em vez de localhostfazer suas consultas ao banco de dados.