[mysqld]

port                =3333

socket            =/tmp/service_mysql.sock

user = mariadb

server-id = 1

basedir = /mariadb/service/instance

datadir = /servicedata/service/datadir

tmpdir  = /servicedata/servicetmpdir

character-set-server  = utf82    ## utf8mb4 는 이미지까지 받아주는 걸로 알고있다.

collation-server = utf8_bin

default_storage_engine = InnoDB

event_scheduler = on

sysdatae-id-now

performance_schema = on

back_log = 100

max_connections = 4000

max_connect_errors = 99999

max_statament_time = 7200

table_open_cache = 2048

wait_timeout = 3600

interactive_timeout = 3600

max_allowed_packet = 32M

max_heap_table_size = 128M

tmp_table_size = 128M

sort_buffer_size = 256K

join_buffer_size = 256K

read_buffer_size = 256K

read_rnd_buffer_size = 256K

query_cache_type = 0

query_cache_size = 0

query_cache_limit = 0

transaction_isolation = READ-COMMITTED

optimizer-switch='split_materialized=off'

plugin-load = unix_socket=auth_socket.so

#### InnoDB Specific Options ####

innodb_data_file_path = ibdatal:1G:autoextend

innodb_file_per_table = 1

innodb_buffer_pool_size = 32G

innodb_log_buffer_size = 64M

innodb_log_file_size = 1G

innodb_log_files_in_group = 2

innodb_autoextend_increment = 256

innodb_flush_log_at_trx_commit = 1

innodb_flush_method=O_DIRECT

innodb_lock_wait_timeout = 120

### MyISAM Specific options ###

key_buffer_size = 64M

bulk_insert_buffer_size = 64M

myisam_sort_buffer_size = 128M

myisam_repair_threads = 1

### Logging Options ###

log_bin = /servicebinary/binlog

general_log = 0

ezpire_logs_days = 5

slow_query_log = 1

long_query_time = 5

log_error = /servicedata/service/logdir/error.log

slow_query_log_file = /servicedata/service/logdir/slow.log

general_log_file = /servicedata/service/logdir/general.log

#### DBA CONFig ####

lower_case_table_name = 1

skip_name_resolve

skip_external_locking

log_slow_verbosity = 'explain'

📌 데이터베이스 트랜잭션과 내부 구조 (실무 관점 정리)

1. ACID와 Isolation Level

• ACID는 트랜잭션의 기본 원칙.
• 그중 **I (Isolation, 격리성)**을 세부적으로 구현한 것이 Isolation Level.

✅ 트랜잭션과 관련된 다른 개념 (계층, 구조 등)

1. ACID 속성 트랜잭션의 기본 원칙:
Atomicity (원자성): 모두 성공하거나 모두 실패해야 함
Consistency (일관성): 트랜잭션 전후 데이터가 무결성 유지
Isolation (격리성): 다른 트랜잭션과 독립적으로 수행
Durability (지속성): 커밋된 데이터는 영구 반영

➡️ Isolation Level은 ACID 중 **I (격리성)**을 어떻게 구현할지에 대한 세부 옵션.

2. MVCC (Multi Version Concurrency Control) – 다중 버전 동시성 제어

주로 READ COMMITTED 또는 REPEATABLE READ에서 사용됨.

데이터를 수정할 때 기존 버전을 유지해서 트랜잭션마다 스냅샷을 보는 것처럼 처리.

Oracle, PostgreSQL, InnoDB 등에서 MVCC 사용.

트랜잭션마다 Undo Log 혹은 Rollback Segment를 참조해서 과거 데이터를 조회함.

2. MVCC (Multi-Version Concurrency Control)

트랜잭션이 동시에 같은 데이터를 읽고 쓸 때 충돌을 줄이는 방식.
👉 핵심 아이디어: “읽는 트랜잭션은 과거 버전을 보고, 쓰는 트랜잭션은 새로운 버전을 만든다.”

(1) 동작 원리

• INSERT → 새로운 Row 생성.
• UPDATE → 새로운 버전(Row)을 만들고, 기존 Row는 Undo Log에 보관.
• DELETE → 실제 삭제하지 않고 "삭제 플래그"를 기록.
• SELECT → 트랜잭션 시작 시점의 Snapshot(Undo Log 참조)으로 읽음.

(2) DBMS별 MVCC 구현

• Oracle : Undo Segment 기반. SELECT는 Undo에 있는 과거 버전을 읽음.
• PostgreSQL : Tuple 버전 관리 → Vacuum(청소 작업) 필요.
• MariaDB/InnoDB : Undo Log + Redo Log 조합. Snapshot 읽기 지원.

3. Locking 계층 (동시성 제어)

트랜잭션 충돌을 제어하기 위해 락을 건다.

(1) 주요 락 단위

• Row-Level Lock : InnoDB. 동시성 높음.
• Table-Level Lock : MyISAM, 일부 DDL. 단순하지만 동시성 낮음.
• Gap Lock / Next-Key Lock : Phantom Read 방지용 (InnoDB).

(2) Intent Lock

• 계층적 락 구조에서 충돌 체크용.
• 예: 테이블 전체 락 vs 특정 Row 락이 충돌하는지 빠르게 판단.

(3) 락 경합(Tuning 관점)

• innodb_row_lock_waits : 락 충돌 횟수
• innodb_row_lock_time_avg : 평균 대기 시간
• 해결책:
  • 트랜잭션 단위를 짧게 유지
  • 인덱스 튜닝 → 불필요한 Range Scan 줄이기
  • Batch Update 대신 Chunk Update

4. Undo / Redo 로그 계층

(1) Undo Log

• MVCC 지원 : 과거 버전 데이터를 저장.
• Rollback 지원 : 트랜잭션 실패 시 원상 복구.
• InnoDB는 Undo Tablespace에 저장.

(2) Redo Log

• 장애 복구용 : Commit된 변경 사항을 기록.
• DB Crash 후 Redo Log를 리플레이하여 데이터 복원.
• InnoDB는 Write-Ahead Logging (WAL) 사용 → 먼저 Redo Log에 기록 후 실제 데이터 반영.

✅ 요약 (한눈에 보기)

mariadb을 사용하다 보면 Binlog(바이너리 로그)가 디스크에 백업이 된다. 

디스크의 용량이 크다면 크게 상관없겠지만, 디스크 용량이 적거나 아니면 백업되는 Binlog 사이즈가 큰 경우

결국 mariadb가 원활하기 구동될 수 있도록 디스크 관리를 해줘야 한다.

이때  Binlog(바이너리 로그)가 불필요하게 너무 많이 쌓이게 되면 삭제를 진행해줘야 한다.

이번에는 Binlog(바이너리 로그)에 대해서 조회 방법, 삭제 방법, 보관 기간 설정하는 부분을 알아보도록 하자. 

그럼 먼저 Binlog(바이너리 로그)가 무엇인지 알아보자.

1. Binlog(바이너리 로그)란?

바이너리 로그는 MySQL 3.23.14 Version부터 도입되었으며, Create, Drop과 같은 DDL문과 Insert, Update, Delete와 같은 DML문을 통해서 데이터의 변화가 발생할 경우 해당 이벤트들을 기록하는 로그 파일이다.

DDL / DML문에 대해서는 아래 내용을 참고하도록 하자.

2. Binlog(바이너리 로그) 조회 방법

먼저 mariadb Data가 쌓이는 디렉토리에서 Binlog(바이너리 로그)가 얼마나 쌓였는지 확인해보자. 

• $ ls -alth binlog*

이와 같이 Binlog(바이너리 로그)가 순차적인 번호를 이용하여 많은 용량을 쌓아가는 것을 확인할 수 있다. 

이때 해당 디렉토리에서 Binlog(바이너리 로그)를 바로 삭제하면 문제가 발생할 수 있으니, 해당 디렉토리에서 먼저 확인 후 꼭 mariadb 내부에서 삭제 명령어를 통해서 삭제하도록 하자.

mariadb 내부에서는 아래 명령을 사용하여 Binlog(바이너리 로그)를 조회할 수 있다. 

• mysql> show binary logs;

3. Binlog(바이너리 로그) 삭제 하기

이제 확인한 Binlog(바이너리 로그)에서 오래된 파일을 삭제해보도록 하자.

위에서도 이야기했지만 꼭 mariadb 내부에서 삭제 명령어를 통해서 삭제하도록 하자.

아래 명령어를 통해서 삭제할 수 있다. 

• mysql> purge master logs to 'binlog.xxx';
  • 삭제할 binlog 번호를 입력하여 이 이전 데이터도 한 번에 삭제할 수 있다.  

이처럼 mariadb Data가 쌓이는 디렉토리에서도 삭제된 것을 확인할 수 있다. 

4. Binlog(바이너리 로그) 보관 기간 조회

이렇게 매번 특정 시점마다 Binlog(바이너리 로그)를 삭제하는 방법도 있겠지만, 보관 기간을 설정하여 해당 기간까지만 Binlog(바이너리 로그)가 남도록 설정하는 것도 방법이다. 

그럼 먼저 Binlog(바이너리 로그) 보관 기간을 조회해보도록 하자.

조회하는 명령어는 아래와 같다. 

• mysql> show global variables like 'binlog_expire_logs_seconds';

mariadb Version에 따라서 기존에는 expire_logs_days를 사용하는 부분도 있으나, MySQL 8.x Version부터는 binlog_expire_logs_seconds를 사용한다.

보관 기간은 second(초)를 기반으로 계산된다. 

현재 기본값(Default)으로 설정된 값은 2,592,000 초이다. 

이것으로 일자로 환산해보면 30일이다. 

환산하는 방법은 잘 알고 있겠지만. 

1일 = 24시간 / 24시간 = 1440분 / 1440분 = 86,400초 를 기반으로 86,400초 * 30일 = 2,592,000 초가 된다. 

5.Binlog(바이너리 로그) 보관 기간 설정

이제 Binlog(바이너리 로그) 보관 기간을 설정해보도록 하자. 

보관 기간은 3일로 설정하고 설정하는 명령어는 아래와 같다. 

• mysql> set global binlog_expire_logs_seconds=259200
  • 86,400초 * 3일 = 259,200 초

6. 참고 문서

• https://dev.mysql.com/doc/internals/en/binary-log-overview.html