Recentemente, convidamos Alexei Lesovsky, do Data Egret, para transmitir Zinc Sale . A conversa acabou sendo interessante e informativa. Por isso, ofereço a transcrição desta edição. Devido ao volume impressionante, foi necessário dividir o texto em pedaços. Se você estiver com preguiça de esperar pela continuação, basta ouvir a versão em áudio aqui .
Olá pessoal, esta é a quadragésima edição do podcast Zinc Prod, e Anton Okolelov, Nikita Vasilchenko e Oleg Gritsak são anfitriões permanentes conosco no estúdio.
Anton : Então, hoje temos um convidado, Alexey Lesovsky. Lesha, por favor, apresente-se, quem você é, o que faz e assim por diante.
Alexei : Olá pessoal, meu nome é Alexei Lesovsky, pois Antokha já me apresentou. Estou administrando o Postgres, sou o PostgreSQL DBA (administrador de banco de dados), trabalho com o login todos os dias, 7 dias por semana, e administro bancos de dados clientes. Temos um escritório - é uma empresa de consultoria, está envolvida em administração, suporte e suporte. E pessoas muito diferentes nos procuram com seus bancos de dados, como regra, são empresas - pequenas, grandes, pequenas, de todos os tipos - têm problemas com o banco de dados, analisamos esses problemas e de alguma forma tentamos corrigi-los. Na verdade, resolvemos os problemas de outras pessoas, outras empresas. Algo assim.
Bem, no meu tempo livre, gosto de fazer coisas diferentes, caminhar pela floresta, fazer snowboard, caminhar, beber cerveja
Anton : beber cerveja defumada
Nikita : antes do lançamento Lyokha falou sobre cerveja defumada
Alexei : sim, cerveja defumada, há uma deliciosa, eu recomendo. Rauchbier Merzen.
Anton : ok, por favor me diga, seu dbshnik, você trabalha há muito tempo, há vários anos. Quão difícil é? Eles ligam para você à noite e pedem para você consertar a base. Liguei para você às cinco da manhã há cerca de um ano ou meio.
Alexei : sim, era, era um problema.
Anton : como você sobrevive, me diga
Alexey : escute, trabalho desde 2014. Até 2014, trabalhei como administrador de Linux em desenvolvimento web. O administrador tem muitas coisas, tivemos virtualização kvm, havia muito Linux, havia todos os tipos de Ruby-on-Rails, nginxs, php, rails ...
Oleg : Docker já esteve?
Alexey : o docker acabou de começar, não o introduzimos em nenhum lugar da produção, mas as tendências para isso já começaram.
E havia muitos postgres em nosso escritório. Depois, persegui um longo rublo e decidi que poderia trabalhar em dois empregos ao mesmo tempo. E ele começou a trabalhar como administrador remotamente em um escritório de Moscou. Combinei dois trabalhos, apenas os bancos de dados foram administrados pela consultoria Postgresql. Havia Max Boguk, Ilya Kosmodemyansky e, como administrador, comecei a fazer parte das tarefas associadas à embaixada. Bem, isto é, Comecei a pegar silenciosamente o pão deles. E, em algum momento, Max me diz isso: ouça e deixe você ir trabalhar conosco. Você deixará todo o seu trabalho, em meio período, e virá a nós em período integral.
Bem, concordei, não hesitei, em princípio me foi oferecido um salário comparável, consegui um emprego e comecei a trabalhar em casa. Agora, desde 2014, acabo trabalhando há 5 anos, trabalho especificamente com o pai, bem, à moda antiga, todos os tipos de temas administrativos, trabalho com eles por hábito. I.e. se em nossa empresa há um problema com algo para entender do lado do administrador, eles me jogam fora, eu entendo
Anton : Mas, em geral, é necessário conhecer essas coisas de administrador? Não está só lá, a base está no vácuo, está girando em algum lugar, você precisa configurar o sistema operacional, certo?
Alexei : sim, sim, é exatamente porque ele geralmente depende muito dos subsistemas do sistema operacional, da memória virtual e do gerenciamento de disco, ou seja, é como se ele próprio não operasse diretamente recursos, como se descarregasse todo esse trabalho para o sistema operacional, e ele próprio gerencia E / S de disco, gerenciamento de páginas de memória, isso é tudo, troca de processos e, portanto, se você encontrar um desligamento do postgres, precisará também há um pequeno truque no sistema operacional, como tudo funciona lá e como funciona na interface com o postgres.
Se, por exemplo, comparar com o Oracle, o Oracle possui, por exemplo, seus próprios subsistemas que funcionam com entrada e saída, ou seja, eles ultrapassaram o sistema operacional, eles podem trabalhar diretamente com o disco, mas no Posgres isso não é, você precisa saber como o sistema operacional funciona com o banco de dados.
Oleg : você tinha que dar suporte ao postgres no Windows?
Alexei : sim, eu tenho que, temos um cliente, eles estão no Windows, atendemos algum tipo de escritório em São Petersburgo, fizemos uma auditoria no banco de dados para eles. A base deles era no Windows, era geralmente assustador, nós nos conectávamos a algum protocolo através do protocolo do terminal, a Área de Trabalho Remota foi aberta, lançamos algumas coisas relacionadas à gravação do desempenho lá. Em suma, foi difícil, assustador, como um sonho terrível agora é lembrado. E agora os clientes estão basicamente todos sentados no Linux. Praticamente ninguém está no Windows.
Oleg : qual é a principal dor no Postgre que todos podem perceber?
Alexey : muitas pessoas querem um auto-filer e multi-master. Bem, multimaster, é claro, uma coisa assim, inatingível. Mas todo mundo trabalhou com o Galera (com o Mysql), e eles dizem: porque, também queremos um multimaster em andamento.
Bem, no progresso existem essas coisas, mas não no próprio núcleo progressivo, existem coisas que implementam o tipo de multimestre, mas que ainda não foram produzidas. Mas as pessoas querem um multimaster. E as pessoas também querem um arquivo automático. Mas agora, graças a Deus que Patroni apareceu, no Patroni você pode fazer um auto-filer, as pessoas estão introduzindo-o lentamente. Bem, em geral, do meu ponto de vista, Patroni se tornou o padrão de fato. Muitas grandes empresas já estão implementando. O mesmo Gitlab, eles fizeram relatórios recentemente, usam o Patroni, estão felizes com tudo, todos estão felizes.
Anton : Escute, você pode nos dizer em poucas palavras o que os clientes são para programadores simples? Estamos principalmente ouvindo líderes de equipe e programadores
Nikita : espere, posso te matar, e pedirei ainda mais aos não programadores para explicar o que é um multimaster
Alexei : veja, imagine agora, Antokha é um programador, ele escreve aplicativos, e o aplicativo precisa armazenar seus dados em algum lugar. Ele os coloca na base, na embaixada. Em algum momento, o banco de dados está localizado em um servidor e, em seguida, no servidor uma vez - e parou de funcionar. A fonte de alimentação está queimada e o aplicativo precisa continuar trabalhando com a base. E aqui surge a opção de que precisamos ter algum tipo de cópia do banco de dados e continuar trabalhando com ele. E mude para ele e, idealmente, não faça nenhuma alternância para que nosso aplicativo conheça essa segunda base e continue a gravá-la.
Na verdade, é uma multimaster, quando temos vários nós disponíveis para leitura e gravação, e nosso aplicativo pode trabalhar simultaneamente com eles e gravar dados em qualquer um desses nós e ler dados desses nós, mas a natureza é tão organizada que não idealmente alcançado, e há prós e contras, há desvantagens, seus próprios casos de uso para o uso do multimaster. O exemplo mais comum é que você não pode gravar os mesmos dados, relativamente falando, em duas instâncias, por exemplo, trabalhar com a mesma tabela, gravar na mesma tabela através de dois servidores, haverá conflitos e eles precisarão ser resolvidos, isso é um problema portanto, é necessário escrever se escrevermos em uma tabela, depois escreveremos apenas através de um servidor.
Nikita : e isso está diretamente relacionado ao ventilador automático, sim, ele está conectado?
Alexei : sim, e isso se deve ao auto-defensor, aqui, por assim dizer, um segue o outro. Se não pudermos pagar por um multimaster, queremos um tipo de mecanismo transparente que alterne o nó sobressalente para o modo mestre, ou seja, temos um aplicativo, ele funciona e, assim que o aplicativo é eliminado do banco de dados, o desenvolvedor não deseja alterar as configurações desse aplicativo e indicar o novo endereço do banco de dados, reiniciar o aplicativo, principalmente se houver muitos aplicativos. Eu quero algum tipo de mecanismo transparente que funcione em algum lugar oculto, troque o banco de dados e nosso aplicativo funcione com o mesmo endereço e continue lendo este banco de dados. Para fazer isso, você já precisa de um arquivador automático que alterne de forma transparente o nó sobressalente para o modo assistente e, para isso, o Patroni é usado apenas
Anton : Patroni é um switch puro ou um fork do postgres, algum tipo de complemento?
Alexei : esse, por assim dizer, é um serviço separado, um processo separado que é executado em um host com um banco de dados. E ele monitora o estado do cluster pós-cluster. Dois objetivos são perseguidos aqui - autofailover e gerenciamento de cluster. Mas, neste caso, obtemos um cluster distribuído, mas temos vários nós no cluster, um mestre e várias réplicas. Portanto, é necessário monitorar constantemente o estado do cluster, ver constantemente se o mestre está ativo. Se ele morreu de repente - você precisa mudar para o papel de "mestre" de outro servidor. E para isso é usado, em geral, existem duas abordagens: como apoiar esse cluster de visualizações, a representação no cluster de como ele deve viver no momento. Há uma opção quando cada um dos nós do cluster - eles checam um ao outro. E você pode armazenar esse estado fora, ou seja, Fora do cluster. E apenas Patroni usa essa abordagem, ele pega e armazena o estado do cluster no terceiro sistema. Geralmente, isso é algum tipo de DCS (configuração do sistema de armazenamento distribuído). Pode ser etcd, consul, ou pode ser kuberenetesovsky etcd. I.e. dependendo de qual é a infraestrutura. Bem, o Patroni simplesmente salva um estado de cluster neste sistema DCS e o atualiza.
Se um dos nós falhar repentinamente, um novo nó será selecionado. Se esse mestre, por exemplo, caiu, um novo mestre é selecionado e esse estado é atualizado novamente no DCS. E aqui, às custas da DCS, Patroni apoia a saúde do cluster.
Anton : E se a rede piscasse entre Patroni e a base?
Alexei : Bem, veja, existe um banco de dados, ou é algum tipo de servidor ou, digamos, no Kubernetes, pode ser algum tipo de sub. Considere um caso simples, digamos que seja um servidor. No mesmo servidor, temos um banco de dados em execução e, no mesmo servidor, o agente Patroni. Este é um processo leve, eles trabalham no mesmo host e se comunicam relativamente no host local. Nossa rede pode piscar entre o repositório DCS e o host em que a base e o Patroni trabalham.
Pode haver opções diferentes. Dependendo da gravidade dessa piscada na rede. Acontece que, se era um mestre, e ele se mostrou isolado, os outros nós descobrirão que o mestre se foi. Eles simplesmente selecionarão um novo mestre, e ele verá o antigo mestre isolado e Patroni o reiniciará no modo somente leitura. Bem, para que não haja cérebro dividido. É ruim se nosso aplicativo gravar em dois nós ao mesmo tempo. Então os desenvolvedores terão que coletar os dados, e este é um trabalho muito difícil - coletar esses dados de forma consistente. Portanto, o mandril apenas reinicia o nó em somente leitura e é isso, e funciona. Assim que a rede for restaurada, a Patroni poderá acessar o DCS, eles coordenarão ainda mais a visualização do cluster e chegarão a algum tipo de solução acordada. Provavelmente esse nó isolado, que era um mestre antigo, se conectará como uma réplica ao novo mestre ...
Anton . Bem, na prática, como isso funciona? Existem problemas, armadilhas. Para Oleg tomar e implementar, por exemplo, Patroni, ele precisa tomar uma decisão para isso.
Oleg . Sim imediatamente
Alexey . Bem, olha, estamos usando o Patroni com clientes desde o ano passado. Temos o primeiro cliente que apareceu na minha opinião em novembro de 2018. E naquela época, não tínhamos uma idéia muito boa de como trabalhar com isso, mas durante o ano em que trabalhamos, em princípio, tudo nos convém. Nós aprendemos a cozinhar. Em princípio, para trazer à mente, em geral, ele realmente não precisa de muitas etapas, literalmente duas ou três ações do lado do postgres, do lado das configurações do usuário, e tudo isso funciona muito bem.
A peça é confiável. É primeiro simples, está escrito em Python, consome pouca memória e funciona em princípio de maneira confiável. A única coisa na infraestrutura deve ser esse DCS. Mas, como regra, é necessário o Consul ou o etcd. Mas para muitas empresas, isso já é usado para todos os tipos de descoberta de serviços diferentes; portanto, como regra, não há problemas com isso.
E que tipo de problemas surgem: o problema mais básico sobre o qual as pessoas não se sentem imediatamente é que podemos perder alguns dos dados com o arquivador automático
Oleg : por causa do atraso na replicação?
Alexei : imagine uma situação em que um arquivador automático ocorre durante a replicação, o antigo mestre ficou offline, mas ainda escrevemos parte dos dados. Suponha que houve algum tipo de atraso na replicação, um novo mestre é selecionado dentre outras réplicas. Um novo mestre é criado e se Patroni estiver configurado de forma que o nó caído seja incluído automaticamente no cluster, por exemplo, a inicialização automática de serviços é ativada e, quando o antigo mestre aumenta, ele vê que não é mais um mestre, está atrasado, tentará se conectar ao novo mestre e se tornar sua sugestão. E nesse momento ele executa o comando pg_rewind.
Este comando rebobina o log de transações no nó antigo (o mestre antigo) até que possa se conectar ao novo mestre, ou seja, o log de transações é substituído. Nesse ponto, podemos perder alguns dados. No próprio Patroni, há pouca proteção, existem algumas reviravoltas que permitem que as réplicas não participem das eleições com um grande atraso. Se, por exemplo, todas as réplicas tiverem um atraso grande, as eleições simplesmente não serão iniciadas e a intervenção manual do administrador será necessária para que o administrador entre e inicie o arquivo automático manualmente. Ou todos vão esperar até que o velho mestre se levante. Até que seu trabalho seja restaurado. E eles já estarão conectados a ele e continuarão a capturá-lo.
Bem, isto é, no Patroni existem mecanismos que permitem que você não perca dados, mas há um risco, então você precisa
Anton : e a replicação síncrona?
Alexei : replicação síncrona, quando usamos replicação síncrona, perdemos desempenho. Nem todo mundo pode ir para este acordo. Mas se usarmos a replicação síncrona, o risco de perda de dados será reduzido. Mas se usarmos vários nós, digamos mais de dois, ainda precisamos considerar a opção quando tivermos um acidente na réplica mestre e na síncrona. E ainda temos uma segunda réplica, e pode ser que possamos capturá-la e perder alguns dados novamente. Diferentes opções são possíveis, elas precisam ser avaliadas, analisadas e entendidas se esse comportamento nos convém ou não.
Anton : escute, apenas dois servidores caem - é como prever uma invasão de alienígenas
Aleksey : e há uma batida na velha
Oleg : você se lembra da mesma ligação às cinco da manhã com Lesha pela última vez, com o que estava interessante, Anton, e não com a perda imediata de duas bases?
Anton : foi um fator humano. Bem, sim, isso acontece.
Alexey : a propósito, não lembro o motivo da ligação
Anton : nós transferimos dois servidores para lá, eles trabalharam em paralelo, registraram dados, não importa. E os sistemas poderiam funcionar em um, mas um foi transferido para outro data center, ligado. O segundo foi transportado até agora e houve algum tipo de fiação tocada no momento da instalação, e o antigo também foi cortado - eles misturaram algo. Em geral, nós dois servidores caímos, começamos a subir e, como eram rigidamente configurados para gravação, tinham pontos de verificação muito raros ou algo assim. Tudo começou por um longo tempo, não entendemos o que estava acontecendo
Oleg : cem shows wal-logs
Anton : não entendemos o que estava acontecendo, por que não começou e, como resultado, tive que fazer uma ligação. Bem, na verdade não havia nada de especial a ser feito ...
Alexei : bem, há a única coisa que provavelmente conectamos, parecemos que tudo está em ordem
Oleg : confirmou a morte do paciente
Anton : na verdade, você só precisava esperar, em geral.
Alexey . Sim, este é um problema conhecido. Com algumas configurações, os pontos de verificação são longos. Existe um problema.
Mas, em geral, se você se lembra dessa chamada noturna, na prática raramente ligamos à noite, temos uma automação especial configurada - em serviço, tudo está como deveria, selecionado de acordo com uma programação especial. Então, se você se lembra, bem, talvez a cada seis meses alguém ligue
Oleg : tudo da nossa empresa é provável
Alexey : não, diferente
Anton : Oleg, ligue com mais frequência
Oleg : faremos uma transição hoje, provavelmente ligarei
Alexey : nós temos caras, o horário da noite está fechando, eles vão funcionar
Anton : escute, Lech, você disse que Patroni tem alguns análogos. Como eles diferem, quais são
Alexey : existem basicamente duas opções, há repmgr, essa coisa apareceu há muito tempo, cerca de 10 anos atrás. Ele implementa um mecanismo quando os nós de um cluster pós-graça checam um ao outro, quem está vivo, quem não está vivo. Mas, na minha opinião, isso não é muito, eu realmente não gosto desse esquema de trabalho.
E não há um arquivador automático pronto para uso, o repmgr foi originalmente aprimorado especificamente para gerenciar o cluster e para alternar manualmente, para a alternância. E se você quiser arquivar automaticamente automaticamente, precisará instalar as demos repmgrd separadamente e, como se sabe, o arquivo automático será iniciado aqui. A coisa é conveniente, boa, mas sim - não temos um arquivador automático pronto para uso. Você precisa colocá-lo separadamente. Em geral, a coisa é boa, conveniente, no sentido de ser bem configurável, é conveniente manter clusters baseados em cluster. Ela é tão flexível, personalizável. As réplicas podem ser derramadas de várias maneiras. De backups, de réplicas a outras pessoas, do mestre. Em suma, uma coisa tão flexível, porque 10 anos. E muitos recursos diferentes foram introduzidos nele, é muito bom.
E outra opção é Stolon. Ele apareceu mais ou menos na mesma época que Patroni, um pouco mais tarde. Está escrito em Go.
Mas tem uma arquitetura mais ramificada. Se você abrir o site do projeto, haverá fotos e o próprio Stolon consiste em vários componentes. Ele tem nós guardiões que trabalham com bancos de dados que geram Postges. Depois, existem os chamados nós Sentinel. Eles monitoram o estado do cluster, verificam sua disponibilidade, verificam se os nós estão ativos ou não. Eles gerenciam o estado do cluster e o reconfiguram se algo acontecer.
E existem os chamados nós proxy, todo o tráfego passa por eles. O aplicativo cliente trabalha com proxies. -, - , . I.e. . , , Stolon DCS, consul, etcd. - .
, - , bare metal , , - , . . ( -) , , .
, . . , . , . oltp- . Stolon , .
, 6 8, . , , . , — wal_keep_segments — - , , , . , - . , . . I.e. , . , , . , — . .
: , , - Citus? , .
: Citus — . Citus , CitusDB, -. , , ,
: ?
: , , . . , pg autofailover. , . , , . , , . , , . , , . I.e. .
: Citus. , , . — , ...
: , ,
: , , , , ,
: , , . , , , . "in the wild" . , .
, " " , !