■ 기본 메커니즘 - 아래 사원과 고객 테이블이있다. 이 두 테이블에서 1996년 1월 1일 이후 입사한 사원이 관리하는 고객 테이터를 추출하는 프로그램을 작성해보자 - 일반적으로 NL조인은 Outer(선행)와 Inner(후행) 양쪽 테이블 모두 인덱스를 이용한다. Outer 테이블은 사이즈가 크지 않으면 인덱스를 사용하지않고 Table Full Scan을 하기도한다. Table Full Scan을 하더라도 한번에 그치기 때문이다. 반면 Inner 쪽 테이블은 인덱스를 사용해야 한다. Inner 루프에서는 관리사원번호 INDEX를 읽어야한다. 그렇지 않을시 Outer루프에서 읽은 건수만큼의 Table Full Scan을 반복하게된다. 1. 사원_X1 인덱스에서 입사일자 >= '19960101' 인 첫번째..

고객사에서 PostgreSQL를 이중화를 원하고 있었다. PostgreSQL 이중화에서 고려해봤던 것들은 Streaming replication + pacemaker를 이용해서 Auto Failover + VIP 이동을 해보려 했으나, 구축 후 장애 포인트가 많아질 것 같아 포기하였다. 다음으로 고려했던 Repmgr를 이용해서 이중화와 VIP 이동을 할 수 있도록 구축하기로 하였다. 이번 글은 Repmgr를 이용한 이중화 & Auto Failover & VIP 이동에 관하여 포스팅할 것이다. ■ 테스트 환경 Master : 10.70.101.69 ( lee-pg001 ) Standby : 10.70.101.70 ( lee-pg002 ) Vip : 10.70.101.68 ■ PostgreSQL 설치 ( A..

언제 한번 이중화로 구성된 고객사에 Lock이 심하게걸리고 문제가 생긴적이있다. 해당 Lock을 해결하고나서 Slave에 상태를 보니 Lock이후부터 따라가지 못하고있는것을 확인하였다. 여러가지 확인을 해보다 Master DB쪽의 binary log의 사이즈가 비정상적으로 컸던적이있다. 나의 예상으론 Binary log에 큰 트랜잭션들이 들어갔고 이 값을 max_allowed_packet 보다 커서 보내지 못한걸로 생각하였다. 나의 경우에는 Mariabackup을 이용해서 Replication을 재설정하였다. 이번에는 문제가 발생했던 영역인 Max_binlog_size 를 작게하였음에도 Binary log 사이즈가 커지는 것을 테스트해볼 생각이다. ■ max_binlog_size 확인 MariaDB [(..

MariaDB와 MySQL은 사용자의 액세스를 기록해야하는 경우 이전에는 데이터베이스 솔루션을 사용해야 했다. 그러나 현재는 Audit log 플러그인을 이용해서 액세스 기록을 할 수 있게되었다. 기본적으로 MariaDB Audit 플러그인의 목적은 서버의 활동을 기록하는 것으로, 각 클라이언트 세션에 대해 누가 서버에 접속했는지 ( 사용자 / 호스트 ) 쿼리 내용, 엑세스한 테이블을 기록하는 것이다. MariaDB 감사 플러그인은 MariaDB, MySQL(버전 5.5.34 및 10.0.7 현재) 및 Percona Server에서 작동합니다. MariaDB는 기본적으로 버전 10.0.10 및 5.5.37의 감사 플러그인을 포함하기 시작했으며 MariaDB 5.5.20의 모든 버전에 설치할 수 있습니다 ..

Graylog를 설치했다면 원격지 서버에서 Syslog를 수집하기 위해 Graylog를 설정한다. ■ Graylog Input 생성 - Graylog에서 Input을 생성하기 위해서는, 원격지 시스템에서 로그가 생성되고, Graylog로 송신을 해야 한다. - Graylog에서는 해당 송신되는 log를 받아 처리할 수 있는 수신 포트를 설정하여야 하며 보통 syslog 수신을 위한 포트는 UDP 514가 Deault이나 Graylog 서버에서 1024 이하의 TCP/UDP 포트 번호는 권한 오류가 발생하게 된다. - 이러한 이슈를 해결하기 위해 UDP 514 -> 1514 포트로 redirection 되도록 처리한다. 1) System -> Input -> Syslog UDP -> Launch new i..

Log 모니터링을 하다보면 5개 정도의 서버의 Log를 보는 거라면 빠르게 볼수있다. 하지만 10대이상가는 서버의 Log를 매일 모니터링을 하다보면 이 시간또한 많은 시간을 들게된다. 현재 맡고있는 서비스는 40대가 넘는 서버의 일일 Log 모니터링을 하고있는데 이런 시간을 줄이기 위해 Graylog를 공부해보고 적용까지 해보려고한다. ■ Graylog - Graylog는 로그메세지의 적재와 조회, 시각화등의 기능외 많은 기능을 제공하는 오픈 소스 로그 관제 솔루션이다. - Graylog Server / Elasticsearch / MongoDB로 구성된다. 이를 통해 애플리케이션으로 부터 전송되는 로그를 거의 실시간으로 구조화하여 적재 할 수 있다. ■ 구조화된 로그가 필요한 이유 - 왜 구조화된 로그..

실제 개발자들이 인덱스를 생성하다보면 이후에 중복된 인덱스들이 존재할 수도 있다고 한다. 이번에는 인덱스중에서 중복되는 역할을하는 인덱스를 찾아 제거하는 방법에 대해 공부해보았다. ■ 중복 인덱스 찾기 세 인덱스는 중복이다. X02 는 선두컬럼이 X01 인덱스 전체를 완전히 포함하고, X03 인덱스 선두 컬럼이 X01과 X02 인덱스 전체를 완전히 포함하기 때문이다. 필자는 이를 '완전 중복'이라고 부른다. X03 인덱스를 남기고, X01, X02 인덱스는 삭제해도 된다. 1) X01 : 계약ID + 청약일자 2) X02 : 계약ID + 청약일자 + 보험개시일자 3) X03 : 계약ID + 청약일자 + 보험개시일자 + 보험종료일자 ■ 중복제거 실습 • PK : 주소ID + 건물동번호 + 건물호번호 + 관..

오늘은 MariaDB Version을 Upgrade 하는 것에 대해 포스팅할 예정이다. https://mariadb.com/kb/en/upgrading-from-mariadb-101-to-mariadb-102/ Upgrading from MariaDB 10.1 to MariaDB 10.2 How to upgrade from MariaDB 10.1 to MariaDB 10.2. mariadb.com 기존 DB Version : 10.1.45-MariaDB 업그레이드 DB Version : 10.2.12-MariaDB ■현재 DB 상태 - Sakila Database를 넣어 두었다. MariaDB [(none)]> show databases; +--------------------+ | Database | ..