[MySQL] Online Alter에도 헛점은 있더구나 – gdb, mysqld-debug 활용 사례

Overview

MySQL에서도 5.6부터는 온라인 Alter 기능이 상당부분 제공되기 시작했습니다. 인덱스과 칼럼 추가/삭제 뿐만 아니라, varchar 경우에는 부분적으로 칼럼 확장이 서비스 중단없이 가능한 것이죠. 물론 오라클 유저들에게는 당연한 오퍼레이션들이, MySQL에서는 두손들고 운동장 20바퀴 돌 정도로 기뻐할만한 기능들입니다. 물론, 대부분의 DDL을 테이블 잠금을 걸고 수행하던 5.5 시절에도 online alter를 위해 트리거 기반의 pt-online-schema-change 툴을 많이들 사용했었기에.. 서비스 중단이 반드시 필요하지는 않았지만요. (https://gywn.net/2017/08/small-talk-pt-osc/)

아무튼 이렇게 online alter가 대거 지원하는 상황 속에서, MySQL의 메뉴얼과는 다르게 잘못 동작하는 부분이 있었는데, 이 원인을 찾아내기 위해서는 MySQL 내부적으로 어떻게 동작을 하는지 알아내기 위해 며칠 우물을 신나게 파보았습니다.

오늘 블로그에서는 지난 일주일간의 삽질에 대해서 공유를 해보고자 합니다.

VARCHAR size extension

MySQL에서 데이터의 타입이 변경되는 경우에는 테이블 잠금을 잡은 상태에서 데이터 리빌딩을 하기 마련이지만.. VARCHAR 타입의 경우에는 조금 다르게 동작을 합니다. VARCHAR 칼럼에는 데이터의 사이즈(바이트)를 알려주는 Padding 값이 포함되어 있는데, 매뉴얼 상으로는 패딩의 바이트 수가 동일한 경우에는 테이블 메타 정보만 수정함으로써 Online Alter 가 진행되는 것이죠.

The number of length bytes required by a VARCHAR column must remain the same. For VARCHAR columns of 0 to 255 bytes in size, one length byte is required to encode the value. For VARCHAR columns of 256 bytes in size or more, two length bytes are required. As a result, in-place ALTER TABLE only supports increasing VARCHAR column size from 0 to 255 bytes, or from 256 bytes to a greater size. In-place ALTER TABLE does not support increasing the size of a VARCHAR column from less than 256 bytes to a size equal to or greater than 256 bytes. In this case, the number of required length bytes changes from 1 to 2, which is only supported by a table copy (ALGORITHM=COPY)

출처 : https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html

바이트 단위로 계산이 되기 때문에, 글자수로 기록이 되는 VARCHAR 타입 입장에서는 캐릭터셋에 따라 글자 수 구간이 달라집니다. 예를 들어 2바이트를 차지하는 euckr인 경우, 1~127글자 구간과 128이상 구간으로 나누어볼 수 있을 것이고, 4바이트 utf8 캐릭터셋인 utf8mb4 경우에는 1~63글자 구간 그리고 64이상 구간으로 그룹을 지어볼 수 있겠습니다.

간단하게 예를 들어보겠습니다. 우선 하단과 같이 테이블을 만들어보고..

CREATE TABLE `test` (
  `a` varchar(8) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

알고리즘을 명시적으로 줘서 테스트를 해보면.. 우선 VARCHAR(8) -> VARCHAR(16) 사이즈 확장은 큰 문제 없이 잘 동작을 합니다. (둘다 바이트 수가 255 이하이므로, 동일 패딩 1바이트입니다.)

mysql> alter table test modify a varchar(16), algorithm=inplace;
Query OK, 0 rows affected (0.04 sec)

그러나 63글자를 넘어서 255사이즈로 inplace 알고리즘(online alter)으로 칼럼을 확장하고자 하면, 아래와 같이 에러를 뱉습니다. 에러 메시지를 존중하여, 알고리즘을 COPY로 지정을 해야 “테이블 잠금”을 품고 “데이터 재구성”하는 과정을 거쳐 비로서 정상적으로 칼럼 확장이 마무리되죠. (둘다 바이트 수가 256 이상이므로, 동일 패딩 2바이트입니다.)

mysql> alter table test modify a varchar(255), algorithm=inplace;
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.

mysql> alter table test modify a varchar(255), algorithm=copy;
Query OK, 1 row affected (0.03 sec)

매뉴얼 내용은 제대로 각인되었을 것으로 간주하고.. 이제 오늘 이야기하고자 하는 주제로 넘어가겠습니다.

Indexed Column Extension

그렇습니다. 이야기대로라면, Padding 조건에 맞는 칼럼이 경우에는 무중단, 리빌딩 없이 순식간에 칼럼 사이즈가 확장되어야 하는 것이 정석이건만.. 인덱스를 품은 VARCHAR칼럼인 경우에는 그렇지가 않았습니다. 위에서 테스트로 간단하게 생성을 했었던 테이블 기준으로 테스트 케이스를 만들어서 확인해보겠습니다.

CREATE TABLE `test` (
  `a` varchar(8) DEFAULT NULL,
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

mysql> insert into test select left(uuid(),8);

## 20회 수행
mysql> insert into test select left(uuid(),8) from test;

mysql> select count(*) from test;
+----------+
| count(*) |
+----------+
|  1048576 |
+----------+

확실한 차이를 보이기 위해서, 우선 인덱스가 없는 현재 상황에서 VARCHAR(8) -> VARCHAR(16)으로 사이즈를 확장해서 0.02초에 백만건 넘는 데이터의 칼럼 사이즈가 바로 확장이 되는 것을 보이겠습니다.

mysql> alter table test modify a varchar(16), algorithm=inplace;
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

이 상태에서 인덱스를 하나 추가하고 앞과 비슷하게 VARCHAR(16) -> VARCHAR(17)로 확장을 시도해보았는데.. 바로 완료가 될 것이라는 기대와는 다르게.. 초단위로 DDL이 수행되었습니다.

mysql> alter table test add key ix_a_1(a);
Query OK, 0 rows affected (1.55 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> alter table test modify a varchar(17), algorithm=inplace;
Query OK, 0 rows affected (1.64 sec)
Records: 0  Duplicates: 0  Warnings: 0

여기에 추가로 인덱스를 하나 더 생성을 해서 VARCHAR(17) -> VARCHAR(18)로 칼럼을 확장을 해보니 인덱스 한개 대비 대략 두배 정도의 시간이 더 소요된 것을 확인할 수 있겠죠.

mysql> alter table test add key ix_a_2(a);
Query OK, 0 rows affected, 1 warning (4.43 sec)
Records: 0  Duplicates: 0  Warnings: 1

mysql> alter table test modify a varchar(18), algorithm=inplace;
Query OK, 0 rows affected (3.24 sec)
Records: 0  Duplicates: 0  Warnings: 0

참고로, 이 alter 구문의 프로파일링은 하단과 같으며.. “altering table” 단계에서 병목이 걸려있습니다. 무언가 내부적으로 이상한 짓을 하고 있는 것이죠. ㅎㅎ 이 당시 상황에서 performance_schema.metadata_locks을 확인해볼 수 있다면 약간의 정보를 더 얻을 수 있겠지만.. 대세에 큰 영향은 없습니다. ㅠㅠ 정보가 너무 부족합니다.

+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000069 |
| checking permissions           | 0.000007 |
| checking permissions           | 0.000005 |
| init                           | 0.000006 |
| Opening tables                 | 0.000297 |
| setup                          | 0.000019 |
| creating table                 | 0.009754 |
| After create                   | 0.000255 |
| System lock                    | 0.000012 |
| preparing for alter table      | 0.000275 |
| altering table                 | 2.993340 |
| committing alter table to stor | 0.014045 |
| end                            | 0.000056 |
| query end                      | 0.000336 |
| closing tables                 | 0.000024 |
| freeing items                  | 0.000041 |
| cleaning up                    | 0.000062 |
+--------------------------------+----------+

참고로 이 상황에서 서비스 쿼리가 중단되거나 하지는 않아요. 그냥 내부적으로 InnoDB Buffer Pool I/O가 늘어났을 뿐 서비스 쿼리는 큰 문제가 없습니다. 문제는 DDL 구문이 오래걸리는 상황이라면, 자연스럽게 “복제 지연”으로 이어질 수 있다는 점인데요. ALTER구문은 데이터를 담고 있는 “그릇”이 변경되는 의미하는 것이기 때문에.. 데이터를 복제하는 슬레이브 입장에서는 DDL 구문 이후에 변경된 그릇 기준으로 생성되는 DML 쿼리를 처리할 수 있습니다.

생각을 해보세요. 1000만건 테이블의 특정 VARCHAR칼럼에 5개 이상의 인덱스가 관여하고 있다면..?? 생각보다 슬레이브 지연 영향도는 심각할 수 있겠죠.

즉, 순식간에 종료될 것이라 생각했던 Online Alter 구문이 슬레이브 복제 지연에 영향을 줄 수 있다는 점이죠.

Replication-Delay

만약 슬레이브 서버들이 어떤 형태로든 서비스에 관여를 하고 있다면.. 이 상황에서 복제 지연 현상은 데이터를 관리하는 데이터쟁이 입장에서는 그다지 듣기좋은 이야기는 아닙니다.

자~ 그렇다면, 도대체 이 현상은 왜 발생했을까요? 다행히 이 이슈 분석을 위해 “인덱스 있는 VARCHAR 칼럼”이라는 중요한 재현 시나리오는 마련이 되어있군요. 만약 재현이 어려운 상황이라면.. 분석이 정말 난해한 상황이었을 것입니다. ㅋㅋ

Debugging with gdb

우선 멈춰있는 이 상황에서, MySQL이 내부적으로 어떤짓을 하고 있는지 디버깅을 해봅시다. 알수 없는 무언가를 하고 있는가를 확인해봐야겠죠. 위에서 MySQL이 무언가 알수 없는 것을 처리하는 상황에서 gdb로 아래와 같이 트레이스를 떠봅니다.

$ gdb -ex "set pagination 0" \
      -ex "thread apply all bt" \
      -batch -p `pidof mysqld` > result.out

이렇게하면 외계 문자들이 쭈르륵 떨어질 것인데.. 이중 OS의 쓰레드 아이디 기준으로 나온 결과를 보고 현재 이 쓰레드에서 무슨 짓을 하고 있는지 추적을 해봅니다. 참고로, mysql 프로세스 아이디 기준으로 OS 쓰레드 아이디는 아래와 같이 threads 테이블에서 알아낼 수 있어요.

mysql> select thread_id_os from performance_schema.threads
    -> where processlist_id = <프로세스아이디>;

만약 OS의 쓰레드 아이디가 8이었다면.. 이 쓰레드 번호로 검색을 해보면.. 지금 어떤일을 하고있는지 적나라하게 확인할 수 있겠죠. 참고로 여기서는 인덱스 리빌딩(row_merge_build_indexes) 관련하여 무슨 짓을 하고 있는 것으로 보여지네요. ㅎ (외계어기는 하지만.. 동일 버전의 소스를 다운받아서 위치를 따라가보면, 대략 무슨 짓을 하고 있는지 이해할 수 있을 듯..)

$ vi result.out
.. 중략 ..
Thread 8 (Thread 0x7ff8790c3700 (LWP 31032)):
#0  0x0104ed22 in row_merge_blocks .. storage/innobase/row/row0merge.cc:2784
#1  row_merge .. storage/innobase/row/row0merge.cc:2957
#2  row_merge_sort .. storage/innobase/row/row0merge.cc:3077
#3  0x01056454 in row_merge_build_indexes .. storage/innobase/row/row0merge.cc:4550
#4  0x00f902da in ha_innobase::inplace_alter_table .. innobase/handler/handler0alter.cc:6314
#5  0x007619ec in ha_inplace_alter_table .. sql/handler.h:3604
.. 중략 ..
#15 0xf9c07aa1 in start_thread () from /lib64/libpthread.so.0
#16 0xf98e8aad in clone () from /lib64/libc.so.6

Debugging with mysqld-debug

앞서 의심을 했었던, 인덱스 관련된 무슨 짓꺼리를 하고 있을 것이다라는 심증은 확신으로 바뀌면서.. 이제 조금더 상세하게 디버깅해보도록 하죠. 이번에는 mysqld-debug로 이 작업을 해보도록 하겠습니다.

$ mysqld-debug --debug=d,info,error,query,general,where:O,/tmp/mysqld.trace

참고: https://dev.mysql.com/doc/refman/5.7/en/making-trace-files.html

괘나 많은 로그가 떨어지겠지만.. 인덱스 있는 케이스와 없는 케이스 두 개로 나누어서 트레이스를 떠보면.. 대충 칼럼 사이즈 변경 시 fill_alter_inplace_info 함수 부분에서 리빌딩할 인덱스 리스트를 선별할 것 같은 우주의 기운이 팍팍 느껴지기 시작합니다. 왠지.. 동일 패딩 사이즈 경우 메타 정보를 수정해서 순식간에 ALTER 작업이 이루어지는 것처럼, 인덱스 리빌딩 단계에서 이 케이스를 선별해서 빼버린다면..?? 이런 병목은 사라질 것 같은 예감이 듭니다.

## 인덱스 없는 경우 ##
mysql_create_frm: info: wrote format section, length: 10
fill_alter_inplace_info: info: index count old: 0  new: 0

## 인덱스 있는 경우
fill_alter_inplace_info: info: index count old: 2  new: 2
fill_alter_inplace_info: info: index changed: 'ix_a_1'
fill_alter_inplace_info: info: index changed: 'ix_b_2'

다행히 이 문제는 MySQL 5.7.23 버전에서 픽스가 되었습니다. 소스를 살펴보고자, Oracle MySQL의 깃헙에 들어가서 살펴보던 중 왠지 우리와 비슷한 상황일 것 같은 커밋 코멘트(BUG#26848813: INDEXED COLUMN CAN’T BE CHANGED FROM VARCHAR(15))를 발견하였고, 대충 훑어보니 역시나 인덱스 리빌딩 케이스였더군요. (이렇게 절묘하게.. 손 안대고 코풀줄이야.. ㅋㅋ)
참고: https://github.com/…/913071c0b16cc03e703308250d795bc381627e37

5.7.23 버전에 online alter 플래그 중 “Alter_inplace_info::RENAME_INDEX” 비트 플래그를 하나 더 추가하였고, varchar 칼럼 확장이면서 패딩 사이즈가 동일하면 “Alter_inplace_info::RENAME_INDEX” 로 분기 분류함으로써 인덱스를 리빌딩하지 않도록 제어하더군요. (부분부분 발췌합니다.)

## fill_alter_inplace_info 함수 ###########
static bool fill_alter_inplace_info(THD *thd,
                                    TABLE *table,
                                    bool varchar,
                                    Alter_inplace_info *ha_alter_info)
{
  ....
  while ((rename_key= rename_key_it++))
  {
    ....
    if (! has_index_def_changed(ha_alter_info, table_key, new_key))
    {
      /* Key was not modified but still was renamed. */
      ha_alter_info->handler_flags|= Alter_inplace_info::RENAME_INDEX;
      ha_alter_info->add_renamed_key(table_key, new_key);
    }
    else
    {
      /* Key was modified. */
      ha_alter_info->add_modified_key(table_key, new_key); 
    }
    ....
  }
  ....
}

## has_index_def_changed 함수 ###########
static bool has_index_def_changed(Alter_inplace_info *ha_alter_info,
                                  const KEY *table_key,
                                  const KEY *new_key)
{
    ....
    if (key_part->length != new_part->length &&
        ha_alter_info->alter_info->flags == Alter_info::ALTER_CHANGE_COLUMN &&
        (key_part->field->is_equal((Create_field *)new_field) == IS_EQUAL_PACK_LENGTH))
    {
      ha_alter_info->handler_flags|=
          Alter_inplace_info::ALTER_COLUMN_INDEX_LENGTH;
    }
    else if (key_part->length != new_part->length)
      return true;
    ....
}

아무튼 5.7.23에서는 이 코드 적용 결과.. 인덱스가 있을지라도 VARCHAR 칼럼 확장은 순식간에 바로 종료가 되는 쾌거를 이룹니다. 아직 5.7.23 이전 버전을 쓰고 계신 분들이 버전을 업그레이드 해야하는 또하나의 이유가 생겼네요. ㅋㅋ

Conclusion

길고 긴.. 오늘 블로그 정리를 해보겠습니다. 그냥 이 세가지 이야기로 정리해보겠습니다.

  1. MySQL5.7.23 버전 이상으로 업그레이드 하는 것이 정신 건강에 좋다.
  2. MySQL5.7.23 이전 버전 사용자들은, 칼럼에 인덱스가 걸려있는지 확인을 우선 해보고 작업 계획을 세운다.
  3. 무엇보다 매뉴얼은 매뉴얼일뿐, 맹신하지 말자.

무엇보다 가장 알고 싶었던 부분은.. 매뉴얼과 전혀 다른 이 현상이 어디부터 시작된 이슈인지를 원인분석입니다. 이것을 알아야 이는 사이드이펙트를 최소화할 수 있는 우회방안도 고민해볼 수 있기 때문이죠. 피할 수 없으면 즐겨야할테니.. 맞더라도 이유는 알고 맞아야할 것이고.. 궁시렁궁시렁

저같은 C알못 평범남도 파보니 이해는 할 수 있겠드라고요. 엯촋들에게는 평범한 일상이겠지만.. 저같은 보통 사람들에게는 신성한 경험이었기에, 이를 공유 삼아 블로그 포스팅을 해봅니다.

아주 오랜만의 길고 긴 대하 소설.. 마칩니다. ㅋㅋ

PowerDNS와 MySQL로 DNS를 해보고 싶어요~

Overview

PowerDNS란 범용적(?)으로 사용되는 오픈소스 기반의 DNS서버이고, 다양한 백엔드를 지원하는 멋진(?) DNS 이기도 합니다. 얼마전, 이 관련되어 간단한 사례에 대해 세미나를 진행을 하였고, 이 구성에 대한 설명이 미흡하여 간단하게 정리해봅니다. ^^

Install PowerDNS

CentOS 6.7 버전에서 구성을 하였고, 실제 설치 작업에는 아래와 같이 같단합니다.
(참고 : https://doc.powerdns.com/md/authoritative/installation/#binary-packages)

$ yum install pdns
$ yum install pdns-backend-mysql

(단, 여기서 MySQL 은 이미 구성되어 있다는 가정하에 진행합니다.)

Configuration

자~ 이제 DNS 데몬을 설치하였으니..(두줄에.. 끝? -_-;; 헐~)

이제,설정을 해보도록 합시다~ 먼저.. MySQL의 계정 및 스키마를 생성을 해보고..

$ mysql -uroot -p << EOF
  create database pdns_production;
  grant all on pdns_production.* to pdns@127.0.0.1 identified by 'pdns';
EOF

DNS 서버에서 사용할 스키마를 아래와 같이 생성을 합니다. 귀찮으니.. 그냥 콘솔 쉘에서 할 수 있도록.. 아래와 같이.. ㅋㅋ

$ mysql -uroot -p pdns_production << EOF
create table domains (
 id int auto_increment,
 name varchar(255) not null,
 master varchar(128) default null,
 last_check int default null,
 type varchar(6) not null,
 notified_serial int default null,
 account varchar(40) default null,
 primary key (id)
) engine=innodb;

create unique index name_index on domains(name);

create table records (
 id int auto_increment,
 domain_id int default null,
 name varchar(255) default null,
 type varchar(10) default null,
 content text default null,
 ttl int default null,
 prio int default null,
 change_date int default null,
 disabled tinyint(1) default 0,
 ordername varchar(255) binary default null,
 auth tinyint(1) default 1,
 primary key (id)
) engine=innodb;

create index nametype_index on records(name,type);
create index domain_id on records(domain_id);
create index recordorder on records (domain_id, ordername);

create table supermasters (
 ip varchar(64) not null,
 nameserver varchar(255) not null,
 account varchar(40) not null,
 primary key (ip, nameserver)
) engine=innodb;

create table comments (
 id int auto_increment,
 domain_id int not null,
 name varchar(255) not null,
 type varchar(10) not null,
 modified_at int not null,
 account varchar(40) not null,
 comment text not null,
 primary key (id)
) engine=innodb;

create index comments_domain_id_idx on comments (domain_id);
create index comments_name_type_idx on comments (name, type);
create index comments_order_idx on comments (domain_id, modified_at);

create table domainmetadata (
 id int auto_increment,
 domain_id int not null,
 kind varchar(32),
 content text,
 primary key (id)
) engine=innodb;

create index domainmetadata_idx on domainmetadata (domain_id, kind);

create table cryptokeys (
 id int auto_increment,
 domain_id int not null,
 flags int not null,
 active bool,
 content text,
 primary key(id)
) engine=innodb;

create index domainidindex on cryptokeys(domain_id);

create table tsigkeys (
 id int auto_increment,
 name varchar(255),
 algorithm varchar(50),
 secret varchar(255),
 primary key (id)
) engine=innodb;
create unique index namealgoindex on tsigkeys(name, algorithm);
EOF

pdns 설정 파일을 열어서.. 기본적으로  파일 기반인 BIND로 설정되어 있는 부분을 주석처리하고 MySQL접속 정보를 넣어줍니다. 위에서 계정 생성을 127.0.0.1로 접근 호스트를 생성하였으니.. 패스워드는 간단하게 설정하였습니다. (다른곳에서는 접근이 불가할테니요. ^^)

$ vi /etc/pdns/pdns.conf
#setuid=pdns
#setgid=pdns
#launch=bind

launch=gmysql
gmysql-host=127.0.0.1
gmysql-user=pdns
gmysql-password=pdns
gmysql-dbname=pdns_production

관리 서버를 올리고 싶다면.. 아래와 같이 pdns.conf에서 웹서버 부분을 변경 설정하여 올립니다. (여기서는 쿼리로만 추가 변경 테스트를 할테니, 굳이 필수 요소는 아닙니다. ^^)

webserver=yes
webserver-address=0.0.0.0
webserver-port=8081
$ /etc/init.d/pdns start

이 모든 과정은.. 하단 메뉴얼에 친절하게 잘 명시되어 있고.. 제 입맛에 맞게 편집을 하였습니다. ㅋㅋ

참고 : https://doc.powerdns.com/md/authoritative/howtos/#basic-setup-configuring-database-connectivity

DNS Test with SQL

먼저 아래와 같이 없는 DNS질의를 해보면 전혀~ 도메인에 대한 정보가 보여지지 않습니다.

$ dig +short aaa.db.io @127.0.0.1

이제 테스트를 위해 아래 쿼리를 밀어넣어줍니다. (참고로, 테이블에는 데이터가 전~혀 없다는 가정으로 테스트합니다.) 여기서 중요한 것은 SOA 는 필수입니다. 도메인의 영역을 표시할 뿐만 아니라, 어떻게 관리되어야할 지를 알려주는 도메인 Zone 개념을 내포하기 때문이죠.

저에게 중요한 것은 TTL이 0인 A타입의 도메인이기에.. A레코드인 경우는 TTL을 0으로 지정하여 넣어줍니다.

INSERT INTO domains (name, type) values ('db.io', 'NATIVE');
INSERT INTO records (domain_id, name, content, type,ttl,prio) VALUES
(1,'db.io','admin.db.io','SOA',86400,NULL),
(1,'aaa.db.io','192.0.0.1','A',0,NULL),
(1,'bbb.db.io','192.0.0.2','A',0,NULL),
(1,'ccc.db.io','192.0.0.3','A',0,NULL);

자. 아까 질의했던 도메인을 다시 확인해볼까요? 조금전에 DB에 밀어넣은 IP를 알려줍니다.

$ dig +short aaa.db.io @127.0.0.1
192.0.0.1

조금 더 자세하게.. 하단과 같이 질의를 해보면, TTL(ANSWER SECTION) 또한 0으로 잘~ 세팅되어 있다는 것도 확인할 수 있지요.

 $ dig aaa.db.io @127.0.0.1

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6 <<>> aaa.db.io @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21973
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;aaa.db.io. IN A

;; ANSWER SECTION:
aaa.db.io. 0 IN A 192.0.0.1

;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 17 22:09:03 2017
;; MSG SIZE rcvd: 43

이제 쿼리로 도메인의 아이피를 바꿔볼까요?

$ mysql -uroot -p pdns_production << EOF
 update records set content = '192.0.0.4' where name = 'aaa.db.io'
EOF

쿼리 실행 후 DNS 질의를 해보면.. 바로 변경된 아이피를 확인할 수 있습니다.

$ dig +short aaa.db.io @127.0.0.1
192.0.0.4

이 내용 또한 앞선 매뉴얼의 테스트 내용을 약간 제 입맛에 맞게 살을 붙여서 만들어보았습니다.^^

Conclusion

여전히 대부분의 DNS는 BIND기반으로 동작하고 있고.. 안정성 또한 입증된 방식이기도 하죠.

그렇지만 MySQL 을 백엔드로 가지는 PowerDNS는 DB가 가지는 강점.. 예를 들면 데이터 처리 및 보안 등등 BIND에서 가져갈 수 없는 강점을 가지기도 하지요. 이를테면.. 존 추가 이후에 서버 재시작이 필요없다거나.. 파일이 아닌 DNS쿼리 하나하나의 ROW Level Locking.. 트랜잭션 등등~~

이 포스팅에서는 간단하게.. 테스트를 수행할 수 있는 정도의 PowerDNS with MySQL 구성 방법을 설명해 보았습니다. 좋은 사례가 있으면 앞으로도 쭉 나왔으면 합니다. ^^

감사합니다.

pt-online-schema-change에 숨겨진 무시무시한 이슈!

Overview

최근들어 거의 연단위로 블로깅을 하나씩 올리는 듯 하는군요. 여기저기 시국이 어지럽고, 바쁘다는 말도 안되는 핑계를 무마시키기 위해.. 아무튼 간만에 블로깅 하나 올려봅니다.

MySQL은.. 특히나 온라인 스키마 변경이 취약합니다. 물론 5.6부터는 online alter기능이 포함되어 있다고는 하나.. 100% 완벽하게 모든 상황을 온라인스럽게 제공해주지도 않고.. 그렇다하더라도, 일정 트래픽 이상의 데이터 변경이 이루어지는 경우, 게다가 슬레이브 지연을 염두한다면.. 꺼려지는 상황이 있지요. (참고로, 마스터에서 온라인 스키마 변경이 이루어졌을지라도, 이 관련 alter구문이 슬레이브로 넘어갔을 때는, alter이후 데이터 변경을 수행해야 하므로, 그만큼 복제 지연이 발생합니다. 미네럴~)

아무튼.. 이런저런 이유로.. 기승전툴이라는 생각이드는데요. 그중, Percona에서 오픈소스 라이선스로 제공하는 pt-toolkit에 포함된 pt-online-schema-change툴을 저는 애용합니다.

참 좋지만.. 반드시 짚고 넘어가야할 이슈 하나만은 반드시 공유할 필요가 있다는 생각이 들어, 이렇게 늦은 시간 포스팅을 합니다. 🙂

pt-online-schema-change?

문제를 말하기에 앞서서, 먼저 pt-online-schema-change의 동작 방식에 대해서 정말 간~략하게 알아볼 필요가 있겠군요.

이 툴은 서비스 중지 없이 실시간으로 테이블 DDL Alter구문을 적용할 수 있도록 도와주는 하나의 “유틸리티”이며, 흔한 RDBMS에서 제공하는 기능 몇가지와, 머리좋은 개발자의 “꼼수”가 환상적인 조합을 이루며 만들어진 멋진 툴입니다. 짝짝짝~

간단한 테이블 변경 순서는 아래와 같아요.

  1.  클론 테이블 생성 후 의도한 스키마를 적용한다.
  2.  원본 테이블 변경 시 트리거로 이를 클론 테이블에 적용한다. (replace into/delete)
  3.  조각 조각 데이터를 잘라서, 데이터를 중복은 무시한 채 복사한다. (insert ignore)
  4.  테이블 복사가 완료되면, 클론<->원본 테이블명을 스위칭한다.
pt-online-schema-change
pt-online-schema-change

Percona..당신들의 잉여력은 많은 이들을 행복하게 하였습니다. 땡큐~!!

 

Problem

물론, pt-online-schema-change도 하나의 툴인 이상.. 분명 100% 모든 상황에 적합하지는 않습니다.

뭐.. 예를 들면.. 아무래도 데이터를 조각조각 나누어서 복사를 해야하는만큼, Primary Key는 반드시 존재해야하는 상황이어야하고, Foreign Key가 정의된 경우에도 제약이 있고.. 궁시렁궁시렁..

그렇지만, 오늘 여기서 짚어보자하는 문제는.. 사실은 pt-online-schema-change가 충분히 동작할 수 있는 상황에서, 데이터가 달라질 수 있는.. 곰곰히 생각을 해보면 서비스 오류까지 발생할 수 있는 그런 상황입니다요.

pt-online-schema-change에서 앞서 설명을 간단하게 했던 것처럼, 트리거를 통해서 현재 데이터 변경된 이력을 클론 테이블(스키마 적용된 최종본 구조 테이블)로 적용합니다. 적용시 insert/update 구문 모두 아래와 같이 replace into 구문으로 대동단결 하는데요. (참고로 _test_tmp는 클론테이블입니다.)

DELIMITER $$
CREATE TRIGGER trg_test_update
AFTER UPDATE ON test
FOR EACH ROW
BEGIN
 REPLACE INTO _test_tmp VALUES (NEW.id, .., NEW.created_at);
END$$
DELIMITER ;

동일 트리거이니.. 문제삼을 update 트리거만..

멀쩡한 상황에서는 이슈가 아닙니다만.. 여기서 replace의 동작 방식을 이해하고, 조금만 고개를 갸우뚱거리면 무엇이 문제인지 이해하실 수 있을 것이예요. 귀찮으니, 매뉴얼 원문을 퍼오겠습니다. 크하하

REPLACE works exactly like INSERT, except that if an old row in the table has the same value as a new row for a PRIMARY KEY or a UNIQUE index, the old row is deleted before the new row is inserte

그렇답니다. 기존의 pk/uk와 같이 충돌나는 것들은 다 날리고.. 신규 데이터로 밀어넣는다는 것인데요. 그렇기에 pk가 없으면 대 재앙일 것이고.. 이런 부분에 대해서는 나름 pt-online-chema-change에서 제약 조건을 체크하기는 합니다. (그랬던가.. 가물가물..)

그렇다면.. 이런 경우 말고.. PK가 변경되는 상황을 생각해볼까요? 이런 상황에서도 역시 replace into 구문으로 트리거는 동작할 것이고.. 트리거 내부에는 “NEW.id, .., NEW.created_at”와 같이 변경될 데이터 기준으로 클론 테이블에 적용될 것이고.. NEW.id가 PK라면, 이 기준과 동일한 데이터를 날리고 엎어버릴 것이고..

그렇다면.. 우움.. 기준이 되는 NEW.id가 변경된 경우에는.. -_-;; 예전 OLD.id의 행방은??

딩동댕~ 맞습니다. ㅠㅠ 어이없게도.. 업데이터로 동작을 해야할 상황이.. 기준점이 변경되었다는 이유로.. 여전히 남아있는 상태가 되겠지요. 미네럴2.

즉.. 로직적인 이슈로.. 기준점이 되는 PK를 변경하는 경우 여전히 과거의 이력이 남아있게 되는.. 어이없는 상황이 발생한다는 것입니다!! <==== 주의주의1

Solutions

사실.. 해결책은 의외로 간단합니다.

PK는 업데이트 하지 말고, 트랜잭션으로 묶어서 DELETE -> INSERT 처리한다. 참 쉽죠잉~! 이것은.. 뭐.. 해결방안이라기 보다는 그냥 “우회처리”라고 해야하나.. -_-;;

그치만.. 사용자를 쿼리를 날리는 경우도 있고.. 기타 이런 상황을 인지 못하는 경우를 대비해서.. 본질적인 해결 방안이 필요합니다.

PK가 변경된 경우 트리거 내부적으로 과거 데이터를 날려주는 로직을 넣어준다.

트리거 정의하는 부분에.. PK 변경 시 OLD 이미지에 해당하는 데이터를 날리도록 강제하면 되지요. 뭐.. 아래 예시는.. 쿼리 레벨 간단하게 소스를 약간 수정한 것일뿐.. 조금 수정해서 트리거 내부에 if else 구문을 넣어도 되고..암튼 그렇답니다.

sub create_triggers {
  .. 중략 ..
  ## 추가 ##
  my $upd_index_cols = join(" AND ", map {
    my $new_col = $_;
    my $old_col = $old_col_for{$new_col} || $new_col;
    my $new_qcol = $q->quote($new_col);
    my $old_qcol = $q->quote($old_col);
    "OLD.$old_qcol <=> NEW.$new_qcol"
  } @{$tbl_struct->{keys}->{$del_index}->{cols}} );

  .. 중략 ..

  ## DELETE 부분 추가 ##
  my $update_trigger
    = "CREATE TRIGGER `${prefix}_upd` AFTER UPDATE ON $orig_tbl->{name} "
    . "FOR EACH ROW "
    . "BEGIN "
    . "DELETE IGNORE FROM $new_tbl->{name} WHERE !($upd_index_cols) AND $del_index_cols;"
    . "REPLACE INTO $new_tbl->{name} ($qcols) VALUES ($new_vals);"
    . "END ";
  .. 중략 ..
}

PK가 변경된 경우에는 데이터를 지워버리고, 그렇지 않으면.. 그냥 예전처럼 replace~ 트리거 내부적으로 update시에 쿼리는 많아지겠고, 트랜잭션이 없는 상황에서는 약간 걱정될만한 사항도 있겠지만.. 다들 기본적으로 InnoDB사용하시잖아요? ㅋㅋ

사실.. 이런 부분은 간단하게 소스를 수정해서 활용을 해도 됩니다. 어려운것도 아니고.. 잉여력이 조금 남아있다면 얼마든지 상황에 맞게 고쳐 쓸 수 있겠지요. 그치만.. 이 부분에 대해서 Percona에 문의를 해보니.. 그들의 입장은.. 번역하면 아래와 같았습니다.

어째서 PK가 변경이 되어야하는 것인가? 테이블에서 PK는 절대적이므로, 결코 업데이트 작업이 이루어지지 않아야 한다. 우리들은 이런 현상을 버그로 인정하지 않는다. – 어느 개발자 –

버그가 아니라면.. 이런 상황을 감지해서 제약을 걸든가.. 미네럴3..

사실.. 가장 경계를 해야하는 문제는.. (제 개인적인 의견이지만) 런타임 오류라고 생각합니다. 서비스 오픈 전에 발생하는 모든 이슈는 사전에 불을 끄고 튜닝하고 해결할 수 있지만.. 런타임 도중 특이 케이스에서만 노출되는 이슈는 정말로 답이 없습니다.

위와 같은 동일한 방식은 아니더라도, 적어도 PK변경 시 뒤따르는 이러한 데이터 꼬임 현상에 대한 것들은 Percona 측에서 제대로 이해하고 GE버전에 적용을 해줬으면 하는 마음이 있고.. 뭐.. 개인적으로, 조직적으로 푸시를 넣고 있습니다만..

좋은 소식이 있겠지요. ^^

Conclusion

pt-online-schema-change 툴은 굉장히 유용하고, 제가 정말 자주 쓰는 권고할만한 유틸입니다. 게다가 소스도 오픈되어 있고, 누구나 수정할 수 있는 라이선스 정책이고요.

그렇지만, 오픈소스를 사용하는만큼.. 그렇게 접근을 하기에.. 상용 솔루션과는 다르게 발생하는 이슈에 대해서 분석을 해보고 해결책을 가져가보고, 대안도 고민해보고.. 사용자 자신도 오픈소스를 사용하는 대가를 치뤄야 하겠지요. 뭐.. 제 능력으로는 지금과 같이 경험을 공유하는 것이 그나마 최선일 듯 합니다만.. ^^

올해 금융업에 뛰어들어, 오픈소스DBMS 적용을 어찌어찌 하다보니.. 예전에는 별 생각이 없이 넘어가던 가벼운 생각들도, 꽤나 진지한 주제로 제게 다가오네요.

다음 포스팅은 언제일지는 모르지만.. 시간이 될 때.. adt를 주제로 한번 읊어보는 것도 좋겠다는 생각이..

좋은 밤 되시와요~!!