제익

MaxScale이란?MaxScale은 MariaDB에서 제공하는 고성능 데이터베이스 프록시 서버로드 밸런싱, 고가용성(HA), 보안, 쿼리 라우팅 등을 지원MySQL과 MariaDB 데이터베이스 환경에서 유연한 트래픽 관리가 가능클라이언트와 데이터베이스 서버 사이에서 다양한 기능을 수행1. MaxScale의 구성 목적데이터베이스 부하 분산(Load Balancing)장애 발생 시 자동 장애 조치(Failover) 및 복구 지원쿼리 필터링 및 보안 기능 강화읽기/쓰기 분리(Read/Write Splitting)데이터베이스 연결 관리 및 최적화2. MaxScale의 장점로드 밸런싱 – 여러 MariaDB/MySQL 간에 쿼리를 분산 처리하여 성능 최적화자동 장애 조치(Failover) – 특정 노드 장애 시..

이전 글에서 binary log를 이용한 MariaDB 이중화 방법과, GTID에 대한 개념을 정리했다.1. [MariaDB (2/5)] MariaDB 이중화 테스트(Master - Slave)2. [MariaDB (3/5)] MariaDB 이중화 테스트(Master - Master) 3. [MariaDB (4/5)] MariaDB 이중화 테스트(GTID 1. 개념 정리) 그럼 이제 GTID를 이용해 마리아DB 이중화를 실제로 진행해보자.이중화 프로세스 요약(사전 작업) binary log 설정Master 서버의 GTID 값 확인Master 서버의 GTID 값을 Slave에서도 사용하도록 적용GTID(Global Transaction ID)replication에 참여한 서버 간 unique ID 값A-B..

이전 블로그에서 binary log를 이용한 MariaDB 이중화 방법을 알아보았다.1. [MariaDB (2/5)] MariaDB 이중화 테스트(Master - Slave)2. [MariaDB (3/5)] MariaDB 이중화 테스트(Master - Master) 위 방법들은 전통적인 Binary Log 기반 이중화 방법으로, 여러 단점이 있다. 1️⃣ Failover(장애 복구)가 복잡함마스터 장애 발생 시, 슬레이브를 새로운 마스터로 승격하려면 Binary Log 파일과 Position을 직접 설정해야 함.실수하면 데이터 불일치 발생 가능.2️⃣ 슬레이브 추가 시 Position 지정 필요SHOW MASTER STATUS;로 확인한 Binary Log 파일과 Position을 슬레이브에 직접 입력해..

이전 글에서는 Maria DB를 Master-Slave 방식으로 이중화하는 방법을 정리했다.링크 : [MariaDB (2/5] MariaDB 이중화 테스트(Master - Slave) Master - Slave 이중화의 경우 Master의 데이터 변경 내역이 Slave에 반영되긴 하나Slave에서의 데이터 변경은 Master에 반영되지 않는다...는 결함이 있다. 이를 극복하기 위해 Master - Master 방식의 이중화 구축 방법도 정리한다.요약1. 각각의 서버에 binary log 파일 형식 및 서버 설정2. 각각의 서버에 서로 접속할 계정 생성 및 권한 부여3. 각각의 서버를 서로의 Slave로 등록 1. 이중화 시킬 2대의 Maria DB 구축 2. 서버 설정    2-1.  Master 서버..

이중화 프로세스Master 서버가 데이터 변경에 대한 event 발생 내역을 binary log에 기록Master 서버가 binary log를 Slave에게 전달Slave는 이 binary log 를 읽어 본인 DB에 반영binary log 란?mysql(mariadb)에서 발생하는 모든 내역들이 기록되는 파일default는 비활성화 상태이기 때문에, 이중화를 하기 위해 이를 활성화시키는 작업이 선행되어야 함 Master - Slave로 이중화 구축하기 위해선 각각의 서버 설정을 따로 수행필요 1. 이중화 시킬 2대의 Maria DB 구축- maria1를 Master로, maria2를 Slave로 구축할 예정 2. Master 서버 설정    2-1. Master 서버 접속      2-2. vi 편집기..

Maria DB 이중화 (replication)Maria DB의 데이터를 또 다른 Maria DB에 복제시켜 동일한 데이터를 관리하는 방식이미지 출처 : https://mariadb.com/kb/en/replication-overview/Maria DB 이중화의 목적고 가용성 확보 : Master DB 장애 발생 시 Slave를 Master로 승격시켜 서비스의 중단 없이 운영이 가능읽기 성능 향상 : 읽기(SELECT)를 Slave가, 쓰기(UPDATE, DELETE, INSERT)를 Master가 수행하도록 기능을 분리시켜 성능 향상이 가능데이터 백업 및 안전성 확보 : Master DB가 망가져도 Slave를 통해 데이터의 백업이 가능데이터 분석 및 테스트 환경의 분리 : 운영중인 Master DB ..