information technology: 10월 2019

2019년 10월 26일 토요일

SQL - ORDER BY

MySQL에서 지원하는 ORDER BY의 부가적인 기능에 대해서 알아보자.

ORDER BY RAND
ORDER BY BINARY

ORDER BY RAND는 MySQL의 내장된 RAND() 함수를 이용하여 무작위로 레코드를 검색할 때 사용된다.

위의 그림에서 보는 거와 같이 order_rand 테이블에 6행의 레코드가 존재할 때, 랜덤으로 3행을 출력하면 매번 결과가 다른 것을 알 수 있다.

ORDER BY BINARY는 대소문자를 구별하여 정렬을 수행한다.

위의 그림에서 보는 거와 같이 order by binary name은 대문자가 출력된 후에 소문자가 출력된다.

그에 반해 order by name, binary name은 대소문자 구별 없이 정렬한 후 binary에 의해 대소문자가 정렬된다.

# Refer

https://dev.mysql.com/doc/refman/5.7/en/sorting-rows.html

https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_rand

2019년 10월 23일 수요일

Binary Log - Redo log 차이점

MySQL의 binary log와 redo log의 차이점을 살펴보자.

redo log는 innodb engine에만 해당하는 로그이고, binary log는 모든 engine에 해당한다.
redo log는 innodb engine level의 물리적 로그이며, binary log는 SQL statement에 상응하는 논리적 로그이다.
redo log는 복수의 고정 사이즈의 파일로 이루어져 있으며, binary log는 일련번호로 파일이 생성된다.

다음으로 redo log와 binary log가 기록되는 흐름을 알아보자.

설정은 sync_binlog = 1, innodb_flush_log_at_trx_commit = 1을 가정한다.

DML 발행
innodb log buffer에 기록
커밋 시 redo log에 flush(prepared 상태)
binlog에 기록
redo log와 binlog의 status를 완료로 변경

* 만약 그림의 1 타이밍에 crash가 일어나면 binlog에 기록되지 않은 상태이므로, MySQL을 재시작 하면 해당 DML은 rollback 된다.
* 2 타이밍에 crash가 일어나면 binlog에 기록된 상태이므로, MySQL을 재시작 하면 해당 DML은 commit 된다 .

# Refer

https://qiita.com/jiangyonglian/items/f581e5ec0a982a4e7100

https://topic.alibabacloud.com/a/the-difference-between-mysql-innodbs-redo-log-and-binlog_1_41_30054519.html

2019년 10월 21일 월요일

SSD

SSD에 대하여 알아보고, HDD가 어떻게 다른 지 비교해보자.

SSD는 Solid State Drive의 약자로 직역하면 고체상태의 드라이브를 의미하며, 저장 매체가 반도체이다.

SSD도 종류가 있다.

SLC(Single Level Cell) - 픽셀 : 비트 = 1 : 1
MLC(Multi Level Cell) - 픽셀 : 비트 = 1 : 2
TLC(Triple Level Cell) - 픽셀 : 비트 = 1 : 3
QLC(Quad Level Cell) - 픽셀 : 비트 = 1 : 4

속도는 SLC > MLC > TLC > QLC 순이며, 저장용량은 SLC < MLC < TLC < QLC 순이다.

HDD와 SSD 비교

SDD는 HDD 같은 물리적인 방식이 아니므로 속도가 빠르다.

하지만 HDD 보다 비싸며, 수명이 짧다.

# Refer
https://coderlife.tistory.com/317
https://chimolog.co/bto-ssd-slc-mlc-tlc/
https://volttexture.tistory.com/entry/HDD-SSD-Nvme-%EC%86%8D%EB%8F%84-%EC%B0%A8%EC%9D%B4%EC%A0%90%EA%B3%BC-%EC%9E%A5%EB%8B%A8%EC%A0%90-%EB%B9%84%EA%B5%90

2019년 10월 19일 토요일

Replication - lossless semi-sync

MySQL 5.7버전에서 lossless semi-sync replication이 추가되었다.

5.5 버전부터 제공하고 있던 semi-sync와 어떤 차이점이 있는 지 알아보도록 하자.

기존의 semi-sync는 Commit을 한 후에 해당 DML이 Slave에 적용될 때 까지 기다리는 구조였다. 그래서 Slave에 적용되기 전에 Master가 Crash하면 아래와 같은 상황이 발생할 수 있다.

이 같은 상황을 방지하기 위해서 5.7버전에서 rpl_semi_sync_master_wait_point 라는 설정이 추가되었다.

설정은 AFTER_SYNC와 AFTER_COMMIT 두가지 중 하나를 할 수 있는 데, 기존의 방식이 AFTER_COMMIT이고 새로 추가된 게 AFTER_SYNC이다.

위 그림과 같이 AFTER_SYNC는 Slave에게 적용이 됐다는 신호를 받은 후에 Master가 Commit을 하고 Client에게 결과를 반환한다. 즉, 적어도 하나의 Slave에는 동기화가 되어 있다는 것을 보장한다.

AFTER_SYNC에서 주의할 점은 Crash된 Master를 재사용 할 수 없다.

왜냐하면 binary log에 uncommitted transactions가 포함되어 있을 수 있기 때문에 Slave가 Recovery할 때 conflict가 일어날 수가 있다.

# Refer
https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html
https://dev.mysql.com/doc/refman/5.7/en/replication-options-master.html#sysvar_rpl_semi_sync_master_wait_point
http://my-replication-life.blogspot.com/2013/09/loss-less-semi-synchronous-replication.html

2019년 10월 17일 목요일

High Availability - MMM과 MHA차이

MySQL을 이중화 하는 대표적인 MMM과 MHA 차이에 대해서 알아보도록 하자.

가장 큰 차이점은 MMM(Multi-Master Replication Manager For MySQL)는 데이터 정합성이 보장되지 않을 수 있고, MHA(MHA for MySQL)은 데이터 정합성이 보장된다.

MMM의 구조는 아래와 같다.
Active 마스터와 Standby 마스터가 양방향 복제하고 Active 마스터만 읽기작업을 한다.