MariaDB 문제 원인 (마스터 서버에서 쓰기 작업중이면 100% 깨짐.)

 

MariaDB   마스터 서버에서 쓰기 작업중이면 100% 깨짐.!

문제  개선방안 제안 3가지!
*   제안 1  : vm 웨어를 3대 띄워서 작업가능은 하나 API 도달의 한계
            장점 : 현장에 남아도는 VM가능(빠르게 설치 , 복구  재현 테스트 가능
            이슈 :  API 도달의 한계를 넘기위해선 멤먼스 15명(구축시 필요했던 구축멤버) 투입필요
                       현재 남아 있는 멤버는 2명이고, 확인할수 있는 API DB 쪽의 리스트업 요청 
                       받아보고 진행예정

------------------------------------------         아래구성방법으로 진행  -----------------------------------------------------
*   제안 2  : 기존의 상태를 재구현하여 여러형태로로 테스트 구현중

      1) InnoDB 플러시 설정 
      2) StatefulSet 및 Pod 종료 처리(설정완료)
      3) 스토리지 선택 및 성능 최적화
                장점 : 시도중에 여러형태의 확인가능성 확장
                단점 : K8S 의  마리아 DB 의 레퍼런스 한계성과 실제 물리적은 성능보장필요(특히 스토리지)
      4) 고가용성(HA) 및 자동 Failover 구성

                방법 : Maxscale  , 갈레라 

      5) 백업 및 복구 전략 수립

        *   방법  : 매일 01:00 에 백업을 진행중이며, 백업파일을 복구하는데
                소요되는 시간은 10분내외 입니다.
                장점 : Database 6개, Table 약 70개 구성됨
                          (k8s DKS 현황 자료 구성, User, Project, enduser, namespace 등 ) DB file 로 구성되어 빠른
                            백업및 복구 가능
                단점 : 소요시간동안 downtime 이 전체복구 30분 소요!(전제조건)

      6) 프로메테우스와 같은 모니터링 시스템 구축(구축완료) 모니터링중.

*   제안3 :  kind cluster(Contaner k8s)  이용하여 현상을 local 재구현 가능
                장점 : 빠르게 설치 , 복구  재현 테스트는 완료
                단점 : 현장과 똑같은 환경재현은 불가(kubepray로 구성됨)

Kubernetes(K8s) 환경에서 설치된 MariaDB의 마스터 서버에서 쓰기 작업 중 서버가 중단되면 리플리케이션이 깨지거나 데이터가 손상되는 문제가 발생할 수 있습니다. 특히 쓰기 작업 중단은 MariaDB의 트랜잭션과 스토리지 문제로 이어질 수 있기 때문에, 이 문제를 해결하기 위한 다양한 방법을 고려해야 합니다. 아래는 그 원인과 해결 방안을 제시한 내용입니다.

문제 원인

6월 정상

8월 비정상 (원인파악)

1. 비정상적인 Pod 종료: 마스터 서버에서 쓰기 작업 중 Pod가 비정상적으로 종료되거나, 네트워크 문제 등으로 인해 MariaDB가 정상적으로 종료되지 않으면 트랜잭션이 불완전하게 끝나 데이터 손상이 발생할 수 있습니다.
2. 트랜잭션 불일치: 쓰기 작업 중에는 여러 트랜잭션이 진행되며, 작업이 중간에 중단되면 데이터 불일치가 발생할 수 있습니다. 트랜잭션이 롤백되지 않거나, 미완성 상태로 남으면 리플리케이션 과정에서 문제가 발생합니다.
3. 스토리지 성능 문제: 스토리지(I/O)가 지연되거나 충돌이 발생하면, MariaDB가 데이터를 정상적으로 쓰지 못하여 데이터 손상이 발생할 수 있습니다. 특히, 비동기 리플리케이션을 사용하는 경우 마스터와 슬레이브 간의 데이터 불일치가 심해질 수 있습니다.

해결 방법

1. 트랜잭션 설정 최적화

MariaDB에서 트랜잭션의 안정성을 높이기 위해 InnoDB 관련 설정을 최적화하는 것이 중요합니다.

https://minsql.com/mysql/mysql-innodb_flush_method/

• InnoDB 플러시 설정: MariaDB는 데이터를 디스크에 쓰기 전에 메모리에 데이터를 저장합니다. 이를 적절하게 설정하지 않으면 비정상 종료 시 데이터가 손실될 수 있습니다. 특히, 다음과 같은 설정을 고려해야 합니다.
  • innodb_flush_log_at_trx_commit = 1: 각 트랜잭션이 커밋될 때마다 로그를 디스크에 플러시하여 데이터 안전성을 보장합니다.
  • sync_binlog = 1: 각 트랜잭션 커밋 시점에 바이너리 로그를 디스크에 동기화합니다. 이는 장애 시 데이터를 잃지 않도록 보장합니다.
  위 설정을 적용하면 성능이 다소 저하될 수 있지만, 데이터 안정성 측면에서 매우 중요합니다. 특히 K8s 환경에서는 Pod가 언제든지 재시작될 수 있으므로, 데이터 손실을 방지하기 위해 이러한 설정이 필요합니다.

[mysqld]
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

2. StatefulSet 및 Pod 종료 처리

Kubernetes에서 MariaDB와 같은 상태 저장 애플리케이션은 StatefulSet으로 배포해야 합니다. StatefulSet은 Pod의 순차적 종료 및 재시작을 지원하며, 특정 Pod가 종료될 때 상태를 보존할 수 있는 메커니즘을 제공합니다.

1. StatefulSet graceful shutdown 설정: Pod가 종료될 때 MariaDB가 안전하게 쓰기 작업을 완료할 수 있도록 preStop 훅을 설정합니다.이를 통해, Pod가 종료될 때 MariaDB가 정상적으로 종료되어 트랜잭션이 완료되거나 롤백됩니다.
   

   lifecycle:
     preStop:
       exec:
         command: ["sh", "-c", "mysqladmin shutdown"]

2. terminationGracePeriodSeconds 설정: Pod가 종료될 때 K8s에서 충분한 시간을 부여하여 안전하게 종료할 수 있도록 합니다.이를 통해 Pod 종료 시 MariaDB가 트랜잭션을 안전하게 마무리할 수 있습니다.

terminationGracePeriodSeconds: 60

 

3. 스토리지 선택 및 성능 최적화

K8s 환경에서 **Persistent Volume (PV)**와 **Persistent Volume Claim (PVC)**을 사용하여 스토리지를 구성할 때, 스토리지 성능이 매우 중요합니다. 특히, MariaDB와 같은 데이터베이스는 빠른 쓰기/읽기 성능이 요구되므로 고성능 스토리지를 사용해야 합니다.

1. 스토리지 클래스 선택: 스토리지 클래스를 설정할 때 고성능 SSD나 NVMe 기반의 스토리지를 사용하도록 설정합니다. 이를 통해 I/O 성능을 높이고, 쓰기 작업 중에 발생할 수 있는 병목을 줄일 수 있습니다.
2. IOPS 및 스토리지 용량 조정: MariaDB가 사용하는 스토리지의 IOPS(Input/Output Operations Per Second)와 용량을 적절히 조정하여 데이터베이스가 처리량에 맞는 성능을 낼 수 있도록 해야 합니다.

storageClassName: fast-ssd

4. 고가용성(HA) 및 자동 Failover 구성

 

 

마스터 서버에서 쓰기 작업 중 다운되는 것을 방지하거나, 다운되었을 때 빠르게 복구할 수 있는 고가용성(HA) 구성을 도입해야 합니다.

1. Galera Cluster 도입: MariaDB에서 Galera Cluster를 사용하면 동기식 마스터-마스터 복제를 통해 고가용성을 구축할 수 있습니다. Galera Cluster는 모든 노드에 동일한 데이터를 유지하며, 하나의 마스터가 다운되더라도 다른 마스터에서 계속해서 쓰기 작업을 수행할 수 있습니다. 
   

   

   
   
   
   • Galera Cluster는 데이터 손실 방지와 자동 복구 기능을 제공하므로, 쓰기 작업 중 발생하는 장애를 줄일 수 있습니다.
     
     https://yunhyeonglee.tistory.com/46
2. MHA (Master High Availability) 도입: MHA는 마스터 서버가 다운되면 자동으로 새로운 마스터를 선출하는 Failover 솔루션입니다. MHA는 슬레이브 노드를 마스터로 승격시키고, 리플리케이션을 재설정하여 서비스 중단을 최소화할 수 있습니다.
3. MHA를 사용하면 마스터 서버에서 쓰기 작업 중 다운되는 문제를 자동으로 해결할 수 있으며, 새로운 마스터가 지정되어 쓰기 작업이 지속됩니다.

 

5. 백업 및 복구 전략 수립

백업 형태 :
    a. 전체 백업(Full Backup) 복구
    b. 증분 백업(Incremental Backup) 복구

    c. mysqldump ,Mariabackup

    d. 컨테이너(Container) 기반 MariaDB의 증분백업,복구
    e. Binary_Log 를 이용 백업, 복구

 

 

https://velog.io/@tkfrn4799/mariadb-mariabackup

쓰기 작업 중 장애가 발생해도 데이터를 복구할 수 있는 백업과 복구 전략을 반드시 수립해야 합니다.

1. 정기 백업: K8s 환경에서 CronJob을 Crontab 사용하여 MariaDB 데이터를 정기적으로 백업합니다. 이때, 모든 트랜잭션 로그와 데이터를 백업해야 하며, 장애 발생 시 데이터를 신속히 복구할 수 있도록 준비해야 합니다.
2. 즉시 복구: 데이터 손실이나 장애가 발생한 경우, MariaDB의 백업 파일과 바이너리 로그를 이용해 복구할 수 있는 절차를 준비해야 합니다. 이를 통해 쓰기 작업 중 손상된 데이터를 복구할 수 있습니다.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: mariadb-backup
spec:
  schedule: "0 3 * * *"  # 매일 새벽 3시에 백업
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: mariadb-backup
            image: mariadb:10.5
            command: ["sh", "-c", "mysqldump --all-databases > /backup/db-backup.sql"]
            volumeMounts:
            - name: backup-storage
              mountPath: /backup
          restartPolicy: OnFailure

6. 프로메테우스와 같은 모니터링 시스템 구축

MariaDB와 Kubernetes 환경에서 발생하는 문제를 빠르게 감지하고 대응하기 위해 Prometheus와 Grafana 같은 모니터링 시스템을 구축합니다. MariaDB 상태 및 성능을 실시간으로 모니터링하고, 장애 발생 시 알림을 통해 빠르게 대응할 수 있습니다.

결론

K8s 환경에서 MariaDB 마스터 서버가 쓰기 작업 중 중단되는 문제를 해결하려면 트랜잭션 안전성, 스토리지 성능 최적화, 고가용성(HA) 구축, 백업 및 복구 전략을 수립하는 것이 필수!!!

이를 통해 MariaDB의 데이터 무결성과 서비스 가용성을 유지하고, 장애 발생 시 신속하게 대응가능!!

기타참조 : https://docs.3rdeyesys.com/docs/database/mysql-mariadb/replication/mariadb-multi-source-replication/ 

MariaDB Multi Source Replication 구성 가이드