replicação de banco de dados para nova inscrição de usuário

Question

Eu tenho um banco de dados que armazena os usuários do meu aplicativo. Quando um novo usuário se inscreve, um registro é inserido no banco de dados desse usuário. Eu tenho uma versão replicada (escravo) deste banco de dados (usando o mysql por enquanto).

O que me preocupa é este cenário:

etapa 1: o usuário se inscreve e o registro do usuário é inserido no banco de dados

etapa 2: o usuário tenta efetuar login e o processo de login consulta o banco de dados para o usuário. no entanto, essa consulta atinge o banco de dados escravo, mas o registro do usuário ainda não foi replicado no escravo e retorna um erro que o usuário não existe.

Este é um exemplo bastante trivial, mas posso ver como isso se aplica a muitos casos. Existe uma estratégia para configurar bancos de dados replicados para ajudar a evitar essa situação?

    

Answer 1

Este é um problema real e acontece quase tão logo você começa a tentar gravar no mestre e ler do escravo. Embora o intervalo de tempo entre a inscrição do usuário e o login do usuário seja provavelmente longo o suficiente para não ter que se preocupar com isso, a maioria das coisas que os usuários desejam fazer causará esse problema.

Ações como criar um fórum ou uma postagem de blog geralmente resultam em um redirecionamento que as leva de volta a uma página na qual podem ver a postagem que acabaram de criar. Se esta página for lida do escravo, haverá apenas uma fração de segundo entre a gravação e a leitura, o que geralmente não será suficiente para permitir a replicação.

Existem três soluções que usei no passado e uma que não usei pessoalmente.

1. Monitore o atraso de replicação no escravo, retire-o da piscina se ficar atrás do mestre. A maneira mais confiável de gerenciar isso é usando a ferramenta heartbeat do kit de ferramentas Percona. Isso provavelmente não resolverá o problema da postagem no fórum.
2. Continue a fazer consultas do mestre para determinadas categorias de consultas. Por exemplo, a página de pós-sucesso e as páginas do CMS ou do centro de administração só consultariam o mestre. Isso coloca uma carga extra no mestre.
3. Use o armazenamento em cache. Algo como Memcached ou similar. As gravações suscetíveis a esse problema devem ser gravadas simultaneamente no memcached e as leituras devem vir de lá primeiro. Faltas são lidas do escravo, o que significa que ainda vale a pena ter um. Você terá que modificar cada parte do seu aplicativo que lê ou escreve, mas se você tiver abstraído corretamente isso não deve ser difícil. Você poderia também implementar isso usando algo como o mysql-proxy, mas eu não posso realmente recomendar essa opção.
4. Replicação síncrona. Eu não acho que o MySQL pode fazer isso, mas eles têm algo chamado replicação semi-síncrona vindo na próxima grande versão. A idéia é que a consulta de gravação original não retornará até que os dados também tenham sido gravados no (s) escravo (s). Isso tem o inconveniente de fazer com que suas consultas de gravação demorem mais e toda a sua plataforma caia quando o escravo faz isso.

A opção 3. foi a mais bem sucedida no passado para mim e é a opção que eu escolheria no futuro.

    

Answer 2

Não realmente (que eu saiba); você teria que ter algum atraso significativo (ou ter tido uma falha séria, fazendo com que o escravo ficasse fora de sincronia) para um usuário efetuar login e possivelmente atingir o banco de dados escravo mais rápido do que o banco de dados escravo pode replicar o servidor. >

A única alternativa em que consigo pensar é ter algo no nível do aplicativo que atinja o mestre, se o escravo não conseguir encontrar o registro; mas isso derrota o propósito de poder consultar o escravo em primeiro lugar.

    

Answer 3

Antes de executar a consulta, verifique se o banco de dados é escravo. Em caso positivo, verifique se os encadeamentos escravos estão em execução e, em caso positivo, verifique o Seconds_Behind_Master . Tudo em SHOW SLAVE STATUS; . Se não estiver em execução ou se houver um atraso significativo, execute a consulta no master.