Recentemente notamos que várias de nossas migrações Rails acabam travando/congelando nosso app+DB em produção. A investigação preliminar revela que isso provavelmente se deve ao acesso simultâneo pelo aplicativo e à migração em uma tabela com leituras muito altas.
Faria sentido explorar uma configuração PG replicada (talvez mestre-escravo), onde todas as gravações e migrações são executadas no mestre e todas as leituras de alto volume são executadas no escravo?
Como o PG se comporta quando uma instrução ALTER TABLE é replicada para um escravo? O escravo também adquire os mesmos bloqueios de tabela? A replicação resolverá os problemas que estamos enfrentando atualmente?
Sim, essa é uma opção. Mas se você escrever suas migrações com mais cuidado (os padrões do Rails são bastante simplistas), você pode reduzir bastante o bloqueio necessário no mestre de qualquer maneira.
Por exemplo, em vez de
você pode escrever
O último não manterá um bloqueio forte sobre a reescrita da tabela e será muito menos perturbador. Ele faz mais trabalho em geral, mas com nÃveis de bloqueio mais baixos.
Se você tomar mais cuidado com a escrita e os testes de migração, verá que esse problema geralmente desaparece. Ajudei com alterações de esquema de tempo de inatividade quase zero em bancos de dados de vários terabytes e os mesmos princÃpios se aplicam lá.
Sim. Você sempre pode alternar leituras para o mestre enquanto a réplica aplica uma grande atualização de esquema que já está confirmada no mestre.