LOCAL 에서 MARIADB STATEFUL 컨테이너 실행하기 * Local에서 데이터베이스를 Container로 실행하는 경우가 자주 발생한다. * DataBase 는 pod가 재실행 되더라도 항상 고정된 볼륨으로 데이터를 저장하고 있어야한다. 이때 주로 사용하는 것이 StatefulSet 이다. * 우리는 여기서 StatefulSet을 생성하고, MariaDB를 로컬 환경에서 실행해 볼 것이다. NAMESPACE 생성하기 * 우리는 storage라는 namespace를 생성하고, mariadb를 실행할 것이다. * namespace definition 은 다음과 같다. apiVersion: v1 kind: Namespace metadata: name: storage STORAGECLASS 생성하기 * 저장해야할 스토리지 클래스를 생성한다. * 스토리지 클래스의 목적은 동적으로 스토리지를 프로비져닝 하기 위해 사용되는 kubernetes resource 객체이다. * 일반적으로 시스템 운영자가 Storage Class를 생성하면, 이후 개발자가 pod를 생성할때 PersisentVolumeClaim 을 통해서 볼륨을 필요에 따라 생성할 수 있게 된다. apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: my-storage namespace: storage provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer * apiVersion: api는 storage.k8s.io/v1 이다. * kind: 리소스 종류는 StorageClass라는 것을 알 수 있다. * provisioner: 프로비져너는 리소스를 생성한는 주체를 이야기한다. 여기서는 로컬을 이용할 것이므로 프로비저너는 no-provisioner 로 지정했다. * kubernetes.io/gce-pd: GCEPersistentDisk 플러그인을 이용하여 볼륨 생성 * kubernetes.io/aws-ebs: AWS ElasticBlockStorage를 이용하여 볼륨 생성 * kubernetes.io/azure-disk: Azure File을 이용하여 볼륨 생성 * kubernetes.io/azure-disk: Azure Disk를 이용 * volumeBindingMode: 볼륨 바인딩 모드는 WaitForFirstConsumer로 처음 pod 생성시 볼륨을 바인딩 하게 된다. 모드는 아래와 같다. * Immediate Mode: 이 모드는 PVC가 생성되면 StorageClass가 있는 PVC에 대한 PV의 자동 볼륨 바인딩이 포함된다. * WaitForFirstConsumer Mode: 이 모드는 사용할 Pod가 생성될 때까지 PV바인딩 및 동적 프로비저닝을 지연한다. PERSISTENTVOLUME CLAIM 생성하기 * Persistent Volume Claim은 볼륨을 pod에서 요청할때 볼륨을 요청한 만큼 할당해 주는

RDS for MariaDB는 클라우드 환경에서 손쉽게 MariaDB를 사용할 수 있게 해 줍니다. 손쉽게 설정을 변경할 수 있고 자동화된 백업으로 장애 발생 시, 언제든 원하는 시간으로 복구할 수 있습니다. 또한 장애 발생 시, 순단 시간을 최소화하고 서비스를 계속하기 위해 별도의 Standby 서버를 준비할 수 있습니다. # 주요 기능 ## 고가용성 지원 고가용성 인스턴스는 장애를 극복하기 위해 Active로 동작하는 Master 인스턴스뿐만 아니라, Standby로 동작하는 Candidate Master를 별도로 제공합니다. Master 인스턴스와 Candidate Master 인스턴스는 서로 다른 가용성 영역에 생성됩니다. Master 인스턴스의 장애가 감지되면 Master 인스턴스는 정지되며, Candidate Master 인스턴스가 새로운 Master로 동작합니다. 이러한 장애 조치가 발생하면 구 Master 인스턴스를 바라보던 도메인의 CNAME이 Candidate Master 인스턴스를 바라보도록 변경됩니다. 따라서 장애 조치 이후 별도의 응용 프로그램의 Database 접속 주소를 변경할 필요가 없습니다.  ## 자동화된 백업 최대 30일 동안 지정된 시간 범위 안에 자동으로 백업이 수행됩니다. 백업 파일은 별도의 오브젝트 스토리지에 안전하게 보관됩니다. 보관된 백업 파일을 통해 언제든 원하는 시점으로 복원할 수 있습니다. ## 손쉬운 설정 변경 웹 콘솔을 통해 손쉽게 설정을 변경할 수 있습니다. 웹 콘솔에서 변경 즉시, Database에 적용되며 필요에 따라 자동으로 재시작됩니다. ## 모니터링 별도의 설정 없이 DB 인스턴스의 하드웨어 및 Database 상태를 모니터링할 수 있습니다. 이상 징후에 대해 알림을 설정하여 빠르게 대응할 수 있습니다.  # RDS for MariaDB 서비스 활용 예 NHN Cloud의 Compute & Network 서비스를 이용한 응용 프로그램에서 Database를 사용해야 할 경우, RDS를 사용하면 안전한 환경에서 높은 성능의 Database를 손쉽게 사용할 수 있습니다. Compute & Network 서비스의 인스턴스와 동일한 VPC Subnet에 RDS가 생성되므로, 외부의 Database를 사용하는 것과 비교하여 더 낮은 네트워크 지연을 기대할 수 있습니다. 또한 별도의 Floating IP를 연결하지 않는다는 가정하에 외부 접근이 차단되므로 중요한 데이터를 외부로부터 고립시킬 수 있습니다. ![RDS for MariaDB_4.png](https://image.toast.com/aaaadh/real/2022/t

2021-12-17 임호현 MariaDB는 전세계에서 많이 사용하는 오픈소스 RDBMS 중 하나이다. 2010년 1월, 5.1버전을 시작으로 꾸준한 업그레이드를 거쳐 2021년 12월 현재 안정화 버전으로 10.6이, Alpha(미리보기) 버전으로 10.7이 배포되고 있다. 개발은 MariaDB 재단이 맡고 있으며 약 1년 주기로 신규 버전을 발표한다. 제품 개발은 Alpha Beta RC(Release Candidate, 릴리즈 후보) 단계를 거쳐 정식 버전이 출시된다. 버전별로 EoL(End of Life)이 정해져 있으며 모든 릴리스가 최소 5년 동안 유지되도록 보장한다. EoL 이후에는 버그나 보안 패치가 제공되지 않는다. [표 1] MariaDB 버전별 EoL Version Released Support Status Release 10.6 2021/07/06 2026/07/06 10.6.5 10.5 2020/06/24 2025/06/24 10.5.13 10.4 2019/06/18 2024/06/18 10.4.22 10.3 2018/05/25 2023/05/25 10.3.32 10.2 2017/05/23 2022/05/23 10.2.41 10.1 2015/10/17 2020/10/17 10.1.48 10.0 2014/03/31 2019/03/31 10.0.38 [표 1] MariaDB 버전별 EoL MariaDB 10.6 버전은 비정상 종료시 안전한 Atomic DDL, OARCLE 호환성에 중점을 둔 구문과 데이터 처리에 사용하는 SQL 구문 그리고 데이터베이스 사용에 도움이 되는 Sys Schema까지 활용도가 높은 기능이 대거 추가되었다. 본 아티클에서는 10.6 버전의 주요한 개선 및 추가·삭제 사항을 살펴보고자 한다. 개선/변경 사항 1. Atomic DDL DDL(Data Definition Language) 작업 중 서버가 비정상 종료될 경우 이전 버전에서는 작업에 대한 안전 보장이 없었다. 10.6 버전부터는 CREATE TABLE, ALTER TABLE, RENAME TABLE, DROP TABLE, DROP DATABASE 및 관련 DDL 문은 비정상 종료에 안전하도록 개선되었다. MariaDB의 Atomic DDL은 비정상 종료하면 DDL문이 완전히 실행되거나 전혀 수행되지 않는다. 이는 비정상 종료가 발생하여 서버를 다시 시작하더라도 모든 테이블이 일관되고 바이너리 로그가 서버의 상태와 일치함을 뜻한다. 또한 Atomic DDL은 데이터베이스 계층에서 구현되어 MariaDB의 다양한 스토리지 엔진과 함께 작동 가능하다. 추후에는 S3 storage engine, partitioning engine도 지원할 예정이다. 2. INNODB row_format=COMPRESSED 형식의 테이블은 기본적으로 읽기 전용으로만 사용이 가능하다. 향후 쓰기 지원을 제거하고 더 이상 사용하지 않을 예정이다. 하지만 변수 innodb_read_only_compressed=OFF를 사용하면 쓰기가 가능하다. InnoDB 임

블로그 목적• None MariaDB 로그 관련 바이너리로그(binary log)관리에 대해서 공부및 정리후 나만의 노하우와 지식을 공유한다.​블로그 요약• None MariaDB bin log 의 주기를 확인하는 방법에 대해서 알아본다.• None MariaDB bin log 의 주기를 세팅하는 방법에 대해서 알아본다.• None MariaDB bin log를 삭제하는 방법에 대해서 알아본다.블로그 상세 내용우선, 바이너리로그에 대해서 간단히 알아보면 아래와 같습니다.• None MariaDB 의 바이너리로그의 내용및 활용은 아래와 같습니다.• None MariaDB는 바이너리로그라는 파일에 DB 에서 발생한 변경내역을 저장한다.• None 해당 로그의 역할및 활용에는 여러가지가 존재하지만 가장 중요한 부분은 바로 복제/복구의 활용이다.• None 아무튼, 해당 블로그를 작성한 이유는 제가 담당하던 서비스가 MariaDB를 사용하는데요.• None 금일 해당 MariaDB 서버에서 디스크가 모자란다는 알람이 와서 확인해보니, 해당 바이너리 로그가 관리없이 많이 쌓여있음을 확인할 수 있었습니다.• None 그래서 해당 블로그에서 말하고 싶은 내용은 해당 바이너리 로그(bin log) 를 어떻게 관리및 삭제하는지에 대한 부분을 말씀드리려고 합니다.​먼저, MariaDB bin log 의 주기를 확인하는 방법에 대해서 알아보겠습니다.• None 아래와 같이 해당 MariaDB 이 설치된 디렉토리를 확인해보니 bin log 가 많이 쌓여있음을 확인할 수 있었습니다.• 아무튼, 우선 root 계정으로 접속해서 bin 로그를 확인해보겠습니다.• None 그럼, 해당 bin 로그의 삭제주기를 확인해보겠습니다.• bin 로그의 삭제주기는 MariaDB 의 환경설정중 expire_logs_days 를 확인하면 됩니다.• 확인결과 현재는 기본값인 0 으로 세팅되어 있는것을 확인할 수 있었습니다.• 참고로 0의 의미는 "bin log 를 삭제하지 않는다" 입니다.• 결과적으로 expire_logs_days 가 세팅되어 있지 않아서 bin log 가 쌓이고 있었던거죠..• 그 리고, 환경설정을 잠시 보자면, 아래 파일을 확인하면 됩니다.• /etc/my.cnf• None 아래와 같이 설정을 하면 grep 으로 확인할 수 있습니다.• 물론, 해당 환경설정파일에 저장을 하면, MariaDB 를 재기동 할때 적용이 됩니다.다음으로 MariaDB bin log 의 주기를 세팅하는 방법에 대해서 알아 보겠습니다.• 위와 같이 환경설정파일에서 환경변수를 입력시키면, 실시간적용이 안되기때문에 실시간으로 적용하는 방법을 말씀드리겠습니다.• 아래와 같이 세팅하시면 됩니다.• 그럼, 정상적으로 세팅되었는지 확인해볼까요?• show variables like 명령을 사용하면 됩니다.• 위와 같이 정상적으로 7일로 세팅되었음을 확인할 수 있습니다.마 지막으로 MariaDB bin log 를 삭제하는 방법에 대해서 알아보겠습니다.• MariaDB bin log 를 삭제하려면,•