On 12-06-2015 13:42, Carlos Adean wrote: > Em 11 de junho de 2015 22:55, JotaComm <[email protected]> escreveu: >> Você realmente precisa fazer isso? E as operações que estão rodando durante >> a atualização? >> > > Sim. Enviamos notificação aos usuários e interrompemos todas as > operações antes de qualquer atualização. > >> Lembre-se que as sessões já iniciadas não serão interrompidas por causa >> desta alteração. Se alguma aplicação está fazendo um UPDATE por exemplo e >> você tentar aplicar alguma modificação nesta tabela, você ficará bloqueado. > > Ocorre exatamente isso, ficamos impedidos de fazer as alterações na > estrutura do banco. > >> >> Como é sua aplicação? OLTP, OLAP? Tem períodos mais tranquilos para você >> fazer este tipo de operação? Detalhe um pouco o teu cenário. > > As aplicações têm como núcleo um framework que criamos para análise de > dados científicos e que utiliza dois bancos de dados, um que > denominamos "catálogo" e possui grande volume de informações que mui > raramente sofrem mudanças, e outro chamado "administrativo" onde > constantemente alteramos sua estrutura. O problema está quando > precisamos mudar a estrutura deste último que citei, pois as > aplicações que fazem a interface dos usuários com o "catálogo" se > utilizam deste banco "administrativo". > > Como falei acima o que fazemos é notificar aos usuários e em seguida > interrompemos o acesso ao "administrativo" para que as novas mudanças > estruturais possam ser executadas, consequentemente isso para tudo. > Procurando melhorar o processo de atualizações para produção é que > resolvi postar a pergunta que origina essa thread. >
Só uma contribuição, certa vez para resolver esse impasse fiz uso do pgbouncer, ou seja, todos aplicativos se conectavam via esse pool de conexões e quando eu precisava rodar alguma DDL eu simplesmente executava um "PAUSE" no pool, abria uma conexao direta com o PostgreSQL (sem passar pelo pgbouncer por conta do pause claro) e aplicava minha DDL, logo após um "RESUME" no pool para a coisa continuar. O efeito para o lado do cliente é a sensação de "lentidão" nesse período pois qualquer query o pgbouncer segura até o pool ser liberado. Att, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
signature.asc
Description: OpenPGP digital signature
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
