Arquitetura de banco de dados: réplicas
O curso explica como funciona uma réplica de leitura no Postgres e quando vale a pena ter uma. Ele trata do envio e da reaplicação do write-ahead log, da replicação assíncrona e do atraso de replicação, além dos papéis de escrita e leitura no Rails, com replica: true e connected_to. Analisa falhas de ler as próprias escritas, mede a fração de leitura e o tempo de banco de uma aplicação e aponta a única query que poderia justificar uma réplica. Mostra também como requisições GET podem escrever e termina com um desafio de roteamento.
O que você vai aprender
- ✓Como uma réplica recebe e reaplica o write-ahead log do primário
- ✓Por que o atraso de replicação cresce com as escritas e causa falhas de ler as próprias escritas
- ✓Como declarar os papéis de escrita e leitura no Rails e rotear com connected_to
- ✓Como medir se o primário está saturado antes de criar uma réplica
- ✓Como achar escritas escondidas em requisições GET antes de rotear por verbo HTTP
- ✓Como implementar a escolha entre primário e réplica a cada requisição
O que uma réplica realmente é
Uma réplica de leitura é um segundo banco que copia tudo o que o primeiro faz, um pouco depois. As duas metades dessa frase importam, e a segunda é de onde vem todo problema de réplica.
Ler a aula completa grátis →Currículo
7 aulasO que uma réplica realmente é
Uma réplica recebe e reaplica o write-ahead log do primário de forma assíncrona, e não serve como backup, shard ou failover.
O papel de leitura
O Rails declara os papéis writing e reading no connects_to, marca réplicas com replica: true e roteia explicitamente com connected_to.
O atraso de replicação é o problema inteiro
O atraso de replicação provoca falhas de ler as próprias escritas, cresce com o volume de escrita e tem janela padrão de dois segundos.
Esta aplicação não tem réplica
A aplicação não tem réplica porque só cerca de 21 ms de uma requisição de 72 ms são tempo de banco.
Quando uma réplica ajuda de fato
Uma réplica ajuda quando leituras caras que aguentam dados desatualizados saturam o primário, como poderia ocorrer com o Admin::StatsQuery.
As escritas escondidas nas suas leituras
O TrackLessonVisitService e o rastreador de atividade escrevem em requisições GET, o que quebra o roteamento para réplica por verbo HTTP.
Juntando tudo
Uma revisão do curso e um desafio de implementar choose_connection, incluindo o caso em que o tempo decorrido é igual ao atraso.