Usando um servidor de database central para muitos sites: plausível?

Basicamente, eu preciso de algumas partes de dados de database sincronizados em várias dezenas de sites. A solução perfeita seria criar um servidor central para hospedar esses dados.

Cada pageload terá que buscar dados de ambos os servidores de database – o local e remoto e grava no servidor remoto também será bastante comum.

Enquanto o servidor db pode ser tão rápido como desejado em hardware, eu sou cauteloso dos estrangulamentos:

  • Várias conexões de database devem ser estabelecidas em cada pageload.
  • Latência do sinal que viaja entre dois locais físicos.

Tenho razão em me preocupar? Seria mais fácil sincronizar os bancos de dados com cronjobs ou outras tecnologias?


Juntamente com a atribuição de uma recompensa, estou adicionando a questão que espera que um especialista com a experiência da vida real venha:

Que outras tecnologias existem (além do cron) para sincronizar bancos de dados MySql?

    qualquer método que sugira synchronization offline está desperdiçando os benefícios da replicação mysql

    (dada a situação pouco clara que você mencionou)
    sua solução pode ser tão simples como manter READ / WRITE separadamente

    Isso significa no database local,

    1. certifique-se de que o local esteja habilitado para leitura apenas para o database que você deseja sincronizar a partir do database centralizado
    2. A operação de escrita é comprometida com o database centralizado (em vez do database local)
    3. centralizar o database do que replicar a atualização para todos os bancos de dados locais

    problema

    1. atraso de replicação devido à latência da rede

    benefícios

    1. a integridade dos dados como operação de gravação só pode ser feita de centralizar o servidor e usar replicação para copiar alterações em vários bancos de dados locais
    2. O database local é possível para permitir a operação de gravação individual (outro dataset / database)
    3. A leitura do database local é muito mais rápida do que o database centralizado (considere que a operação de leitura é mais freqüente do que a operação de gravação)

    Estas perguntas são realmente baixas para a sua situação e acredito que você identificou os dois principais problemas com a solução DB central – então sim, você está certo em se preocupar.

    Eu pessoalmente optaria por sincronizar os dados com os servidores usando um cron (ou qualquer método escolhido) – reduzindo os custos de hardware e os tempos de carregamento da página. Isto para mim é a solução mais técnica, mas em termos de benefícios (tempos de carregamento de página mais rápidos, nenhuma dependência no DB central, custos mais baixos) é a solução correta.

    Alternativamente, você sempre pode configurar um pequeno database MySQL em um servidor remoto e criar alguns sites de testes e executar alguns benchmarks, isso lhe dará alguns dados sobre se você está feliz com os tempos de carregamento.

    A replicação do MySQL é definitivamente o caminho a seguir. O problema de ter um único servidor de database é que, se a carga se tornar muito alta, todos os seus sites irão diminuir. Você deseja espalhar a carga o máximo possível, porque se um servidor desce ou se sobrecarrega, é o fim de todo o problema.

    Algumas coisas a ter em mente ao lidar com a replicação

    • Você quer pelo menos 2 (de preferência 3 ou mais, 1 mestre e 2 escravos) servidores de database.
    • Você nunca grava seus servidores escravos. Todas as operações de gravação vão para o mestre, cuja replicação sincronizará os escravos logo após.
    • Você sempre lê dos servidores escravos (a menos que você precise garantir que você tenha os dados mais atualizados). Ao separar as operações de leitura e gravação entre servidores, você pode melhorar significativamente o desempenho.

    Jogue em um servidor de balanceamento de carga e os problemas de carga do database desaparecem!

    A maneira como o Google resolveu esse problema (você obtém algumas informações aqui . Desculpe, eu não tenho o link para o artigo publicado atualmente descrevendo isso) é mais ou menos através de uma série de triggersdores.

    Há um (e por um, eu quero dizer, milhares) de hub central de dados e uma série de clones. Cada vez que é necessária uma gravação, é solicitado um bloqueio do hub, a gravação é realizada no clone, que então encaminha a mudança para o hub (liberando o bloqueio). O hub empurra os dados para todos os outros clones.

    Isso significa que o access de leitura pode ficar quase instantâneo (você possui um clone localizado por instância do site). O access local de escrita também será rápido. Tudo o resto pode ser manuseado de forma assíncrona para que os dois servidores precisem apenas comunicar uma solicitação de bloqueio e uma mensagem de bloqueio recebida antes do início da gravação, e o empurrão pode acontecer depois que o usuário se deslocou.

    Isso pode ser um pouco para suas necessidades, mas é assim que o Google faz isso.

    Primeiro, um aviso, o que você está tentando fazer não é fácil; enquanto o MySQL suporta a replicação mestre / escrava e você pode ter vários mestres e escravos executando em todos os tipos de níveis, o que você realmente precisa pensar é “como eu me recupero de uma falha no servidor de database” – você promove um escravo? e a consistência (como é garantido que a replicação falhou entre os escravos)? etc. Você também precisa considerar modificações de esquema; tudo está bem e dandy, desde que você tenha o mesmo esquema em todos os servidores, mas, assim que você precisa pressionar uma atualização de código que requer uma mudança de database simultânea, você não pode confiar em que a mudança de esquema tenha sido promulgada para as replicações.

    Ok, aviso acabado, então, como você faz isso? O caminho mais fácil é abrir a versão mais recente do PhpMyAdmin, que permite configurar a replicação de forma muito rápida e fácil. Antes de fazer isso, certifique-se de que o log binário esteja ativado em todos os servidores MySql, pois esse será seu salvador de recuperação de falhas; http://dev.mysql.com/doc/refman/5.0/pt/binary-log.html

    Onde você localiza seus servidores é a próxima grande questão. Se seus usuários não estiverem dispersos geograficamente e suas cargas de consulta são baixas, você provavelmente poderá hospedá-los todos atrás de uma rede privada no mesmo data warehouse. A replicação mestre-escravo lhe dará uma grande elevação de desempenho em qualquer caso, uma vez que todas as leituras de database devem ser feitas contra escravos e apenas gravações executadas contra o mestre.

    Se você precisa localizar a localização geográfica, então não podem ser armazenados no mesmo data warehouse, então as coisas ficam um pouco mais difíceis; você agora tem latência para lidar com isso. Nessa situação, uma vez que a internet não é instantânea, uma escrita feita ao mestre levará tempo para se propagar para o escravo. Portanto, qualquer consulta de seleção feita muito pouco depois que a escrita provavelmente não retornará os novos dados, uma vez que ainda não será replicada para o escravo. Isso é chamado de “consistência eventual” e é relativamente fácil de superar quando você reconhece que vai acontecer e codificar para esperá-lo – ou seja, nunca assumir que os dados estejam presentes.

    Não posso responder a sua pergunta com qualquer justiça real neste site. Sua melhor opção é ler um livro, eu recomendo este;

    MySQL High Availability – ISBN-13: 978-0-596-80730-6

    Minha resposta rápida a isso seria usar um sistema de fila de trabalho como Gearman para descarregar o trabalho de synchronization também. Desta forma, isso não afeta o carregamento da página ou a experiência do usuário. Você simplesmente cria um trabalho do Gearman, e enviará o trabalho para o Gearman Queue e chegará a ele como puder.

    Isso também parece uma solução muito melhor, instantânea, para usar um cron. Porque isso aumentaria instantaneamente o trabalho para a fila e o manusearia quase que instantaneamente também. E como você parece querer replicar apenas dados selecionados, não vejo como a Replicação MySQL seria de muita ajuda.

    Eu trabalhei com o Gearman antes (mesmo com o PHP) e foi uma ótima solução para interromper o trabalho em outro lugar para ser concluída, quando o carregamento da página não precisava aguardar a conclusão desse trabalho.

    Embora isso possa não ser simples, como eu fiz isso parecer, já que você precisa configurar e aprender Gearman, mas é uma ferramenta muito útil.

    Espero que isto ajude!

    Eu queria saber se você está ou não usando o SQL Server como seu back-end ou outra coisa. Tenho certeza de que o SQL pode usar a Replicação SQL http://technet.microsoft.com/en-us/library/ms151198.aspx para alcançar o objective desejado. Nesse ponto, seus aplicativos locais acessariam sua própria instância SQL, enquanto cada instância sql “replicaria” e “sincronizaria” seus dados com o servidor DB principal. O resultado final é que seu database central estará sempre atualizado e terá dados agregados de todos e cada um dos servidores satelitais SQL. (Por favor, não me cite neste … Não sou um especialista em SQL.)

    (Desculpe, acabei de perceber que você está usando o PHP / MySQL … e provavelmente favorece a fonte aberta … No entanto, acho que isso vale a pena procurar.)

    Eu fiz uma synchronization de database entre o aplicativo php cliente-servidor e usei a próxima ideia http://vitana-group.com/article/php/data-synchronization