시콩식의 IT일지

현재 운영중인 서버는 멀쩡하나, 클라이언트가 튕기거나 기능이 온전하게 작동하지 않는 이슈가 있다.모니터링을 해보니, mysqld 프로세스의 cpu 점유율이 100%에 달하였으며, 해당 상태가 10~40분 정도 지속되는 현상이 확인되었다. 다행히도 서비스는 죽지 않고 일정 시간이 지난 후 자연 해소되었으며,구글링과 gpt의 도움을 받아 원인을 분석해보니 지속,반복적으로 실행되는 slow 쿼리(aes_decrypt 함수 포함) 등으로 인하여 cpu 사용량이 급증하는 것으로 파악하였다. 아래는 해당 slow 쿼리에 대한 분석 및 대응 방향이다.🔎 slow 쿼리 분석1. 주요 특징대량의 데이터를 조회하는 복잡한 SELECT 쿼리AES_DECRYPT, FROM_BASE64 연산이 다수 포함되어 있어 CPU 부하..

Connection Timeout 오류 분석로그에서 나타난 java.sql.SQLTransientConnectionException: hikari-rw-chat - Connection is not available, request timed out after 30000ms 오류는 HikariCP에서 제공하는 데이터베이스 연결 풀의 연결 요청이 30초 동안 대기한 후에도 연결을 확보하지 못해 발생하는 연결 시간 초과 문제입니다. 주요 오류 내용해당 오류는 SQL 쿼리가 실행되기 전 데이터베이스 연결 풀에서 유효한 연결을 제공하지 못한 상황을 나타냅니다. 일반적으로 이는 데이터베이스 부하가 크거나, 연결 풀의 설정이 충분하지 않아서 발생합니다. 해결 방안HikariCP 설정 최적화:HikariCP의 연결 풀..

Galera Cluster의 Flow Control은 Galera 클러스터에서 노드 간의 데이터 동기화를 관리하는 메커니즘으로, 클러스터의 안정성과 데이터 일관성을 유지하기 위해 중요한 역할을 합니다.Galera는 동기식 멀티마스터 데이터베이스 클러스터로 설계되어 데이터 무결성과 일관성을 보장하지만, 노드 간 데이터 동기화 속도와 처리 속도 차이를 조정해야 하는 상황이 종종 발생합니다. Flow Control은 이런 상황에서 클러스터의 전체 성능과 안정성을 조율합니다.1. Galera Cluster의 동작 원리Galera 동기화 구조Galera는 **Write Set Replication(WSREP)**을 사용하여 트랜잭션 데이터를 클러스터 내 모든 노드에 복제합니다.각 노드는 Write Set을 받고,..

MariaDB에서 InnoDB 엔진은 데이터 무결성, 트랜잭션 관리, 잠금 및 동시성 제어 등 고성능의 DB 운영을 위해 필수적인 요소입니다. InnoDB 설정 관련하여 성능을 모니터링할 수 있는 주요 요소들은 시스템 자원의 사용 현황과 데이터 처리 효율을 확인하는 데 도움이 되며, 이를 통해 잠재적인 성능 문제를 진단하고 최적화할 수 있습니다. 아래는 MariaDB에서 InnoDB 성능을 모니터링할 때 중요한 요소들입니다.1. InnoDB Buffer Pool 사용 현황InnoDB는 버퍼 풀(Buffer Pool)을 사용해 디스크 I/O를 최소화하고, 데이터를 메모리 상에 캐싱하여 성능을 향상시킵니다. InnoDB의 성능은 버퍼 풀이 얼마나 효과적으로 작동하는지에 크게 의존하므로, 다음 요소들을 중점적..

* MySQL 운영 환경에서 성능 저하를 방지하고 리소스를 효율적으로 모니터링하기 위한 다양한 명령어들이 있습니다.* 각 명령어는 서버의 상태를 특정 측면에서 분석하며, 주로 트랜잭션 처리량, 메모리 사용량, 잠금 현황 등 성능에 직접적인 영향을 미치는 요소를 모니터링하는 데 사용됩니다.MySQL 성능 모니터링을 위한 주요 명령어SHOW STATUSSHOW STATUS 명령어는 MySQL 서버의 일반적인 상태를 확인할 수 있게 해줍니다. 예를 들어 Connections(연결 수), Uptime(운영 시간), Questions(질의 수) 등의 지표를 제공하여 서버의 전체 상태를 파악하는 데 유용합니다. 특히 쿼리 수와 같은 요청 처리 빈도를 확인하여, 특정 시점에서의 부하 정도를 파악할 수 있습니다.Mar..

오늘은 mysql의 데이터 타입에 대한 내용입니다.(Mysql 8.4 기준) 1. 정수 유형 데이터 타입타입유형부호 있는 최소값미부호 최소값부호 있는 최대값미부호 최대값TINYINT1-1280127255SMALLINT2-3276803276765535MEDIUMINT3-83886080838860716777215INT4-2147483648021474836474294967295BIGINT8-26302의 63제곱-12의 64제곱-1 2. 고정 소수점 유형DECIMAL(M,D) / NUMERICM자리 정수와 D자리 소수점으로 표현, 최대 65자리=> 부동 소수전 유형은 현재 사용되지 않음 (8.0.19 이후) 3. 날짜 및 시간 데이터 유형타입0값DATE (3byte)'0000-00-00'TIME (3byte)'..

이번 포스팅에서는 복제 상태 및 서버 로그를 활용한 Galera Cluster 모니터링에 대해 알아보겠습니다. 복제 상태클러스터 무결성 및 노드 상태를 모니터링하면 복제를 방해하거나 차단할 수 있는 문제가 생길 수 있습니다.노드가 너무 바빠지지 않도록 Galera는 Flow Control 이라는 피드백 메커니즘을 트리거 하여 복제 프로세스를 관리합니다. 대기열에 쓰기 세트가 너무 많으면 노드는 Flow Control을 사용하여 복제를 일시 중지한 다음 따라잡을 수 있을 때까지 기다립니다. 이를 위해 확인할 상태 변수는 아래 세가지 입니다. wsrep_local_recv_queue_avgwsrep_flow_control_pausedwsrep_cert_deps_distance 이 변수들은 서버가 재시작되거나..

Galera Cluster는 안정적이고 신뢰할 수 있는 데이터베이스 복제 클러스터링 시스템입니다.InnoDB 스토리지를 갖춘 MySQL과 MariaDB는 모두 Linux를 실행하는 노드 간 통신에 Galera를 활용합니다. 하지만 운영하는 측면에서 지속적으로 클러스터 상태를 확인해야 합니다. 또한, 각 노드의 상태를 확인하고 모니터링하여 문제(예: 복제 지연, 네트워크 연결 등)를 방지해야 합니다.클러스터 활동 및 복제 상태를 모니터링하는 데 사용할 수 있는 방법은 세 가지가 있습니다. 1. MySQL의 상태 변수를 정기적으로 쿼리 2. 상태 변수의 변경에 반응하는 사용자 지정 스크립트를 사용, 상태 변수에 의존하는 타사 모니터링 애플리케이션을 사용할 수 있습니다. => Grafana - promethe..

클러스터 DB서버 정보1번 서버 - 192.168.59.134 maria12번 서버 - 192.168.59.135 maria23번 서버 - 192.168.59.136 maria3예상 테스트 시나리오1~3번 서버 기존 mysql 서비스 stop1번 서버 galera.cnf 수정 (gcomm)2,3번 서버 galera.cnf 수정 (gcomm)1번 노드 재기동, 에러 발생1번 서버 galera_new_cluster 명령 입력1번 서버 mysql start, 성공 시 2,3번 서버 mysql 서비스 startstatus 체크 후 data insert 테스트 진행(1번 → 2번 / 2번 → 1,3번 / 3번 → 1,2번) 형태의 클러스터 구축 성공 (로컬에서 운영 환경으로 테스트)1. 1~3번 서버 mysql ..

Redis 서버 3대 클러스터 구성을 통해 master-slave의 안정적인 형태의 구축을 목적으로 함데이터 파티셔닝 가능(샤딩)일부 노드가 실패하거나 통신이 불가한 상황에서도 정상적으로 운영 가능하다.→ 마스터 노드가 모두 다운되는 극단적 상황을 제외하고, 노드의 하위 집합에서 장애 발생 또는 클러스터의 나머지 부분과 통신이 불가능할 때에도 지속적으로 운영 가능테스트 redis 서버 #1~#3 (192.168.59.134 ~ 136) 구축→ 마스터 (#1~#3:6379) / slave (#1~#3:6380)Master #1 (6379) ==⇒ Slave #2 (6380)Master #2 (6379) ==⇒ Slave #3 (6380)Master #3 (6379) ==⇒ Slave #1 (6380) re..