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

오늘은 Oracle Session Kill에대해 글을 써보도록하겠습니다. Database를 운영하다보면 특정 Session 을 Kill해야 하는일이 생기게된다. 자주 발생하는 예로는 Lock이 발생하였을때 Lock 을 유발시킨 Session을 Kill하게 됩니다. Session 확인 USERNAME이 LEE인 USER의 SID,SERIAL#을 확인하였다. SQL> select username,sid,serial#,status from v$session where username='LEE'; USERNAME SID SERIAL# STATUS ------------------------------ ---------- ---------- -------- LEE 191 5 INACTIVE Session KILL..

오늘은 MariaDB에서 MSSQL로의 DBLINK에 관하여 글을 쓸 예정이다. 최근 고객사에서 MariaDB에서 MSSQL로 DBLINK를 맺어달라 문의를 받아서 해보게 되었다. MariaDB의 Connect Engine을 이용해서 DBLINK을 맺을 예정이다. 0. Connect Engine? - Connect Storage Engine은 MariaDB 10.2 부터 반영되었다. - MariaDB에서 외부 로컬 또는 원격 데이터를 액세스할 수 있게 해주는 Storage Engine이다. - ODBC,JDBC를 통해 다른 DBMS 또는 제품(Excel)에서 추출한 데이터를 액세스 할 수 있다. - Connect Stroage Engine은 테이블 파티셔닝, MariaDB 가상 칼럼을 지원하며 ROWID..

■ 갈레라 클러스터 장점 - 진정한 다중 마스터 : 아무 때나 어떤 노드에서도 읽기와 쓰기가 가능하다. - 동기적 복제 : 슬레이브 지연이 없고 노드 충돌 시에 데이터 손실이 없다. - 일관적인 데이터 : 모든 노드는 같은 상태를 유지한다. - 멀티스레드 슬레이브 : 어떠한 워크로드에서도 더 나은 성능을 가능케한다. - 상시 대기 : 장애 극복 시 downtime이 없다. - 읽기와 쓰기 스필릿이 필요 없다 : 읽기와 쓰기 요청을 스플릿할 필요가 없다. - 자동 노드 복제 : 노드를 추가하거나 유지 관리를 위해 종료 할 때 증분 데이터 또는 기본 데이터를 수동 백업할 필요 없시 Galera Cluster는 자동으로 온라인 노드 데이터를 가져온다. ■ 갈레라 클러스터 단점 - 동기적 복제이다 보니 클러스터..

이번에 MariaDB Galera를 사용하고 있는 고객사에서 Memory 관련 문의가 들어오게 되면서 Memory부분을 공부해보게 되었다. ■ MariaDB Memory 종류 - MariaDB Memory는 두가지로 분류가된다. 모든 세션이 공유하고 사용하는 Global Memory 영역과 각각의 세션들별로 사용되는 Session Memory영역이 있다. ■ Global Memory 영역 DB가 최초 기동되었을 때에는 메모리를 최소한만 사용하다가 설정된 값 까지 증가하며 증가한 이후에는 "메모리를 반환하지 않고" 설정 된 값 이내에서 계속 사용됩니다. (오라클의 경우 DB기동시 설정된 값 만큼 메모리를 할당 받고 올라가는 반면 Mariadb 는 기동시 설정된 메모리 값만큼 할당 받는것이 아닌 설정된 값 ..

고객사에서 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..

0.사전준비 sysstat 설치 yum -y install sysstat 1.대량의 Insert 준비 - 많은량의 CPU를 사용하게 하기 위해 Insert Procedure를 실행시킨다. ##Table 생성 MariaDB [test]> use test; MariaDB [test]> drop table if exists tes0t_bak; MariaDB [test]> create table test_bak (a int primary key,name varchar(10),test varchar(100),Address varchar(500)); ## Procedure 생성 MariaDB [test]> drop procedure if exists PInsert; DELIMITER $$ CREATE PROCEDU..

얼마 전에 고객사에 ORA-00257 에러가 발생하였다. 해당 고객사는 Crontab으로 7일 이후의 Archive Log는 삭제하는 스크립트를 걸어놨음에도 250G의 +RECO DIskgroup이 Full이 차는 일이 발생하였다. 우서 장애처리를 위해서 Archive log를 5일 치 남기고 삭제하여 해결하기는 하였으니 이후 왜 Archive log가 Full이 찾는지 원인을 찾기 시작하였다. ■ 장애 발생 - RECO DISKGROUP 의 Free_MB가 236이다. - RECO DISKGROUP에서 ARCHIVE LOG가 249G를 차지하고 있다. State Type Rebal Sector Logical_Sector Block AU Total_MB Free_MB Req_mir_free_MB Usab..

기존 MariaDB를 Replication을 걸어두고 윗단에 Maxscale을 두어서 Auto Failover / VIP 접근 / READ & WRITE 분산을 테스트 해보았다. 아직까지 Replication에서 쓰고있는 고객들은 보지 못하였지만 나중을 위해 테스트해본 것을 기록하였다. 0.TEST 환경 Master 172.40.40.189 Slave 172.40.40.188 Maxscale 172.40.40.187 1.MAXSCALE 설치 ** 1.필요 library 설치 ** [root@maxscale ~]# yum -y install libcurl libaio openssl gnutls libatomic ** 2.Maxscale 유저 그룹 생성 ** [root@maxscale ~]# groupadd..

테이블의 데이터를 읽는 방식으로는 크게 Full Table Scan, Index Range Scan으로 나뉜다. 일반적으로 Full Table Scan은 느리다고 생각되어 쓰지 않으려고 하는 경향이 있다. 하지만 DW 용도로 Database를 사용하는 경우 Full Table Scan이 필수적으로 사용되는 경우가 있다고 한다. 그래서 이번에는 Full Table Scan에 대해 공부해보려고한다. FULL TABLE SCAN (FTS) 1) FTS이 발생하는 경우 상황 설명 적용 가능한 인덱스가 없는 경우 적용할 인덱스가 있지만 칼럼 가공, 연산으로 인해 인덱스 사용이 불가능할때 넓은 범위의 데이터 액세스 인덱스 처리 범위가 넓어 전체 테이블 스캔이 더 적은 비용이 들경우 Tull Table Scan을 적..