[오픈소스컨설팅]Day #2 MySQL Tuning, Replication, Cluster

Day #2
MySQL Tuning, Replication, Cluster
Certified Partner by
오픈소스컨설팅(http://www.osci.kr)
오픈소스컨설팅은 기술과 노하우 공유를
위해 항상 노력합니다.

2
- Internal Use Only -
목차
MySQL 최적화
최적화 간략 소개
파티셔닝
Thread pool
테이블 유지보수
•테이블 검사, 최적화, 복구
MySQL Replication
replication 소개
replication 구성방법
replication tuning 방법
MySQL Cluster
Cluster 소개
Cluster 구성방법
Cluster tuning 방법

MySQL 최적화

4
MySQL 최적화 MySQL의 다양한 최적화 방법들
스레드 풀
테이블 파티셔닝
테이블 옵티마이즈
쿼리 프로파일링
쿼리 실행계획
슬로우 로그 확인 및 해결
에러로그 확인 및 해결
여러가지 튜닝 방법들
Table optimize
Group 1
Group 2
Group 3
Group 4
Table partitioning
Thread pool

MySQL 최적화 - table partitioning

6
Table partitioning
v5.1부터 가능
Partition 은 분리, 분할 한다는 의미
데이터를 분할/관리함으로써 보다 빠른 데이터처리
하나의 큰 테이블로 사용할 경우 그 만큼 인덱스도 커지고, 물리적인 공간도 필요
특정 데이터 집합의 추가/삭제가 간편함
데이터 검색 시 특정 파티션만 읽어서 속도를 향상
병렬 처리가 가능
한 테이블에 너무 많은 데이터가 입력되었을 시 발생하는 속도 저하를 방지함
MySQL 에서 Partition 을 사용할 경우 효과
Partition 개요
Group 1
Group 2
Group 3
Group 4
Table partitioning

7
Table partitioning
모든 파티션은 동일한 스토리지 엔진 사용
Partition 된 테이블은 foreign Key 미지원
Partition 된 테이블은 FullText Index 미지원
한 테이블당 파티션의 갯수는 최대 1,024개
Partition 값은 정수형
Temp Table 은 파티션 사용 불가
파티션별 다른 엔진을 지정하여도 에러가 발생하지는 않지만 적용 안됨
Partition 된 테이블은 Geometry(point, geometry...) 컬럼 타입 미지원
제약사항
테이블이 Unique 또는 Primary Key를 가지고 있다면, 파티션키는 모든 Unique 또는 Primary Key의 일부 또는 모든 컬럼을 포함해야 한다.
Group 1
Group 2
Group 3
Group 4
Table partitioning

8
CREATE TABLE `employees` ( `id` INT NOT NULL, `fname` VARCHAR(30), `lname` VARCHAR(30), `hired` DATE NOT NULL DEFAULT '1970-01-01', `separated` DATE NOT NULL DEFAULT '9999-12-31', `job_code` INT NOT NULL, `store_id` INT NOT NULL ) PARTITION BY partition type (id) PARTITIONS number;
Table partitioning Example
물리적 파일 정보
테이블 정보 파일
파티션 정보 파일
분할된 데이터 파일

9
Table partitioning 종류
Range 파티션 키의 연속된 범위로 파티션을 정의
List Range 파티션과 비슷, 파티션 키 값이 고정 값일 경우
Hash HASH 함수에 의해 레코드가 저장될 파티션을 결정하는 방식
Key 해시 파티션과 거의 동일, 해시값을 계산하는 방법을 사용자가 지정 가능
Subparttioning 복합 파티셔닝

10
Range partitioning
파티션 키의 연속된 범위로 파티션을 정의
날짜 기반 데이터가 누적되고 년도, 월,일 단위로 분석, 삭제 할 경우
범위 기반으로 데이터를 여러 파티션에 균등하게 나눌 수 있을 경우
파티션 키 위조로 검색이 자주 실행 될 경우
대량의 과거 데이터 삭제 시
CREATE TABLE `range_partition_exam`
(
id INT NOT NULL,
fname VARCHAR(30),
lname VARCHAR(30),
hired DATE NOT NULL DEFAULT '1970-01-01',
separated DATE NOT NULL DEFAULT '9999-12-31',
job_code INT NOT NULL,
store_id INT NOT NULL
)
PARTITION BY RANGE (YEAR(hired))
(
PARTITION p0 VALUES LESS THAN (2010),
PARTITION p3 VALUES LESS THAN MAXVALUE
);
Range 파티션에서 Null 은 어떤 값보다 작은 값으로 취급된다. hired 컬럼이 Null 인 데이터가 insert 된다면 가장 작은 값을 저장하는 p0에 저장된다. 하지만 파티션 지정시 PARTITION p0 VALUES LESS THAN (NULL) 과 같이 지정할 수는 없다.
날짜 컬럼에 대한 Range 파티션 적용시 YEAR(), TO_DAYS() 함수만 사용하길 권장한다. 이 두 함수는 MySQL 서버 내부적으로 파티션 프루닝처리가 되어 성능상의 문제가 발생하지 않지만 그 외의 함수는 파티션 프루닝이 제대로 작동하지 않을 수도 있다. (UNIX_TIMESTAMP()를 이용한 변환식, 날짜를 문자열로 포매팅한 형태('2012-02-12')등의 형태는 사용하지 않길 바란다)

11
Partition 추가
ALTER TABLE `range_partition_exam` ADD PARTITION(PARTITION p4 VALUES LESS THAN (2009));
Partition 삭제
ALTER TABLE employees DROP PARTITION p4;
Range Partitioning 운영
제약 사항에 걸릴 수 있음!!
Partition 분리
ALTER TABLE `range_partition_exam` REO RGIANIZE PARTITION p3 INTO
(
PARTITION p4 VALUES LESS THAN MAXVALUE
);
Partition 병합
ALTER TABLE `range_partition_exam` REORGANIZE PARTITION p2, p3 INTO ( PARTITION p23 VALUES LESS THAN (2012) );

12
Range 파티션과 비슷
파티션 키 값이 코드 값이나 카테고리와 같이 고정 값일 경우
키 값이 연속적이지 않고 정렬순서와 관계없이 파티션을 해야 할 경우
파티션 키 값을 기준으로 레코드 건수가 균일하고 검색 조건에 파티션 키가 자주 사용 될 때
List
CREATE TABLE `list_partition_exam` ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT '1970-01-01', separated DATE NOT NULL DEFAULT '9999-12-31', job_code INT NOT NULL, store_id INT NOT NULL ) PARTITION BY List (job_code) ( PARTITION p0 VALUES IN (3), PARTITION p1 VALUES IN (1,9), PARTITION p2 VALUES IN (2,6,7), PARTITION p3 VALUES IN (4,5,8,NULL) );
Range 와 달리 Null 을 명시할 수 있으며, MaxValue 를 지정할 수는 없다.
v5.5 부터는 파티션 키 값에 정수형 값 이외에 문자열 타입도 사용 가능하다.
PARTITION BY List (job_code)
(
PARTITION p0 VALUES IN ('sports'),
PARTITION p1 VALUES IN ('teacher'),
PARTITION p2 VALUES IN ('student'),
PARTITION p3 VALUES IN ('banker',null)
);

13
HASH 함수에 의해 레코드가 저장될 파티션을 결정하는 방식
Range, List 로 데이터를 균등하게 나누는 것이 어려울 때.
테이블의 모든 레코드가 비슷한 사용빈도를 보이지만 너무 커서 파티션 적용이 필요한 경우
Hash
CREATE TABLE `hash_partition_exam`
(
id INT NOT NULL,
fname VARCHAR(30),
lname VARCHAR(30),
)
PARTITION BY HASH (id)
PARTITIONS 4;
PARTITIONS 4
(
PARTITION p0 ENGINE = INNODB,
PARTITION p1 ENGINE = INNODB
);
CREATE TABLE `hash_partition_exam`
(
id INT NOT NULL,
fname VARCHAR(30),
lname VARCHAR(30),
)
PARTITION BY LINEAR HASH ( YEAR(hired) )
PARTITIONS 4;
OR

14
Partition 추가
파티션의 갯수로 MOD 연산한 결과에 따라 각 레코드를 저장할 파티션을 결정하므로 새로이 파티션이 추가될 경우 파티션에 저장된 모든 레코드는 재배치 되어야 하므로 많은 부하가 발생한다.
ALTER TABLE `hash_partition_exam` ADD PARTITION (PARTITION p5 ENGINE = INNODB); (파티션 이름을 부여하는 경우)
ALTER TABLE `hash_partition_exam` ADD PARTITION PARTITIONS 3; (별도의 이름 없이 3개의 파티션을 추가하는 경우)
Partition 삭제
파티션 키 값을 이용하여 데이터를 각 파티션으로 분산한 것이므로 각 파티션에 저장된 레코드의 부류를 사용자가 예측할 수 없기에 해시나 키를 이용한 파티션에서는 파티션단위의 삭제는 불가하다
Hash Partitioning 운영
Partition 분리
특정 파티션을 분할하는 것은 불가하면, 파티션 추가만 가능
Partition 병합
2개이상의 파티션을 하나로 합치는 기능은 제공 안함
파티션의 갯수를 줄이는 것은 가능
ALTER TABLE employees COALESCE PARTITION 1; (4개에서 3개로 재구성) (기존 파티션의 갯수에서 1개를 뺀 수 만큼 파티션을 재배치 한다.

15
해시 파티션과 거의 동일. 해시값을 계산하는 방법을 사용자가 지정 가능
키 파티션은 선정된 파티션 키값에 대하여 내부적으르 MD5() 함수를 이용하여 해시값을 계산하고, 그 값에 MOD를 적용하여 저장할 파티션을 결정
Key
CREATE TABLE `key_partition_exam` ( id INT NOT NULL PRIMARY KEY, name VARCHAR(20) ) PARTITION BY KEY() PARTITIONS 2;
KEY( ) 절에 컬럼을 명시하지 않아도 에러가 나지 않는데 명시하지 않으면 PK가 파티셔닝 키로 사용, PK가 없다면 UK가 파티셔닝에 사용
KEY 파티셔닝의 key 컬럼은 반드시 NOT NULL

16
Sub partitioning
CREATE TABLE `key_partition_exam` ( id INT NOT NULL PRIMARY KEY, name VARCHAR(20), purchased DATE ) PARTITION BY RANGE ( YEAR (purchased) ) SUBPARTITION BY HASH ( TO_DAYS(purchased) ) ( PARTITION p0 VALUES LESS THAN (1990) ( SUBPARTITION s0, SUBPARTITION s1 ), PARTITION p1 VALUES LESS THAN (2000) ( SUBPARTITION s2, SUBPARTITION s3 ), PARTITION p2 VALUES LESS THAN (1990) ( SUBPARTITION s4, SUBPARTITION s5 ) );
RANGE 파티션 하위에 Hash 파티션
파티션 안에 또 다른 작은 파티션을 만들 수 있음
Range 나 List 파티션 안에 서브 파티션으로 Hash 나 Key 파티션을 만드는 것도 가능

17
Partitioning 확인방법
CREATE TABLE `range_partition_exam` ( `id` int(11) NOT NULL, `fname` varchar(30) COLLATE utf8_bin DEFAULT NULL, `lname` varchar(30) COLLATE utf8_bin DEFAULT NULL, `hired` date NOT NULL DEFAULT '1970-01-01', `separated` date NOT NULL DEFAULT '9999-12-31', `job_code` int(11) NOT NULL, `store_id` int(11) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin /*!50100 PARTITION BY RANGE (YEAR(hired)) (PARTITION p0 VALUES LESS THAN (2010) ENGINE = InnoDB, PARTITION p1 VALUES LESS THAN (2011) ENGINE = InnoDB, PARTITION p2 VALUES LESS THAN (2012) ENGINE = InnoDB, PARTITION p3 VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */
> Show CREATE TABLE `range_partition_exam`
Partition 확인 방법

18
Table partitioning PATH 지정 방법
CREATE TABLE test ( id INT AUTO_INCREMENT, partition_region int default 0, note VARCHAR(500), INDEX idx (id) ) ENGINE = MYISAM PARTITION BY KEY(id) ( PARTITION p0000 INDEX DIRECTORY = '/home/xpartition/idx' DATA DIRECTORY = '/home/xpartition/data/data-0000', PARTITION p0001 INDEX DIRECTORY = '/home/xpartition/idx' DATA DIRECTORY = '/home/xpartition/data/data-0001', PARTITION p0002 INDEX DIRECTORY = '/home/xpartition/idx' DATA DIRECTORY = '/home/xpartition/data/data-0002', PARTITION p0003 INDEX DIRECTORY = '/home/xpartition/idx' DATA DIRECTORY = '/home/xpartition/data/data-0003', PARTITION p0004 INDEX DIRECTORY = '/home/xpartition/idx' DATA DIRECTORY = '/home/xpartition/data/data-0004' );
Directory 지시자를 이용
인덱스 파일과 데이터 파일을 따로 위치 시킴
물리적인 위치의 PATH가 존재하지 않으면 에러
MySQL이 없는 경로를 생성해주진 않음
해당 경로의 디렉토리에 권한 필요
실제 파일은 지시자에 의해 지정된 위치에 존재
MySQL 기본 datadir 위치에는 링크 파일이 위치함

19
Table partitioning 확인
실제 파일은 파티션 생성 시 지정된 위치에 있음
MySQL datadir 위치에는 링크 파일이 위치함

20
각 파티션 균등하게 증가
> insert into test (id, partition_region) values (1, 0);

21
mysql> SELECT partition_name, table_rows FROM information_schema.PARTITIONS WHERE table_schema='rwx' AND table_name='test';
데이터 상태 살펴보기

MySQL 최적화 - thread pool

23
MySQL 최적화 - Thread Pool MySQL은 상용버전에서만 사용가능, MariaDB, Percona 는 기본 사용가능
기본 스레드 생성 방식
스레드 풀 방식
Request
MySQL은 connection 당 Thread 를 생성한다.
Result 가 반환되고 Thread 가 더 이상 사용되지 않으면 종료 루틴
Response
Request
1
2
3
4
5
6
…
Thread pool
Response
1
recycle
요청이 오고 connection 이 이루어지는 순간 부하발생
이미 생성되어 있는 connection이 요청에 응답, connection overhead 없음
Default connect

24
MySQL 최적화 - Thread Pool
Thread pool 확인
mysql> show variables like '%thread%';
Default connection
pooling connection

25
Thread pool 설정
Thread_handling=pool-of-threads
My.cnf 파일에서 [mysqld] 섹션에 추가

26
Thread pool 을 위한 그 외 설정값들
thread_pool_idle_timeout
Command Line:
Yes
Config File:
Yes
Scope:
Global
Dynamic:
Yes
Variable Type:
Numeric
Default Value:
60 (seconds)
: 유효 스레드가 종료 전 대기하는 시간 제한
thread_pool_max_threads
Command Line:
Yes
Config File:
Yes
Scope:
Global
Dynamic:
Yes
Variable Type:
Numeric
Default Value:
500
풀에 있는 스레드의 최대수 제한, 설정 값에 도달하면 더 이상 생성되지 않음
thread_pool_size
Command Line:
Yes
Config File:
Yes
Scope:
Global
Dynamic:
Yes
Variable Type:
Numeric
Default Value:
Number of processors
동시에 CPU를 사용할 수 있는 스레드 수

27
Thread pool 을 위한 그 외 설정값들
thread_pool_oversubscribe
Command Line:
Yes
Config File:
Yes
Scope:
Global
Dynamic:
Yes
Variable Type:
Numeric
Default Value:
3
: 이 매개 변수의 값이 클수록 더 많은 스레드를 동시에 실행할 수 있습니다
thread_pool_stall_limit
Command Line:
Yes
Config File:
Yes
Scope:
Global
Dynamic:
No
Variable Type:
Numeric
Default Value:
500 (ms)
: 롱 쿼리 제한 설정, 스레드의 시간을 밀리 초 단위로 간주, 제한에 도달하면 새로운 스레드를 만들거나 풀이 일어남

MySQL 테이블 유지보수

29
MySQL 최적화 - table check, optimize, repair
Table 최적화 명령어들
check table `table name`
repair table 은 테이블 에러를 체크
check table 명령어는 MyISAM, ARCHIVE, InnoDB engine 에서만 적용
키 통계치 업데이트
뷰 체크

30
optimize table `table name`
optimize table 은 테이블을 최적화 한다
optimize table 명령어는 테이블의 많은 부분을 삭제하거나 테이블에 변경사항이 많아 테이블에 가변길이로 로우를 적용할 때 사용 ( varchar, varbinary, blob, text 컬럼을 가진 테이블 ) 삭제된 로우는 연계된 리스트에 계속 남아있고 그 다음 INSERT 실행은 이전 로우 포지션을 재사용
사용한 적이 없는 스페이스를 교정, 데이터파일을 조각처리하기 위해 사용

31
analyze table `table name`
ANALYZE TABLE은 테이블의 중요 분포(key distribution)를 분석하고 저장
분석하는 동안, 테이블은 리드록(read rock)으로 잠김
MyISAM, BDB, InnoDB 테이블에서 지원됨

32
repair table `table name`
repair table 은 손상된 테이블을 복구
데이터를 잃어버릴 수 있음 ( 실행 전 백업 필요 )
repair table 명령어는 MyISAM, ARCHIVE, CSV engine 에서만 적용

MySQL Replication

34
MySQL Replication - 소개
Replication 소개
Replication = 복제
물리적으로 다른 서버의 저장 공간 안에 동일한 데이터를 복사
Replication은 데이터를 이중화 (Oracle RAC는 DB를 이중화하는 개념)
정의
비동기 방식 ( async )
종류
반 비동기 방식 ( semi-async )

35
MySQL Replication
Replication은 로그 기반으로 비동기적으로 데이터를 복제
데이터 변경 작업이 수행되면 Binary Log라는 곳에 이력을 기록
Statement, Row, Mixed 세 가지 방식
복제 방법
Statement-based Type
•MySQL 3.23 이후로 도입된 방식
•실행된 SQL을 그대로 Binary Log에 기록
•Binary Log 사이즈는 작으나, SQL 에 따라 결과가 달라질 수 있음
•(Time Function, UUID, User Defined Function)
Row-based Type
•MySQL 5.1부터 도입된 방식
•변경된 행을 BASE64로 Encoding하여 Binary Log에 기록
•특정 SQL이 변경하는 행 수가 많은 경우 Binary Log 사이즈가 비약적으로 커질 수 있음
Mixed Type (Statement + Row) – default
•기본적으로 Statement-Based Type으로 기록되나, 경우에 따라 Row-base Type으로 Binary Log에 기록

36
MySQL Replication
async 복제 방법 설명
Master
1. Commit write
2. Update binlog
3. Update storage
5. copy log
4. done
6. Apply update
slave
1.Application 에서 query commit 하면
2.Binlog에 기록되고
3.데이터/엔진에 적용
4.Application에게 결과리턴
5.마스터의 binlog 를 슬레이브에 전달
6.슬레이브는 전달 받은 로그를 기준으로 업데이트

37
MySQL Replication
semi-async 복제 방법 설명
Master
1. Commit write
3. Update storage
4. copy log
6. done
7. Apply update
slave
1.Application 에서 query commit 하면
2.Binlog에 기록되고
3.데이터/엔진에 적용
4.마스터의 binlog 를 슬레이브에 전달
5.마스터에게 로그 전달 확인
6.Application에게 결과리턴
7.슬레이브는 전달 받은 로그를 기준으로 업데이트
2. Update binlog
5. ack

38
MySQL Replication
마스터 -> 슬레이브 ( master – slave *n )
마스터 <-> 마스터 ( master – master )
마스터 -> 슬레이브 -> 슬레이브 ( master – slave *n - slave *n )
구성 방법에 따라 다양함
구성

39
MySQL Replication
Replication 구성 방법
…
…
> select * from mysql.user where Repl_slave_priv = 'Y'
Replication check

40
MySQL Replication
Master
Slave
마스터 데이터 백업 슬레이브에 마스터 백업 데이터 입력 동기화를 위해 슬레이브에 마스터 정보입력 슬레이브 동기화 시작 마스터/슬레이브 상태 확인
1
2
3
4
5
Async Replication 설정 순서
1
2
3
Change master to …
4
5

41
MySQL Replication
> mysqldump -uroot -p --master-data=2 --all-databases --single-transaction > x.sql
Master Backup
•--single-transaction : dump를 하나의 트랜잭션을 이용해서 실행함 (InnoDB 스토리지 엔진을 사용하는 테이블에 대해서는 Lock없이 일관된 덤프를 받을 수 있음)
•--master-data : 이 옵션이 명시되면, dump 파일의 헤더 부분에 CHANGE MASTER TO 구문을 포함시키며, 이 구문에는 덤프 시작 시점의 Binary log 파일명과 위치 정보 및 호스트 정보를 포함하고 있다. 이 값을 1로 설정하면 CHANGE MASTER TO 구문이 실제 실행 가능한 형태로 포함되며, 2로 설정되면 SQL 코멘트 형태로 참조만 할 수 있도록 포함된다. 가끔 Binary log가 활성화되지 않은 서버에서 실행 시 에러를 유발하기도 하므로 반드시 먼저 테스트를 해볼 것을 권장한다.
> GRANT REPLICATION SLAVE ON *.* TO ‘username’@'%’ IDENTIFIED BY ‘password’;
user 생성

42
MySQL Replication
mysql> CHANGE MASTER TO MASTER_HOST='192.168.0.8', MASTER_USER='repl_user', MASTER_PORT=3306, MASTER_PASSWORD='chris##', MASTER_LOG_FILE='0.000011', MASTER_LOG_POS=120;
Set Master Info in Slave
MASTER_HOST='192.168.0.8', : master server ip
MASTER_USER='repl_user', : replication 권한을 줬던 유저 MASTER_PORT=3306, : 사용 포트 MASTER_PASSWORD='chris##', : 비밀번호
MASTER_LOG_FILE='0.000011', : 백업당시 binary log file
MASTER_LOG_POS=120 : binary file position
- Option 설명

43
MySQL Replication
Set Master Info in Slave
Binary file 과 position 위치를 확인하기 위해 백업 SQL 파일을 열어서 확인한다.

44
MySQL Replication
Slave 상태 확인

45
MySQL Replication

46
MySQL Replication
Slave sync 상태 확인
Slave process 상태 확인

47
MySQL Replication
Master sync 상태 확인
Slave sync 상태 확인

48
MySQL Replication
sync 후 상태 확인

49
MySQL Replication
sync 후 물리적 파일 상태 확인
…
auto.cnf
relay-log.info
Master.info

50
MySQL Replication
알면 유용한 팁
master-connect-retry
Deprecated
5.1.17
Command-Line Format
--master-connect-retry=#
Option-File Format
master-connect-retry
Permitted Values
Type
numeric
Default
60
PURGE { BINARY | MASTER } LOGS
> PURGE BINARY LOGS TO 'mysql-bin.010';
> PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';
RESET MASTER
Start slave;
Stop slave;

51
MySQL Replication
…
semi-async 확인
> show variables like '%semi%';

52
MySQL Replication
semi-async master 설치
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
…
semi-async plugin 설치 확인

53
MySQL Replication
semi-async 설치 후 상태 확인
connect slave count
semi-async variables 확인

54
MySQL Replication
semi-async slave 설치
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
…
semi-async plugin 설치 확인

55
MySQL Replication
semi-async 설치 후 상태 확인
semi-async variables 확인

56
MySQL Replication
semi-async master 기동 시키기
> SET GLOBAL rpl_semi_sync_master_enabled = 1;
semi-async master 기동 상태

57
MySQL Replication
semi-async slave 기동 시키기
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
semi-async slave 기동 상태

58
MySQL Replication
start slave;
Slave 상태 확인 Slave start 상태 및 시스템 변수 확인
2
3
1
1
2
3
3

59
MySQL Replication
•STOP SLAVE IO_THREAD;
•START SLAVE IO_THREAD;
명령어를 이용하여 컨트롤 가능

60
MySQL Replication
마스터에 연결된 slave count
마스터에 연결된 slave

MariaDB/Percona Cluster

62
MariaDB/Percona Cluster Galera Cluster는 MariaDB의 Synchronous 방식으로 동작하는 다중 마스터 클러스터
Galera 라이브러리를 사용하여 노드간 데이터 복제를 수행
MariaDB
Galera Lib
MariaDB
Galera Lib
MariaDB
MariaDB
MariaDB
MariaDB
MariaDB
Users
Users
Users
Users
Galera Library를 이용한 동기화
Users
Cluster Overview

63
MariaDB/Percona Cluster - History

64
MariaDB/Percona Cluster - 특징 및 장점
특징
Synchronous 방식으로 노드 간 데이터 복제
Active-Active 방식의 다중 마스터 구성 - 모든 노드에서 읽기/쓰기가 가능
클러스터 내 노드 자동 컨트롤 – 특정 노드 장애 시 자동으로 해당 노드 제거
자동으로 신규 노드 추가
완벽한 병렬적으로 데이터를 행 단위로 복제
기존의 MySQL 클라이언트 방식으로 동작

65
특징
미들웨어 없이 바로 연결

66
특징
읽기 및 쓰기에 대한 확장성

67
특징
병렬 복제
•1~512 노드 연결 가능
•시작과 동시에 연결

68
MariaDB/Percona Cluster - 한계점
장점 ( 전통방식 대비 )
마스터/슬레이브간 데이터 동기화 지연 없음
노드 간 유실되는 트랜잭션이 없음
읽기/쓰기 모두 확장이 가능
클라이언트의 대기 시간이 줄어듦 – 데이터는 로컬 노드에 존재 전통방식에 비해 장점이 있으나 한계점은 존재
한계점
신규 노드 추가 시 부하 발생 – 신규 노드 추가 시 모든 데이터를 복사해야 함
효과적인 쓰기 확장 솔루션에는 한계 – 서버 간 Group Communication시 트래픽 발생
모든 서버 노드에 동일한 데이터를 유지해야 함 – 저장 공간 낭비
현재 InnoDB 타입만 지원

Galera Library

70
Galera Library
Galera Library
wsrep API로 노드 간 통신 – mariadb측에서 내부적 개선
Innodb 스토리지 엔진 내부에서 Write Set을 추출, 적용
리플리케이션 엔진은 wsrep에 정의된 call/callback 함수에 따라 동작

71
Galera Library
Certification Based Replication Method
성능 저하 없이 Synchronous하게 데이터베이스 리플리케이션을 구현하기 위해 “Group Communication and Transaction Ordering techniques”이라는 새로운 방식이 고안
높은 가용성과 성능이 필요한 어플리케이션에서는 상당히 쉽고 확장 가능한 Synchronous 방식의 리플리케이션을 제공
분할된 라이브러리와 같이 동작하고, wsrep API로 동작하는 시스템이라면 어떠한 트랜잭션과도 연관되어 동작할 수 있는 구조
성능 저하 없이 Synchronous하게 데이터베이스 리플리케이션을 구현하기 위해 “Group Communication and Transaction Ordering techniques”이라는 새로운 방식이 고안
높은 가용성과 성능이 필요한 어플리케이션에서는 상당히 쉽고 확장 가능한 Synchronous 방식의 리플리케이션을 제공

72
Galera Library
Galera Replication implementation
가장 큰 특징은 트랜잭션이 커밋 되는 시점에 다른 노드에 유효한 트랜잭션인지 여부를 체크하는 방식으로 동작
트랜잭션은 모든 서버에 동시에 반영되거나 전부 반영되지 않는 경우 둘 중 하나
트랜잭션 커밋이 가능한 여부는 네트워크를 통해서 다른 노드와의 통신에서 결정
커밋 시 커밋 요청에 대한 응답 시간이 존재
커밋 요청의 응답 시간에 대한 영향 요소
네트워크 왕복 시간
타 노드에서 유효성 체크 시간
각 노드에서 데이터 반영 시간

Galera Library 동작 방법

74
Galera Cluster 데이터 복제
트랜잭션이 커밋 되는 시점에 다른 노드에 유효한 트랜잭션인지 여부를 체크하는 방식으로 동작
트랜잭션 커밋이 가능한 여부는 네트워크를 통해서 다른 노드와의 통신에서 결정
커밋 되는 시점에 노드 간 트랜잭션 유효성 체크
커밋 되는 시점에 마스터 노드에서 슬레이브 노드에 이벤트 전송. 그리고 슬레이브 노드에서 유효성 체크 후 데이터를 정상적으로 반영하게 되면 실제 마스터 노드에서 커밋 완료. 그렇지 않은 경우는 롤백 처리

75
Node Provisioning
Active cluster
Joining node

76

77

78

79
MariaDB/Percona Cluster – 구성
Liner Cluster 구성
##############################################################################
# galera options
##############################################################################
# Path to Galera library
wsrep_cluster_address=gcomm://
wsrep_cluster_name=office
wsrep_node_name=node-001
# wsrep_node_address=192.168.123.10
wsrep_provider='/home/percona/lib64/libgalera_smm.so'
wsrep_provider_options='gcache.size=1G;'
wsrep_slave_threads=8
wsrep_sst_method=rsync
wsrep_sst_auth='root:'
wsrep_retry_autocommit=1
wsrep_convert_LOCK_to_trx=1
wsrep_certify_nonPK=1
##############################################################################
# query_cache_size = 1M
# query_cache_limit = 32M
master my.cnf 설정
seed node

80
############################################################################## # galera options ############################################################################## # Path to Galera library wsrep_cluster_address=gcomm://192.168.0.8 # wsrep_cluster_address=gcomm:// wsrep_cluster_name=office wsrep_node_name=node-002 wsrep_provider_options='gcache.size=1G;' wsrep_slave_threads=8 wsrep_sst_method=rsync wsrep_sst_receive_address=192.168.0.8 wsrep_sst_auth='root:' wsrep_retry_autocommit=1 wsrep_convert_LOCK_to_trx=1 wsrep_certify_nonPK=1 ############################################################################## # query_cache_size = 1M # query_cache_limit = 32M
slave my.cnf 설정
Slave/joinner node

81
구성확인
자신의 address
non PK ON
Node name

82
구성확인
Node name
Cash 정보
Doner 정보

83
base_host = 192.168.0.8; base_port = 4567; cert.log_conflicts = no; evs.causal_keepalive_period = PT1S; evs.debug_log_mask = 0x1; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.info_log_mask = 0; evs.install_timeout = PT15S; evs.join_retrans_period = PT1S; evs.keepalive_period = PT1S; evs.max_install_timeouts = 1; evs.send_window = 4;
Variable_name: wsrep_provider_options (master)
evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.use_aggregate = true; evs.user_send_window = 2; evs.version = 0; evs.view_forget_timeout = PT5M; gcache.dir = /home/percona/data/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /home/percona/data//galera.cache; gcache.page_size = 128M; gcache.size = 1G; gcs.fc_debug = 0;

84
ist.recv_addr = 192.168.0.8; pc.checksum = false; pc.ignore_quorum = false; pc.ignore_sb = false; pc.linger = PT20S; pc.npvo = false; pc.version = 0; pc.weight = 1; protonet.backend = asio; protonet.version = 0; replicator.causal_read_timeout = PT30S; replicator.commit_order = 3
Variable_name: wsrep_provider_options (master)
gcs.fc_factor = 1; gcs.fc_limit = 16; gcs.fc_master_slave = NO; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = NO; gmcast.listen_addr = tcp://0.0.0.0:4567; gmcast.mcast_addr = ; gmcast.mcast_ttl = 1; gmcast.peer_timeout = PT3S; gmcast.time_wait = PT5S; gmcast.version = 0;

85
파일 정보
Node 연결 정보
galera 상태 정보

86
연결 확인
Error.log 를 확인해보면 연결상태를 확인할 수 있다

87
연결 확인
Master 상태 정보
joiner 상태 정보

88
튜닝 옵션
wsrep_sst_receive_address wsrep_sst_method wsrep_sst_auth wsrep_slave_threads wsrep_retry_autocommit wsrep_provider_options wsrep_recover wsrep_provider wsrep_node_name wsrep_node_incoming_address
wsrep_node_address wsrep_mysql_replication_bundle wsrep_max_ws_size wsrep_max_ws_rows wsrep_convert_LOCK_to_trx wsrep_cluster_address wsrep_certify_nonPK wsrep_auto_increment_control
http://www.percona.com/doc/percona-xtradb-cluster/5.5/wsrep-system-index.html
Option

89
OPEN SHARE CONTRIBUTE ADOPT REUSE

[오픈소스컨설팅]Day #2 MySQL Tuning, Replication, Cluster

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to [오픈소스컨설팅]Day #2 MySQL Tuning, Replication, Cluster

Similar to [오픈소스컨설팅]Day #2 MySQL Tuning, Replication, Cluster (10)

More from Ji-Woong Choi

More from Ji-Woong Choi (20)

[오픈소스컨설팅]Day #2 MySQL Tuning, Replication, Cluster