시냅스

이 글에서는 Cent OS 를 기준으로 MariaDB 설치부터 Galera Cluster 구성까지 살펴봅니다. 실제로 운영하며 겪었던 TroubleShooting 및 중요사항에 대해 설명합니다. MariaDB 설치 /etc/yum.repos.d/MariaDB.repo 를 등록합니다. MariaDB 공식 repo 링크 위 링크에서 현재 환경에 맞는 OS, MariaDB Version 을 선택합니다. yum install MariaDB 명령어로 MariaDB 를 설치합니다. mariadb --version 명령어로 설치를 확인합니다. systemctl start mariadb 로 실행 후 mysql -uroot -p 로 접속합니다. 이 때 root 는 아직 password 가 설정되지 않은 상태이므로 pas..

이 글에서는 MySQL 의 Galera cluster 의 상태 전송에 대한 이해와 그 방법에 대해서 알아봅니다. https://liltdevs.tistory.com/201 GTID 와 Galera Cluster GTID 글로벌 트랜잭션 식별자, Global Transaction ID 는 서버에서 커밋된 각 트랜잭션에 대한 식별을 가능하게 합니다. 서버 내에서만 유일한 것이 아니라 모든 복제 서버에서도 식별을 가능하게 합니 liltdevs.tistory.com Galera Cluster 는 Multi Master 의 운영을 쉽게 도와주는 도구입니다. 각각의 노드에서 Read-Write 가 가능하고, 논리적인 동기 방식을 지원하므로 선형성을 갖출 수 있습니다. 다만 운영하며 상태 이전에 대한 이해는 필요할 ..

Galera Cluster https://liltdevs.tistory.com/201 GTID 와 Galera Cluster GTID 글로벌 트랜잭션 식별자, Global Transaction ID 는 서버에서 커밋된 각 트랜잭션에 대한 식별을 가능하게 합니다. 서버 내에서만 유일한 것이 아니라 모든 복제 서버에서도 식별을 가능하게 합니 liltdevs.tistory.com 현재 회사에서는 고가용성을 목적으로 Galera Cluster 를 사용하고 있습니다. Galera Cluster 는 bootstrap(galera_new_cluster 로 실행시킨 node) 이 galera cluster 형성에 중요한 역할을 합니다. 아래에서는 그 설명과 관련 파일에 대해 알아보겠습니다. Boostrap Bootst..

GTID 글로벌 트랜잭션 식별자, Global Transaction ID 는 서버에서 커밋된 각 트랜잭션에 대한 식별을 가능하게 합니다. 서버 내에서만 유일한 것이 아니라 모든 복제 서버에서도 식별을 가능하게 합니다. 따라서, 복제 토폴로지 내에서 모든 트랜잭션을 고유하게 식별할 수 있게 합니다. GTID 를 통해 slave 는 master 에 연결된 후 데이터를 어디에서부터 동기시켜야 하는지 판별하고, MySQL 서버가 죽었다가 다시 올라와 데이터가 중단된 시점을 판단하여 데이터 불일치를 해결할 때에도 사용됩니다. Galera Cluter Galera Cluster 는 Sync / Multi Master 를 지원합니다. 단, 실제로는 네트워크 문제(복제 시 네트워크 지연으로 인한 장시간 blocking..

이 글에서는 Full-Text Index + Search 에 대한 설명과 프로젝트에서 사용하게된 이유, Full-Text Search 를 JPA 에서 사용하는 방법을 설명합니다. 현재 진행하고 있는 프로젝트는 공연에 대한 예매시스템을 구축하고 있습니다. 사용자들은 공연에 대한 정보를 확인하거나 예매할 때 검색을 사용하기에 기능을 구현할 필요가 있었습니다. 여기에 고민한 것은 Elasticsearch 와 MySQL 의 Full-Text Search 였습니다. Elasticsearch 는 검색에 대한 분명한 장점이 있습니다. 자체적으로 분산 아키텍처를 구축하고 데이터를 샤딩하여 저장하고 역 인덱스를 통한 빠른 데이터 참조를 가능하게 합니다. 다만 구축하려는 검색기능은 높은 가용성이나 정확성을 요구하지 않고 ..

이 글에서는 No Offset 방식이 왜 빠른지 이해하기 위한 개념과 예시를 상술합니다. LIMIT MySQL 에서 LIMIT 은 범위를 제한할 때 사용합니다. 쿼리 결과에서 지정된 순서에 위치한 레코드만 가져오고 싶을 때에 유용하게 사용됩니다. SELECT * FROM test_tb LIMIT 0, 10; 위와 같은 쿼리에서 만약 LIMIT 이 없었다면 테이블 풀 스캔을 실행하여 결과값을 반환했을 것입니다. 하지만 이 때 LIMIT 을 사용하면서 MySQL 엔진은 레코드를 10건만 읽은 직후 반환하게 됩니다. 따라서 모든 레코드를 읽어야하는 것 보다 훨씬 부하가 줄게 됩니다. -- 1 SELECT * FROM test_tb GROUP BY first_name LIMIT 0, 10; -- 2 SELECT..

이 글에서는 커버링 인덱스와 pk 를 활용한 복합 인덱스에 대해 간단한 예시를 통해 설명합니다. 커버링 인덱스 Covering Index는 특정 쿼리의 모든 필요한 데이터를 인덱스에서 직접 얻을 수 있게 하는 인덱스입니다. 이는 테이블 자체에 접근할 필요 없이 인덱스에서 쿼리의 모든 필요한 데이터를 찾을 수 있게 합니다. 커버링 인덱스는 인덱스에서 충족하는 데이터를 갖고 있어 디스크 I/O 를 줄이고, 테이블 락을 줄임으로써 데이터베이스의 전반적인 부하를 감소시켜 성능을 향상시킵니다. 예제1 - 단순 select 테이블은 위와 같은 모습으로 준비했습니다. id 는 pk, auto increment 로 하나씩 올라갑니다. 또한 테이블에는 미리 1,000 만 개의 데이터를 넣어 두었습니다. 커버링 인덱스는 ..

단편화, Fragmentation 단편화, fragmentation 는 기억 장치의 빈 공간 또는 자료가 여러 개의 조각으로 나뉘는 현상을 말한다. 이 현상은 기억장치의 사용 가능한 공간을 줄이거나, 읽기와 쓰기의 수행속도를 늦추는 문제점을 야기한다. https://ko.wikipedia.org/wiki/%EB%8B%A8%ED%8E%B8%ED%99%94 MySQL InnoDB 에서는 PK 혹은 Clustering Index 를 통해 각 레코드를 관리하고 있습니다. Secondary Index와 Clustering Index 는 B+Tree 의 구조를 가지며, Clustering Index는 리프노드에 직접 레코드를 가지고 있고 Secondary Index 는 Clustering Index 의 주소를 갖고..

이 글에서는 MySQL의 Repeatable Read 격리 수준에서 트랜잭션 동작 방식과 트랜잭션 락킹에 대해 설명합니다. 이해를 돕기 위해 간단한 예시를 사용하며 설명합니다. Repeatable Read Repeatable Read 는 InnoDB 기본 격리 수준입니다. 트랜잭션 내에 읽기에 대한 일관성을 스냅샷을 기준으로 보장하며 InnoDB 에서는 Next Key Lock 을 사용하며 Phantom Read 까지 예방합니다. 스냅샷을 기준으로 일관성을 보장한다는 것은, 현재 실행하고 있는 트랜잭션 id 보다 전의 id 를 갖는 언두 로그를 참조한다는 뜻입니다.. 따라서 SELECT 시에 다른 트랜잭션에서 업데이트하며 해당 데이터가 바뀌더라도 현재의 트랜잭션에서는 일관성을 유지합니다. 위와 같은 상황..

InnoDB Locking MySQL 의 InnoDB 에서 사용하는 Locking 기법 Shared Lock, S-Lock 특정 레코드를 읽을 때 사용되는 Lock Shared Lock 끼리는 동시 접근이 가능하다. 하나의 레코드를 여러 트랜잭션이 동시에 읽을 수 있다. 어떤 자원에 Shared Lock 이 하나라도 걸려있으면 Exclusive Lock을 걸 수 없다. 동시에 읽기는 가능하지만, 변경은 불가능하게 한다. e.g. SELECT ... FOR SHARE Exclusive Lock, X-Lock 변경(write) 작업을 할 때 사용되는 lock 이다. Exclusive Lock 이 걸린 레코드에는 다른 트랜잭션에서 변경이나 삭제가 불가능하다. 특정 레코드에 Exclusive Lock 이 걸려있..