AWS JDBC Wrapper 란?AWS에서 제공하는 AWS JDBC driver는 현재 deprecated되고 AWS wrapper로 대체되었다. AWS wrapper는 기존의 JDBC driver를 한 번 감싼 형태로, 편의성을 위해 여러 플러그인을 제공하는 DB connector이다.이 중 DB 운영에 가장 유용하게 쓰일만한 플러그인은 단연 fast-failover 와 read/write splitting 플러그인이다.fast-failover: failover 발생 시 connection error 없이 빠른 failover가 가능read/write splitting: 하나의 접속스트링만으로도 reader/writer 전환 가능https://github.com/aws/aws-advanced-jdbc..

복제 환경에서 GTID가 간혹 가다 틀어지는 경우가 있다. GTID가 틀어지는 원인 다양한 원인이 존재하나, 대부분은 sql_log_bin=ON 상태에서 DBA의 변경 작업(DML, DDL)으로 인해 발생한다. slave의 sql_log_bin 상태가 "ON"이면 트랜잭션에도 master 서버로부터 넘어오는 GTID set과 별개로 GTID가 부여되면서 두 서버간의 GTID set이 달라지게 되는 것 GTID가 틀어졌을 때의 문제점 failover시 문제 발생 달라진 데이터에 대해 master로부터 DML이 넘어오는 경우 replication 자체가 깨질 위험 있음 해결 방법 기본적으로 GTID 맞추는 작업은 1. 데이터 정합성 맞추기 → 2. GTID 맞추기의 과정이며, 1. 데이터 정합성 맞추기 단계..

mysql에서 데이터 flush를 하는 기본 순서는 1. 버퍼 풀 or log buffer에 있는 내용을 flush하면 2. mySQL 안의 버퍼에 있던 내용을 메모리 상의 OS cache로 이동(write) 3. OS cache 안의 내용을 디스크상의 데이터 파일로 이동(flush) 인데, innodb storage engine에서는 innodb_flush_method 변수를 통해 flush 방법을 설정할 수 있다. fsync: default로 설정되어 있는 방법. 버퍼 풀과 로그 버퍼 모두 OS cache를 이용하고, fsync()를 통해 OS cache에서 디스크로 데이터를 이동한다. O_DSYNC: 로그 버퍼에서 write를 할 때(2번 단계) 자동적으로 데이터 파일에 fsync()까지 한 번에 ..

UTF8 VS UTF8MB4 영어 등 서구권 언어: 1글자당 1byte 한글 등 아시아권 언어: 1글자당 2byte UTF-8: 1글자당 1~3byte(가변적) utf8mb4: 가변 4byte utf-8 charset 다국어를 지원하기 위해 1~3 가변바이트 charset utf-8이 주로 사용되어왔다. 그러나 emoji 등 새로 개발된 언어는 글자당 4바이트를 차지하므로, 해당 charset으로 설정되어있는 경우 글자가 깨지는 현상이 발생한다. 따라서 mySQL 5.5 이후 버전부터는 utf8mb4 charset을 지원하면서 최대 4바이트까지 문자를 저장할 수 있도록 하고 있다😄 검색이나 로그인 등 다양한 경우에서 대소문자 구분 여부는 중요하다. 예를 들어, 회원가입 시 비밀번호 설정 부분에서는 대/소..

Unix 시간 변수에 32bit 정수형을 사용해서 발생한 이슈로,DBMS에서 현재 날짜+시간+timezone을 나타내는 TIMESTAMP 타입 변수를 사용할 시2038-01-19 03:14:07 UTC까지가 표기 최대범위인 문제가 있다.MySQL에는 아직 해당 이슈가 남아있다. 이 시간을 초과하면 사인 비트가 1로 변하면서 음수가 되어 자동으로 오류를 감지하면서 시간이 0으로 초기화(1970-01-01 00:00:00)으로 돌아가는 버그이다.따라서 TIMESTAMP 대신 DATETIME변수를 사용하거나, 시간 변수에 64비트를 사용하면 문제가 해결(?)된다. 292,277,026,596년까지 표기되므로 나를 포함한 이 글을 보고 있는 사람들 모두 64비트를 사용함으로써 발생하는 문제와는 상관이 없지 않을..

Mysql document를 읽던 도중 PAD_CHAR_TO_FULL_LENGTH 옵션에 대해 알게 되었다. 고정길이 문자형 변수를 저장하는 CHAR타입 컬럼에 이 옵션을 disable시키면, VARCHAR타입과 같이 남은 공간을 space가 아닌 null로 처리해주는 옵션이었다. (default로 활성화되어있는 변수이기 때문에, CHAR타입의 길이보다 적게 데이터를 입력하면 알아서 space처리가 된다.) 그렇다면 VARCHAR형과 같은 데이터 타입인데.. 굳이 이 옵션을 만들어서 둘을 구분해 둔 이유가 궁금해서 테스트를 진행해 보았다. 테스트 환경은 macOS Catalina 10.15, MySQL 5.7 버전을 사용하였다. char type 우선 PAD_CHAR_TO_FULL_LENGTH = dis..

InnoDB의 redo log는 여러 파일로 구성되어 있지만, 내부적으로 이를 모아서 하나의 연속된 공간으로 사용한다. InnoDB Redo Log size = innodb_log_file_size * innodb_log_files_in_group * mysql 5.7 ver에서는 redo log를 최대 2TB까지 설정할 수 있다. 1) innodb_log_file_size - 각 로그파일의 size를 결정하는 시스템 변수 버퍼 풀의 크기가 아무리 크더라도 redo log의 크기가 작으면 자주 checkpoint가 발생하기 때문에 버퍼 풀을 제대로 이용할 수 없게 된다. 따라서 버퍼 풀의 크기를 변경하는 경우, redo log file의 크기도 함께 변경해야 한다. 일반적으로 innodb_buffer_p..

출처:mySQL 8.0 document https://dev.mysql.com/doc/refman/8.0/en/innodb-in-memory-structures.html 1) Buffer Pool - 데이터 파일과 인덱스 정보 캐싱 + write buffering => random I/O 감소 mySQL innoDB 스토리지 엔진의 버퍼 풀 크기를 결정하는 변수는 innodb_buffer_pool_size로, 기본 128MB이다. 크기를 크게 할수록 disk 접근 횟수 줄어들기 때문에 성능이 향상되나, 서버 용량에 비해 너무 큰 값을 설정하면 page swap이 자주 발생하여 성능이 저하될 수 있음 DB를 운영할 때는 최적의 상태로 리소스를 쥐어짜내면서 가장 효율적으로 데이터를 사용해야 한다. 현재는 S..