O que são bancos de dados Master e Slave e como o emparelhamento deles torna as aplicações web mais rápidas?

Uma base de dados é "escrava" de um "mestre" quando recebe um fluxo de atualizações do mestre em tempo quase real, funcionando como uma cópia. O "slave" deve simplesmente aplicar as alterações que o master validou e aprovou.

Em princípio, pode-se criar uma configuração master-slave transferindo arquivos muito rapidamente de um servidor para o outro; mas na prática, cada banco de dados tem seu próprio protocolo de replicação especializado.

Existem muitas razões pelas quais uma réplica faz com que as consultas retornem mais rapidamente. Uma é que a CPU do master's é menos sobrecarregada por consultas enquanto a CPU da réplica's é menos sobrecarregada por escritas; por isso há mais CPU disponível para fazer trabalho. Outro é que os dados, enquanto nominalmente armazenados em disco, são armazenados em cache na RAM quando isso é possível; e de fato o SO faz isso, quer o banco de dados peça ou não, e pode ser imprevisível sobre isso. No master, porções recentemente escritas do banco de dados e qualquer coisa usada para suportar escritas -- por exemplo, índices usados para verificar a singularidade -- estarão na RAM o tempo todo; estes devem compartilhar espaço com as porções do banco de dados carregadas para servir consultas. A réplica precisa't carrega tantos dados para suportar sua carga de escrita (está escrevendo para as mesmas partes do banco de dados, mas pode ingenuamente submetê-la sem verificar nada) e torna mais RAM disponível para servir consultas.

Existe também a questão do acesso ao disco. Quando os dados são escritos no master, eles devem ser escritos no disco antes que o master possa retornar uma mensagem de commit bem sucedida para a aplicação. Para gravar no disco, o sistema operacional deve disponibilizar a cabeça do disco. Se a cabeça do disco estiver longe do local onde precisamos gravar o registro atualizado ou adicionado, então ele deve ser movido. Para que a cabeça de disco "procure" pode ser bastante demorado, em relação a outras operações. Por esta razão, os desenvolvedores de banco de dados escolheram inteligentemente ter seus bancos de dados gravando todas as alterações uma após a outra, um ao lado do outro no disco, até que algumas alterações tenham sido gravadas. Assim, a cabeça do disco precisa de't mover-se do local onde estava quando o último registro foi escrito. Este registro de registros não os armazena da maneira mais eficiente -- a "pilha" da base de dados é onde os registros são armazenados mais eficientemente -- mas para alguns registros de cada vez, isso'não é um problema. De vez em quando, o software da base de dados pega todas as mudanças registradas e as grava na pilha. Este último passo, de fato, move a cabeça do disco; mas pelo menos nós temos'não o movemos para frente e para trás por toda a pilha para cada e toda mudança. Reduzir procura melhorar muito o desempenho médio da base de dados's.

Leituras não permitem este tipo de atalhos. Para ler os dados, devemos ir ao seu lugar no disco e lê-los. Isso reintroduz pressão para mover a cabeça do disco para frente e para trás. Uma réplica tem sua própria cabeça de disco (ou cabeças) e pode, assim, assumir alguma desta carga de busca por consultas.

Uma pessoa poderia perceber estes mesmos benefícios ao obter um servidor maior, também; um com mais discos, CPU e RAM. Fazer isso sem tempo de inatividade é um pouco difícil, no entanto. E enquanto uma réplica lhe dá uma opção no caso do master cair, um grande servidor de banco de dados não é mais confiável do que um pequeno servidor de banco de dados.