Início / server / Perguntas / 997728
Accepted
laimison
Asked: 2020-01-06 16:02:17 +0800 CST

Cluster MySQL do Kubernetes em uma nuvem privada

  • 772

Estou interessado no cluster MySQL formado por 1 primário e 2 secundários.

Normalmente em uma nuvem pública nós

  • usar armazenamento externo

  • use serviços como RDS para que a replicação e o failover sejam tratados por trás desse serviço

  • você pode recriar o pod com falha em um nó diferente, porque o armazenamento e o banco de dados não estão sendo executados em nenhum de seus nós k8s

Solução que funcionou em uma nuvem privada, mas não no Kubernetes:

  • usando armazenamento local

  • usando o utilitário mysqlfailover para que ele possa nomear um novo

  • alterando o registro DNS de "mysql-0" (primário) e instruindo o aplicativo a atualizar o DNS para que ele possa ver um novo primário no evento de failover

Explorando a solução Kubernetes:

  • qual usar armazenamento local ou NFS? (se NFS, como você faria um cluster entre diferentes servidores?)

  • usando https://github.com/oracle/mysql-operator , Percona, soluções semelhantes ou até mesmo o mesmo mysqlfailover - qual você prefere e como ele lida com o caso de failover? É preferível a opção de código aberto.

Se eu tentar mesclar minha solução mysqlfailover atual e migrar para o Kubernetes, talvez seja necessário configurar o Node Affinity para que os pods conectem seus armazenamentos locais corretamente.

Além disso, este mecanismo mysqlfailover deve ser melhorado (o ponto de partida está aqui https://medium.com/@zzdjk6/step-by-step-setup-gtid-based-mysql-replica-and-automatic-failover-with-mysqlfailover-using -docker-489489d2922 ) porque pode, por exemplo, nomear um novo mysql-1 primário, enquanto o original (mysql-0) está inativo. Com base no meu entendimento, essa pode não ser a melhor opção, porque na arquitetura usual, sempre queremos ter o mysql-0 como primário em um StatefulSet enquanto o mysqlfailover funciona completamente o oposto.

Então, qual opção você escolheria se não resolvesse o problema existente? Quais passos você tomaria? Quais componentes MySQL e Kubernetes você usaria?

Muito Obrigado

mysql

1 respostas

  1. Best Answer

    A solução que encontrei foi o Percona XtraDB Cluster no Kubernetes. Possui um operador Kubernetes para gerenciar automaticamente os cenários de failover.

    Seu aplicativo não deve saber nada sobre clustering, porque é classificado de forma transparente em kubernetes-service-hostname:3306. Portanto, o aplicativo chama esse endereço e, por trás dele, há 3 contêineres SQLProxy/HAProxy (por servidor). Em seguida, a consulta é roteada para um dos três contêineres MySQL.

    Quando o servidor fica inativo, os contêineres SQLProxy/HAProxy e MySQL com falha são removidos do Kubernetes, portanto, kubernetes-service-hostnamecontém dois em vez de três membros.

    Quando o servidor está online novamente, os contêineres são criados para ter o cluster completo novamente.

    Há também o contêiner do operador Percona que ajuda automaticamente a gerenciar os pods e fazer outras ações para que o cluster esteja totalmente operacional.

    Em termos de armazenamento, pode ser apenas hostPathum diretório local que mostra um sinal de simplicidade da perspectiva de armazenamento. Você também pode usar PersistentVolumeClaime qualquer tipo de classe de armazenamento por trás dele ou armazenamento externo, como NFS.

    Na verdade, é uma configuração multi-mestre.

    Mais detalhes:

    https://www.percona.com/doc/kubernetes-operator-for-pxc/kubernetes.html

    • 0

relate perguntas