Início / dba / Perguntas / 339275
Accepted
Sivakajan
Asked: 2024-05-06 20:30:28 +0800 CST

Acesse um armazenamento MySQL com duas instâncias independentes

  • 772

Tentei implantar a implantação do MySQL com Kubernetes, tendo três réplicas que acessam o mesmo armazenamento (PVC). Aqui está a configuração

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
  labels:
    type: local
spec:
  persistentVolumeReclaimPolicy: Retain
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteMany
  hostPath:
    path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Service
metadata:
  name: mysql-service
spec:
  type: NodePort
  ports:
  - protocol: TCP
    port: 3307
    targetPort: 3306
    nodePort: 30091
  selector:
    app: mysql
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  replicas: 2
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:latest
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: pwd
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: mysql-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-storage
        persistentVolumeClaim:
          claimName: mysql-pvc

Ao aplicar este arquivo de configuração kubectl apply -f file_name.yaml, você pode criar três pods, que acessam o mesmo armazenamento para os bancos de dados. Ao verificar o status dos pods kubectl get pods, você pode ver que apenas um pod está em execução e os outros estão em CrashLoopestado. O que está acontecendo é que, ao criar mais de uma instância para utilizar um armazenamento comum, apenas uma instância poderá adquirir o bloqueio do ibdata1arquivo. É por isso que apenas um pod fica íntegro e outros no CrashLoop. (você pode ver isso usando kubectl logs pod-name). O que eu quero é,

  1. Posso liberar o bloqueio do ibdataarquivo e usar o armazenamento para todos os pods? (geralmente não é possível, devido a problemas de consistência)
  2. Caso contrário, como posso criar a ideia proposta? (acessando um único armazenamento/volume usando várias instâncias de pod)?
  3. Você sugeriria outras ideias para conseguir acessar um único armazenamento usando várias instâncias de pod?

Suas respostas e ajuda são bem-vindas.

mysql

2 respostas

  1. Best Answer

    A única maneira de permitir que múltiplas instâncias do MySQL leiam os mesmos dados é definir todas, exceto uma, no modo somente leitura.

    https://dev.mysql.com/doc/refman/8.0/en/innodb-read-only-instance.html

    Este modo de operação é apropriado em situações como:

    • Várias instâncias do MySQL consultando o mesmo diretório de dados simultaneamente, normalmente em uma configuração de data warehousing. Você pode usar essa técnica para evitar gargalos que podem ocorrer com uma instância do MySQL muito carregada ou pode usar diferentes opções de configuração para as diversas instâncias para ajustar cada uma delas para tipos específicos de consultas.

    Leia a página do manual na íntegra para entender como configurá-la e como funciona.

    Mas não está claro na sua pergunta qual é o seu objetivo ao fazer isso.

    Se você quiser permitir que múltiplas instâncias do MySQL tenham acesso de leitura e gravação aos arquivos de dados, você não pode fazer isso. O InnoDB gerencia dados parcialmente no armazenamento e parcialmente em buffers na RAM, dentro do mysqldprocesso. Por exemplo, se você tivesse vários mecanismos, cada um deles teria seu próprio conjunto de buffers, buffer de log e outros buffers de memória, e estes não seriam coordenados. Portanto, é quase certo que seus arquivos de dados serão corrompidos muito rapidamente.

    Se o seu objetivo for diferente, descreva-o. Talvez outra solução seja possível.

    Re seu comentário:

    Você não pode ter mais de uma instância do MySQL executando e usando o mesmo datadir. Quando uma instância do MySQL é iniciada, é necessário bloquear o arquivo de espaço de tabela do InnoDB. Portanto, você pode fazer com que uma instância seja iniciada após a outra ser encerrada. Mas mais de uma execução ao mesmo tempo usando os mesmos arquivos de dados não funcionará (no modo leitura-gravação).

    Há muito tempo é um ponto fraco do Kubernetes executar serviços com estado, como um servidor de banco de dados. A maioria dos administradores de banco de dados que conheço recomenda que você use o Kubernetes apenas para aplicativos sem estado. Se esses aplicativos precisarem de um banco de dados, o banco de dados deverá ser executado de forma persistente, não em um ambiente Kubernetes.

    Sei que alguns fornecedores tentam oferecer suporte ao MySQL Server rodando no Kubernetes, mas é sempre uma tarefa difícil. Na minha opinião, as dificuldades superam as vantagens.

    • 3

  2. Cópia da minha resposta do stackoverflow:

    Você pode, mas não deve liberar o bloqueio, pois isso sacrificará a consistência e provavelmente resultará em um banco de dados quebrado (pelo menos em algum momento).

    Para implementar algo assim, você precisaria de um back-end de armazenamento com algum tipo de desduplicação, que descobriria que os arquivos de banco de dados de todas as três cópias são semelhantes e os desduplicaria automaticamente. O ZFS pode ser capaz de fazer isso e, no futuro, você pode querer dar uma olhada em simplesmente bloquear (isenção de responsabilidade simplesmente bloquear funcionário), já que estamos trabalhando nessa funcionalidade também.

    O ZFS pode ser sua melhor aposta no momento, mas tenha cuidado, o ZFS tem implicações de velocidade/latência. Embora seja o sistema de arquivos mais confiável do planeta, ele não foi projetado para maior rendimento ou menor latência, mas para maior confiabilidade.

    • 0

relate perguntas