gywn's tech

Vitess, 로컬에서 직접 만들어보며 이해하기

gywndi@gmail.com (gywndi) — Sun, 09 Aug 2026 23:15:14 +0900

MySQL 하나로는 데이터를 감당하기 힘들어지는 시점이 옵니다. 유튜브, 슬랙, 깃허브 같은 곳들이 이 문제를 풀 때 쓴 방법 중 하나가 Vitess입니다. Vitess가 뭘 하는 물건인지, 어떤 부품으로 이뤄져 있는지, 그 부품들을 실제로 어떻게 배치해야 하는지를 로컬 Docker 환경에 직접 만들어보면서 정리했습니다. 여기 나오는 구성은 GitHub 저장소에 그대로 올려뒀고, Docker만 있으면 그대로 따라 켤 수 있습니다.

1. Vitess가 뭔가요?

MySQL 하나로는 데이터가 너무 커지거나 쓰기 트래픽이 너무 많아지는 순간이 옵니다. 이때 흔히 쓰는 해법이 샤딩입니다. 데이터를 여러 MySQL로 쪼개서 나눠 담는 거죠. 문제는 샤딩을 직접 하면 애플리케이션 코드가 “이 데이터가 몇 번 서버에 있더라"를 일일이 알아야 해서 지저분해진다는 점입니다.

로컬 LLM 댓글 검수 — 모델 교체기

gywndi@gmail.com (gywndi) — Fri, 27 Mar 2026 22:15:02 +0900

댓글이 쌓이고 있었다

카페 방명록에 댓글이 달리면, 사람이 직접 보는 게 아니라 로컬 LLM이 먼저 검수를 합니다. 욕설인지, 광고인지, 그냥 좋은 후기인지 판단해서 자동으로 처리하는 구조예요.

https://cafepurplemint.com (깨알같은 홍보)

그런데 어느 날 로그를 보다가 이상한 걸 발견했습니다.

[MOD] Processing 5 pending entries...
[MOD] Processing 5 pending entries...
[MOD] Processing 5 pending entries...

같은 로그가 계속 찍히고 있었어요. 처리가 끝나지 않은 채로 다음 폴링이 돌고 있었습니다.

원인은 단순했습니다. 댓글 하나 검수하는 데 평균 5.6초. 폴링 주기는 1초. 수학적으로 댓글이 조금만 몰려도 처리 큐가 쌓일 수밖에 없었습니다. (사실 카페 홈페이지를 만들고. 지인 단체방에 댓글 한번 해보라고 홍보아닌 홍보를 했었죠.)

AI와 함께 카페 메뉴를 정리한 이야기

gywndi@gmail.com (gywndi) — Sat, 14 Mar 2026 22:37:02 +0900

3년 만에 홈페이지를 고쳤습니다

와이프는 현재 무인카페 주인입니다. 그리고 3년전 제가 워드프레스 기반으로 카페 홈페이지를 만들었었죠.

그 후로 거의 손을 안 댔습니다. 메뉴가 바뀌어도, 이미지가 달라져도, 홈페이지는 그냥 그 자리에 있었습니다. 관리가 번거로웠거든요. 어느 날 홈페이지를 열어봤더니, 현실과 너무 달랐습니다. 없어진 메뉴가 올라가 있고, 있는 메뉴가 빠져 있었습니다.

이건 아니다 싶었습니다. 그래 리뉴얼을 결심했습니다. (사실 작년ㅜ터..)

이번엔 쉽게 관리할 수 있는 구조로 처음부터 다시 만들기로 했습니다. 그 과정에서 AI를 적극 활용해보기로 했습니다.

Claude Code, 요구사항도 없이 코드부터 짠다고요?

gywndi@gmail.com (gywndi) — Tue, 10 Mar 2026 16:16:38 +0900

Claude Code를 쓰다 보면 생기는 문제

요즘 개발자들 사이에서 Claude Code를 사용하는 분들이 많아지고 있습니다.

Claude Code는 Anthropic이 만든 AI 코딩 도구인데요. 터미널에서 Claude에게 말로 설명하면, 실제 코드를 작성해주는 강력한 도구입니다.

그런데 이걸 써보신 분들이라면 이런 상황을 겪어보셨을 거예요.

“회원가입 기능 만들어줘.”

라고 말했을 뿐인데, Claude가 데이터베이스 설계부터 API 코드까지 주르르 짜기 시작합니다. 처음엔 “와, 빠르다!” 싶지만, 잠깐 들여다보면 내가 원하는 방향이 아닌 경우가 많습니다.

이메일 인증이 없어도 된다고 했는데 들어가 있거나
프레임워크를 Next.js로 쓰고 싶었는데 Express로 만들거나
아직 기획이 안 됐는데 너무 복잡한 구조로 짜버리거나

방향이 잘못된 채로 코드가 쌓이면, 나중에 수정하는 비용이 처음부터 다시 만드는 것보다 커집니다. 그리고 Claude는 멈추지 않습니다. 계속 만듭니다.

독서잡담:: 번뇌를 벗어나, 감정과 마주해.

gywndi@gmail.com (gywndi) — Sat, 30 Aug 2025 08:55:10 +0900

최근 사피엔스 두꺼운 책을 3번째 시도를 거쳐 읽어나가고 있는 와중. 감정이라는 무기에서 일맥상통하는 시타르타 부처의 가르침이 머릿속을 맴돌기에. 이에 대해 기록을 해보고자 합니다. 물론 일부 발췌 문구에 여러 기록의 상상의 나래를 펼쳐 내용을 장황 늘려보았어요.

부타의 번뇌를 벗어나는 가르침

시타르타의 가르침은 번뇌를 벗어나 해탈의 경지에 이르는 것을 핵심으로 합니다. 불교에서는 이 번뇌가 인간의 고통을 낳는 근본적인 원인이고, 이를 벗어나기 위한 수양법을 가르쳐왔습니다.

1. 사성제(四聖諦)

고제(苦諦): 인생에는 고통(생로병사)이 있다.
집제(集諦): 그 고통의 원인은 탐욕,분노,어리석음 이다.
멸제(滅諦): 번뇌를 없애면, 열반(해탈) 에 이른다.
도제(道諦): 해탈에 이르는 길이 있으니, 그것이 팔정도(八正道)이다.

2. 팔정도(八正道)

정견(正見): 세상에 있는 그대로, 바르게 보는 것
정사유(正思惟): 욕심/해침/해로움 없는 올바른 생각
정어(正語): 거젓말/험담/욕설 하지 않는 올바른 말
정업(正業): 살생/도둑질/사악한 행위를 피하는 올바른 행동
정명(正命): 다른 생명을 해치지 않는 올바른 생활
정정진(正精進): 끊임없이 선한 마음을 일으키고, 악한 마음을 줄이기 위한 노력
정념(正念): 지금 이 순간을 맑게 알아채는 마음가짐
정정(正定): 마음을 고요하게 집중하는 것

감정과 마주하기?

“감정을 억누르지 말고, 있는 그대로 바로보아라.” 라는 예전 도서의 문구가 머릿속을 맴돌았다. 감정은 억압을 하거나 무시를 할 때 오히려 더 강력해지고, 부정적인 패턴으로 이어질 수 있습니다. “부정적인 감정"을 애써 외면하지 말고, 직접 마주하고 생산적인 에너지를 바꾸기를 가이드합니다.

워드프레스 블로그 휴고 전환 스토리

gywndi@gmail.com (gywndi) — Wed, 20 Aug 2025 11:27:18 +0900

Overview

벌써 15년이 훌쩍 넘었던 워드프레스 블로그. 워낙에 레거시 태그들이 내부적으로 많았고. 스킨을 몇번 변경하다 보니. 이미 덕지덕지 오염(?)이 되어있던 상태. 그 와중 hugo를 접하면서 이쪽으로 넘어오면 좋겠다는 생각만을 마음속으로만 했었는데. 어제 겸사겸사 마음을 잡고 이 대사작업을 진행을 해보았습니다.

hugo가 생소하신 분들도 있으실텐데.. hugo는 정적 사이트 생성기로. golang로 만들어져 있으며. 속도도 빠르고, 마크다운 기반 컨텐츠를 HTML/JS/CSS 등으로 변환해주는 녀석입니다. hugo로 글을 쓰면 좋은 것은. 굳이 GUI툴을 사용하지 않더라도. md 파일을 syntax를 적절히 넣어서 작성하면 되고. 모든 것을 git으로 관리하며. netify와 연계를 하면 기존 도메인도 제대로 활용할 수 있다는 점입니다. 로컬에서 서술하듯 글을 쓰다 보니. 가볍고, 생산적이고. 기타 등등..

리눅스에서 tc로 레이턴시 조정해보기

gywndi@gmail.com (gywndi) — Wed, 18 Sep 2024 12:26:29 +0000

Overview

일년만에, 블로그에 새 글을 올려봅니다. 그동안, 많은 주제가 있었지만, (주관적인 판단이지만) 좋은 주제일지 예전같은 확신이 서지 않아서, 많은 시간 망설이며 잠시 블로그를 멈추었습니다.

그러나, 제가 알던 경험이. 나만의 아련한 기억이 되고 점차 소멸되기 전에. 잊기 전에. 블로그 하나를 올려봅니다. 멀티DC 환경을 고려하면서, 몇가지 테스트를 하던 중. 노드간 네트워크 레이턴시를 고민을 했었는데. TC(Traffic control)를 활용하였고 나름 의미있는 결과를 도출했었는데.. 오늘은 tc에 대해서 이야기를 해보고자 합니다.

Traffic control (TC)?

동일 네트워크 상에서, DC간의 레이턴시를 고려하여 성능 변화를 테스트하고 싶은 경우가 있습니다. 특히나, 과거와는 다르게 서비스가 여러개의 DC 또는 Zone에서 분산 구동될 수 있다는 상황을 고려해본다면. 이런 테스트는 필수 입니다. 참고로, 아주 오래 전, 서울/부산 레이턴시 14ms로 인하여 대형 서비스 장애를 경험해본 입장으로. 서비스 오픈 전 이런 검증은 필수라 생각합니다.

Apache Ignite로 분산 캐시 만들어보고 싶어요 (1탄)

gywndi@gmail.com (gywndi) — Tue, 10 Oct 2023 07:10:35 +0000

Overview

안녕하세요. 벌써 일년이 넘는 시간동안 포스팅을 하지 않았네요.

그동안 업무적으로 많은 변화도 있던 격동의 시기였던지라, 제 삶의 가장 중요한 요소 중 하나라 생각하던 공유의 가치를 그만 간과하고 말았네요. 물론 포스팅을 멈춘 시간동안 놀지 않고 많은 경험을 쌓아보았습니다.

오늘은 그중 하나, 인메모리 데이터베이스인 Apache Ignite에 대해 이야기를 해보고자 합니다.

Apache Ignite?

이미 많은 분들이 Ignite 를 사용해보셨을 수도 있겠습니다만, 저는 DBA로 일을 하면서도 늘 제대로된 캐시 용도로 써보고 싶었던 분산 인메모리 데이터베이스가 Apache Ignite입니다.

MySQL Heatwave를 살펴보았습니다

gywndi@gmail.com (gywndi) — Mon, 23 May 2022 00:00:00 +0000

Overview

안녕하세요. 너무 오랜만에 글을 올려봅니다. 올해도 벌써 반이 훌쩍지나버렸네요.

MySQL을 쓰시는 분들, 아니 RDBMS를 써오시던 분들의 가장 가려운 부분은 개인적으로 통계 쿼리 수행 속도라고 봅니다. 특히나 데이터 사이즈가 하루가 다르게 폭발적으로 증가해가는 상황에서 너무나도 반가운 소식이라고 봅니다. HTAP(Hybrid transactional/analytical processing) 구현이라 하는데..

오늘 이 포스팅에서는 서비스 활용 관점으로 Heatwave를 이야기해보도록 하겠습니다.

MySQL Heatwave는?

Oracle Cloud에서 제공하는 OLAP 분산 클러스터로, MySQL의 InnoDB데이터를 자동으로 Heatwave 클러스터로 동기화하여, 제공하는 스토리지 엔진 플러그인입니다.

Fluentd? 나만의 에이전트 패키징!

gywndi@gmail.com (gywndi) — Tue, 07 Sep 2021 03:26:39 +0000

Overview

세상에는 수많은 모니터링 도구들이 있습니다. 최근 많이 사용하고 있는 시계열 데이터베이스인 Prometheus와 수많은 exporter가 그중 하나입죠. 매트릭 수집에 최적화된 이런 구성은 시스템의 상태 값을 수집하기에는 더없이 좋은 시스템이기는 합니다만, 로그성 데이터 수집(에러로그 혹은 syslog)에는 아무래도 한계를 가집니다.

이 경우, td-agent와 같은 범용적인 로그 수집 에이전트를 활용하게 되는데요. (혹은 자체적으로 구현을 하거나) 타팀과 혼재해서 사용하는 경우 문제 발생소지가 있긴합니다. 참고로, td-agent는 ruby 뿐만 아니라, 필요한 라이브러리들을 패키지 내부에 포함시켜서, OS 의존성을 최소화합니다.

MySQL document store 초간단 테스트

gywndi@gmail.com (gywndi) — Wed, 28 Jul 2021 02:00:16 +0000

Overview

MySQL을 마치 NoSQL의 저장소처럼 써보겠다는 Document Store!! 만약 memcached plugin처럼 native한 프로토콜로 스토리지 엔진에서 직접적인 데이터 처리를 할 것 같은 꿈만 같은 저장소로 느껴졌습니만..

결론적으로 이야기해보자면.. 단순히 json 타입의 컬럼에 데이터를 넣고 빼기위한 프로토콜일 뿐.. 모든 것이 쿼리로 변환이 되어서 데이터 처리가 이루어집니다.

이에 대해 간단한 테스트 내용을 공유해봅니다.

Installation

도큐먼스스토어를 활성화시키는 것은 간단합니다. 아래와 같이 mysqlx.so 플러그인만 설치를 하면 됩니다.

## mysql.session@localhost 계정이 존재해야함.
mysql> INSTALL PLUGIN mysqlx SONAME 'mysqlx.so';

mysql> show variables like '%mysqlx_port%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| mysqlx_port              | 33060 |
| mysqlx_port_open_timeout | 0     |
+--------------------------+-------+
2 rows in set (0.00 sec)

mysql> \! netstat -an | grep 33060
tcp46      0      0  *.33060                *.*                    LISTEN

참고로, mysql.session 계정이 있어야, 정상적으로 동작합니다. (Docker로 테스트하시는 분들은. ^^ 이부분 유념해주세요.) 이제 테스트를 하기위한 테이블과 데이터를 만들어봅니다.

Go언어로 나만의 Query Exporter 만들어보기!

gywndi@gmail.com (gywndi) — Tue, 13 Jul 2021 05:39:54 +0000

Overview

안녕하세요. 무더운 7월 잘 지내고 계시죠.?

오늘은 조금 특이한 주제를 가지고 이야기를 해보고자 합니다. 바로 go로 나만의 Exporter를 만들어보는 것입니다. 특정 쿼리를 등록을 해놓으면, 이 쿼리 결과를 Exporter 결과로 보여주는 간단한 프로그램입니다. 아직 Expoter가 무엇인지 생소하신 분들이 있을 수 있겠는데요. 오늘 차근차근 설명을 하면서, 머릿속에 살짝 인스톨해드리도록 하겠습니다. 🙂

Exporter?

Exporter란, Prometheus같은 시계열 데이터베이스에서 데이터를 끌어가기 위한 하나의 HTTP 서버라고 생각하면 되겠습니다. Prometheus에서는 정해진 주기에 따라 exporter의 특정 URL을 호출하고, 그 결과값을 시계열로 데이터를 저장합니다.

MySQL에서 리셋되는 시퀀스 만들어보기

gywndi@gmail.com (gywndi) — Mon, 21 Jun 2021 06:24:06 +0000

Overview

서비스를 준비하다보면, 시퀀스에 대한 요구사항은 언제나 생기기 마련입니다. 물론, MySQL에는 기본적으로 테이블 단위로 auto_increment가 있기는 합니다만, 일반적인 시퀀스가 요구되는 환경을 흡족하게 맞추기는 어려운 실정입니다.
보통은 Peter Zaitsev가 하단에 게시한 블로그 내용처럼, Function 기반으로 채번 함수를 만들고는 하지요. (물론 InnoDB로 지정하는 것이, 복제 상황에서는 아주 안정성을 확보하기는 합니다.)
https://www.percona.com/blog/2008/04/02/stored-function-to-generate-sequences/

이 내용을 기반으로, “재미난 시퀀스를 만들어볼 수 없을까?” 라는 퀘스천에 따라, 이번 블로깅에서는 특정 시점에 리셋이 되는 시퀀스를 한번 만들어보고자 합니다.

Schema

첫번째로는 현재 시퀀스를 담을 테이블 그릇(?)을 아래와 같이 생성을 해보도록 하겠습니다.

MySQL binlog파서와 memcached plugin의 콜라보레이션!

gywndi@gmail.com (gywndi) — Mon, 31 Aug 2020 00:55:06 +0000

Overview

6개월도 훌쩍 넘은 시간에. 간만에 포스팅합니다. 그동안 OGG javaue든, MySQL Binlog파서든.. 흐르는 데이터를 핸들링하는 고민으로 하루하루를 지내왔던 것 같아요. 그러던 중 이전 포스팅에서 주제로 삼았던, InnoDB memcached plugin을 Binlog parsing을 통해 데이터를 맞추면 좋을 것 같다는 생각이 들었습니다.
오늘 이 자리에서는 이런 답답함을 극복하고자, Binlog 이벤트를 활용하여, 최신 데이터를 유지시키는 방안에 대해서 이야기를 해보도록 하겠습니다.

MySQL Binary log?

MySQL에서 데이터복제를 위해서는 Binnary Log(binlog)를 쓰게 되는데, 이중 ROW 포멧으로 만들어지는 이벤트를 활용하여 다양한 데이터 핸들링이 가능합니다.

MySQL InnoDB의 메모리 캐시 서버로 변신! – 활용편 –

gywndi@gmail.com (gywndi) — Mon, 06 Jan 2020 14:10:44 +0000

Overview

벌써 새해가 밝았네요. 새해 복 많이 받고 계시쥬?

판교 생활을 한지도 벌써 만 7년을 훌쩍 지나, 8년을 향해 가고 있군요. 2020년 우주의 원더키디(아재 인증)의 그 시간이 이렇게나 빠르게 찾아올 줄은 그때의 저는 몰랐답니다. ㅠㅠ

오늘 주제는, 그동안 MySQL innodb memcached 플러그인의 마지막편, (지극히 개인적인 의견인) 서비스적인 활용 편입니다. 상상의 날개를 펼쳐서, 서비스 최우선적인 활용을 위해 무엇을 꿈꿔볼 수 있을지, 이야기 해보고자 합니다. (이전 포스팅은 하단을 참고요.)

1탄. MySQL InnoDB의 메모리 캐시 서버로 변신! – 설정편 –
2탄. MySQL InnoDB의 메모리 캐시 서버로 변신! – 모니터링편 –

MySQL InnoDB의 메모리 캐시 서버로 변신! – 모니터링편 –

gywndi@gmail.com (gywndi) — Thu, 19 Sep 2019 14:28:50 +0000

Overview

MySQL memcached plugin 2탄! 모니터링편입니다.
어떤 초호화 솔루션일지라도, 시스템의 정확한 상태를 파악할 수 없다면, 사용하기에는 참으로 꺼려집니다. 그래서 어떤 방법이든, 가장 효율적인 모니터링 방안을 찾아봐야 하겠는데요. 저는 개인적으로는 prometheus를 활용한 metric수집을 선호합니다.
오늘 이 자리에서는 Prometheus에서 MySQL InnoDB memcached plugin을 모니터링 하는 방법에 대해서 이야기를 해보도록 하겠습니다. 🙂

Why prometheus?

이유는 단순합니다. 이미 만들어져 있는 exporter가 굉장히 많다는 것, 만약 원하는 것들이 있다면 나의 구미에 맞게 기능을 추가해서 쉽게 접근할 수 있다는 것! 즉, 오픈소스라는 것!! 무엇보다 Time-series 기반의 데이터 저장소인 Prometheus로 정말로 효율적으로 모니터링 매트릭 정보를 수집할 수 있다는 것! Prometheus는 로그 수집에 최적화 되어 있다고 과언이 아닙니다.

MySQL InnoDB의 메모리 캐시 서버로 변신! – 설정편 –

gywndi@gmail.com (gywndi) — Sun, 15 Sep 2019 11:50:15 +0000

Overview

꽤나 오래전의 일이었습니다. MariaDB에서 Handler Socket이 들어간 이후 얼마 후인 것으로 기억합니다. MySQL lab버전에 memcached plugin 기능이 추가되었고, memcache protocal로 InnoDB 데이터에 직접 접근할 수 있는 길이 열린 것이었죠. (아마도 거의 8년 정도 전의 일이었던 것같은..) 아무튼 당시, 이것에 대해 간단하게 테스트만 해보고, MySQL을 캐시형태로 잘 활용할 수 있겠다라는 희망만 품고 지나버렸다는 기억이 나네요.

이제 Disk는 과거의 통돌이 디스크가 아니죠. 기계 장치를 탈피하여, 이제는 모터없는 전자기기.. SSD의 시대가 도래하였습니다. 통돌이 대비, 어마어마한 수치의 Random I/O를 제공해주는만큼, 이제 DB 데이터에 새로운 패러다임(?)으로 접근할 수 있겠다는 시점이 온 것 같아요.

오픈소스 데이터베이스, 흐르는 은행 데이터에 빨대를 꽂아보다.

gywndi@gmail.com (gywndi) — Wed, 11 Sep 2019 11:52:42 +0000

ifkakao 발표 세션 동영상이 떴습니다. 두둥!

오픈소스 데이터베이스, 흐르는 은행 데이터에 빨대를 꽂아보다

발표 자료는 아래에 있어용! (근데 왜 embed가 안되지.. -_-;)
자료: 오픈소스 데이터베이스 은행데이터에 빨대를 꼽아보다.v.1.1

MySQL 파티셔닝 테이블 SELECT가 느려요.

gywndi@gmail.com (gywndi) — Thu, 29 Aug 2019 14:56:26 +0000

Overview

네이티브 파티셔닝 적용 이전의 MySQL은, 파티셔닝 파일들은 각각이 테이블로써 관리되었죠. 그래서, table cache 로 인한 메모리 부족 현상은 인지하고 있었습니다만.. 이것 외에는 특별히 성능 저하 요소는 없다고 생각해왔어요. (http://small-dbtalk.blogspot.com/2013/09/mysql-table-cache.html)

그런데, 얼마전 서버당 4개의 데이터베이스를 만들고, 각각 데이터베이스 안에 26개월로 분할된 파티셔닝된 테이블을 넣고, 간단한 Range scan 성능 테스트를 하였는데.. 말도안되는 수치를 보였습니다. 이 관련하여 간단하게 이에 대해 알아보도록 할께요. 🙂

Problem

하단과 같은 테이블 구조에서, 단순히 최근 10건의 데이터만 끌어오는 형식의 SQL을 다수 실행시켜 간단한 트래픽을 주었을 때.. 성능적으로 별다른 문제는 없을 것이라고 생각을 했습니다. 우리의 메모리는 기대치보다 훨씬 웃돌았기 때문에.. ㅎㅎ (참고로, InnoDB 버퍼풀 사이즈 대비 데이터 사이즈는 약 10배 이상이지만, 최근 파티셔닝 사이즈를 따지면, 버퍼풀 안에 충분히 들어올만한 상황이었습니다.)

PMM팁1탄! MySQL을 READ-ONLY 기준으로 표기해보기.

gywndi@gmail.com (gywndi) — Mon, 28 Jan 2019 23:58:03 +0000

Overview

어느덧 1월이 마무리되어가는 이 시점.. 한달 내내 놀다 시간 보내기에는 아쉬움이 많이 남아, 블로그 한두개 정도는 남겨보고자, 아주 간만에 노트북 앞에 앉습니다. 가장 기억 속에 맴도는 주제를 찾던 중, 작년 나름 많은 분석을 했었던 내용들을 한번 몇가지 주제로 정리해보고자 합니다.

PMM(Percona Monitoring and Management)이라는 녀석으로 퉁 쳐서 이야기를 했지만, 사실 이번에 이야기할 내용은 Prometheus 쿼리와 Grafana를 사용하는 간단한 꼼수(?)에 대한 이야기입니다.

혹시 PMM이 어떤 녀석인지 궁금하시다면? PMM 이야기 1편 – INTRO 편을 읽어보주세요. ㅎㅎ

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

gywndi@gmail.com (gywndi) — Fri, 12 Oct 2018 00:00:52 +0000

Overview

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

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

MySQL에서 Affected Rows를 병맛나게 활용해보자.

gywndi@gmail.com (gywndi) — Mon, 26 Mar 2018 23:45:20 +0000

Overview

이제 슬슬 날이 풀려가고 있습니다. 얼어붙은 땅이 녹듯이, 오랜시간 얼어있던 블로그 공간도 잠시마나 녹여볼까 합니다. 사실 지난 PMM 이야기 1편 이후 2편, 3편 쭉 써야하지만.. 이노무 귀차니즘과 여기저기 산재한 낙서들을 아직 정리하지 못한 탓에.. 쿨럭..

사실 오늘 얘기할 내용은 3년도 훨씬 전 내용으로, 블로그로 이미 정리했다고 지금까지 착각을 했던 이야기입니다. 바로 Affected Rows 값을 활용해서, 다양한 요구 사항을 조금 더 재미있게 풀어보자는 내용이죠.

Affected Rows?

다들 아시겠지만, Affected Rows는 DML시 실제로 영향을 미친 데이터 Row 수입니다. 보통 update/delete를 날린 후에 몇 건의 데이터가 변경이 되었는지를 CLI툴에서 확인하는 용도로만 제 경우에는 많이 사용하고는 했습니다.

PMM 이야기 1편 – INTRO

gywndi@gmail.com (gywndi) — Sat, 03 Mar 2018 17:33:28 +0000

Overview

정말 오랜만에 글을 써봅니다. 은행이 오픈한지도 어언 8개월째를 훌쩍 접어들었네요. 여전히 MySQL 서버군에는 이렇다할 장애 없이, 무난(?)하게 하루하루를 지내고 있습니다.. (아.. 그렇다고 놀고만 있지는 않았어요!!)

사실 그동안의 경험과 삽질을 바탕으로, 필요성을 느꼈던 다양한 부분을 중앙 매니저에 최대한 녹여보았고, 그 집대성의 결과가 지금 뱅킹 MySQL시스템입니다. MHA 관리, 스키마 관리, 파티션 관리, 패스워드 관리, 백업/복구 관리..아.. 또 뭐있더라.. -_-;; 암튼, 귀찮은 모든 것들은 최대한 구현을 해놓았지요.

그러나, 예전부터 늘 부족하다고 생각해왔던 한가지 분야가 있는데.. 그것은 바로 모니터링입니다. 시스템에 대한 가장 정확한 최신 정보는 바로 모니터링 지표입니다. 만약, 제대로된 모니터링 시스템 환경 속에서, 실제 서비스의 영속성과 시스템의 매니지먼트를 모니터링 지표를 통해서 제대로된 에코 시스템을 구축할 수 있다면? 등골이 오싹할 정도의 선순환 작용으로 엄청 견고한 시스템을 구축할 수 있겠죠.

JDBC의 autoReconnect 파라메터가 저지른 일!

gywndi@gmail.com (gywndi) — Tue, 31 Oct 2017 00:00:00 +0000

세상에 말도 안되는 일이 일어났습니다.

서비스가 정상적으로 동작하기 위해서는, 아무래도 데이터베이스가 필수인데.. 이 데이터베이스로부터 쉽게 데이터를 주고받을 수 있게 디비별/언어별 중간 역할을 해주는 것이 바로 Driver입니다.

MySQL역시 자바에서 원활하게 데이터 처리를 수행할 수 있도록 connector/j라는 녀석을 Oracle에서 배포를 하는데.. 오늘은 이 녀석이 제공해주는 기능인 autoReconnect 파라메터가 저지르는 일에 대해서 얘기를 해보고자 합니다.

autoReconnect는 무슨 일을 하는가?

파라메터 이름 그대로.. 자동으로 커넥션을 다시 맺어준다는 의미입니다. 데이터베이스 역시 서버로 구동하는 프로그램의 한 축이기에.. 클라이언트가 맺은 커넥션이 절대 끊어지지 않는다고 보장할 수 없습니다.

소소한 데이터 이야기 – pt-online-schema-change 편 –

gywndi@gmail.com (gywndi) — Wed, 23 Aug 2017 22:20:31 +0000

Overview

MySQL 5.6부터는 Online ddl 기능을 제공하기 시작하였지만, 사실은 이전에도 트리거 기반의 online alter 유틸로 서비스 중단없이 테이블 스키마 변경을 수행했었습니다. 이중 percona에서 제공해주는 pt-online-schema-change가 많이들 활용되고 있는데요. 오늘은 돌다리도 망치로 때려가면서 안정성에 신중히 접근한 우리의 케이스에 대해서 데이터 기준으로 얘기를 해보고자 합니다.

pt-online-schema-change?

얘기하기에 앞서서, 이 툴에 대해서 다시한번 짚어보겠습니다. 대충 동작 순서는 아래와 같이..

변경할 스키마 구조의 임시 테이블을 생성하고,
insert/update/delete 트리거를 만들어서 최근 변경 데이터를 동기화하고,
처음부터 끝까지 일정 청크 사이즈로 읽으면서 임시 테이블에 복사한 후,
완료되면 RENAME TABLE하여 완료

동작합니다.

데이터쟁이 입장으로 “슬로우 쿼리”를 다시 고민해보았습니다.

gywndi@gmail.com (gywndi) — Mon, 14 Aug 2017 23:13:09 +0000

Overview

서비스를 하면 당연히 실행이 오래 걸리는 쿼리, 슬로우 쿼리는 발생합니다. 원인은 정말 비효율적인 쿼리인 것도 있겠지만, 때로는 Lock, Disk fault 등등 원인은 다양합니다. DB 내/외부 요소에 의해서, 슬로우 쿼리가 발생하게 되는데.. 이것을 늘 모니터링하고 적시에 바로 최적화 적용을 하는 것이야말로, 안정적인 서비스 최상 품질 보장의 첫 걸음이라고 생각합니다.

물론, 이 관련해서는 여러가지 방법론이 있겠지만, (예를들면 fluentd를 활용한 수집 방안) 슬로우 쿼리를 데이터로써 제가 생각하는 원칙으로 접근해보았습니다.

스크립트는 하단 github를 참고하시지요. 아마도 잘 될꺼예요. (50% 상상코딩이라..흐흐)
https://github.com/gywndi/kkb/tree/master/mysql_slow_log_gather

[MySQL] 바쁜 서비스 투입 전, 이런 캐시 전략 어때요?

gywndi@gmail.com (gywndi) — Thu, 15 Jun 2017 21:39:12 +0000

Overview

데이터베이스를 운영한다는 것은 최적의 상태로 리소스를 쥐어짜면서 가장 효율적으로 데이터를 끄집어내야할텐데요. 지금은 SSD 디스크 도입으로 상당 부분 Disk I/O가 개선되었다지만, 여전히 메모리 효율은 굉장히 중요합니다. 특히나 Page Cache와 같은 항목이 과다하게 메모리를 점유하게 되면.. 다른 프로세스 효율에도 영향을 미칠 뿐만 아니라, 때로는 메모리 부족 현상으로 인하여 스왑 메모리에도 영향을 줄 수 있습니다.

서론은 짧게.. 이번에 DBMS 구조를 그려가면서, 실제 리소스 사용에 걸림돌이 되는 몇몇 요소에 대한 우리의 사례를 얘기해보도록 하겠습니다.

[MySQL] 슬레이브 하나 더 추가했을 뿐인데.. :-)

gywndi@gmail.com (gywndi) — Mon, 12 Jun 2017 21:08:18 +0000

Overview

MySQL의 꽃중의 꽃은 역시 비동기 방식의 데이터 복제라고 볼 수 있는데요. 지극히 개인적인 생각이기는 하지만, 슬레이브 노드를 데이터 일관성이 반드시 필요한 상황에서의 READ 스케일아웃을 제외하고는, 지금의 MySQL을 있게한 결정적인 한방이라고 봅니다. 물론 소셜 서비스에 따른 기존 스케일업으로는 도저히 감당할 수 없는 데이터 사이즈와 비용 요소도 직접적인 영향을 주었겠지만요.

뜬구름잡는 얘기는 여기까지로 마무리하고.. 슬레이브 노드를 READ 분산 혹은 배치 서버 용도를 제외하고는 스탠바이 용도로 한대를 더 추가하는 경우는 극히 드뭅니다. 뭐, 나랏님이 시키는대로.. 반드시 수십 km 떨어진 IDC에 DR 서버를 구축해야한다는 법적인 제약인 경우를 제외하고는요.

MySQL_5.7의 n-gram? 버그앤런!

gywndi@gmail.com (gywndi) — Thu, 08 Jun 2017 19:52:06 +0000

Overview

바로 얼마전 포스팅에서 n-gram에 대한 간단한 소개를 했었는데.. 아무래도 5.7에 처음으로 소개된 기능인만큼 현재 이슈 사항에 대해서 공유를 해볼 필요가 있어보입니다. (이전 포스팅: “MySQL_5.7의 n-gram 전문 검색을 이상하지 않게 써보아요”)

제가 겪은 상황과 우회할 수 있는 방안.. 그리고 현재 진행 상황에 대한 내용이예요. ^^

1. Performance Problem

일단 InnoDB의 n-gram 인덱싱은 두 글자로만 나뉘어서 토큰으로 만들어집니다. 그리고 이 토큰들은 도큐멘트 아이디를 각각 가짐으로써, 빠르게 두 글자가 포함된 문서를 바로 찾아낼 수 있는 것이지요.

MySQL_5.7의 n-gram 전문 검색을 이상하지 않게 써보아요.

gywndi@gmail.com (gywndi) — Tue, 18 Apr 2017 23:47:31 +0000

Overview

MySQL5.6부터는 InnoDB에서도 전문검색이 가능하기는 하였습니다만.. 아쉽게도 여전히 공백 기준으로 단어들이 파싱이 되는 MeCab Full-Text Parser Plugin 방식으로 동작합니다. 즉, 한국말처럼 공백만으로 단어를 파싱할 수 없는 언어의 경우에는 크게 매력적이지는 않습니다. InnoDB에서 전문검색 인덱싱이 가능하다는 것은 Transaction이 전제로 이루어지는 것이라고 볼 수 있기에.. 리플리케이션 및 시점 백업/복구 측면에서는 혁신으로 볼 수 있습니다.

반드시 Limit로 끊어서 가져오고자 한다면, ‘Order By’로 정렬을 하세요~ 이 관련해 버그가 있고 조만간 픽스될 예정이기는 합니다. (n-gram 처리 시 스토리지 엔진에서 limit이 영향을 미쳐 제대로된 결과 도출 혹은 최악의 경우 크래시까지 발생할 수 있어요.)

세상만사 귀찮은 MySQL DBA를 위한 자동 복구 시나리오

gywndi@gmail.com (gywndi) — Mon, 23 Jan 2017 14:10:02 +0000

Overview

안녕하세요. 요새 창고 대방출! 그동안 미뤄 두었던 얘기들을 연달아 공유합니다. (마스터 스크립트를 만들어야하는 수고를 덜기 위해.. 해당 스크립트 제거 및 스크립트 수정하였습니다.)

MySQL을 사용하는 이상, 리플리케이션 활용에서 벗어나기 쉽지 않은데요. 그 말은 곧 다수의 동일한 데이터를 가진 여러개의 서버를 운영관리 해야한다는 말과 같고.. 장비가 많아진다는 것은 그만큼 데이터 복구가 많다는 이야기이기도 하지요. 특히나 샤딩 환경으로 데이터 폭증을 대비해두었다면 더욱 그렇습니다.

게다가 복구 시 새벽 백업을 사용한다는 말은 곧 새벽 이후로 저장이된 변경 이력을 일괄 적용을 해야하고.. 이 내용이 많으면 데이터 동기화 시간도 적지않게 소모되고.. (횡설수설~)

MySQL에서 파티션 일부를 다른 파티션 테이블로 옮겨보기

gywndi@gmail.com (gywndi) — Fri, 20 Jan 2017 04:24:56 +0000

Overview

한동안 운영에 치여, 문서를 못봤더니, 재미난 사례를 많이 놓친듯.
그래서 여기저기 떠도는 문서 중 재미난 사례 하나를 내 입맛에 맞게 샘플을 변경해서 공유해봅니다.
(영혼없이 붙여넣기만 해도 알아보기 쉽게 ㅋㅋ)

Preview

파티셔닝 특정 부분을 다른 테이블 혹은 파티셔닝 일부로 넘기는 방안에 대한 것인데..

하단 포스팅 내용 중 미흡한 부분을 보완해서 정리해본 것입니다
https://dzone.com/articles/how-to-move-a-mysql-partition-from-one-table-to-an

Generate Test Data

먼저 테스트 데이터를 생성해야할테니..

mysql> create table f_tb (
      seq bigint(20) not null default '0',
      regdate date not null,
      cont text not null,
      primary key (seq,regdate)
  ) engine=innodb collate=utf8_unicode_ci
  /*!50500 partition by range columns(regdate)
  (partition p09 values less than ('2016-10-01'),
   partition p10 values less than ('2016-11-01'),
   partition p11 values less than ('2016-12-01'),
   partition p12 values less than ('2017-01-01')) */;

아래처럼 테스트로 사용할 데이터를 간단하게 생성해봅니다. 2017-01-01 기점으로 랜덤하게 120일 사이 일을 빼서 마치 파티셔닝 테이블이 관리된 것처럼 데이터를 밀어넣는 것이죠.

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

gywndi@gmail.com (gywndi) — Tue, 17 Jan 2017 13:54:29 +0000

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 데몬을 설치하였으니..(두줄에.. 끝? -_-;; 헐~)

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

gywndi@gmail.com (gywndi) — Sun, 25 Sep 2016 15:30:47 +0000

Overview

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

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

파티션 제약 극복기! 유니크한 토큰 값을 만들어보자!

gywndi@gmail.com (gywndi) — Fri, 03 Jul 2015 14:15:42 +0000

Overview

MySQL에는 날짜 별 데이터 관리를 위해 파티셔닝이라는 좋은 기능(?)을 5.1버전부터 무료(!)로 제공합니다. 일정 시간 지난 후 불필요한 데이터는 간단하게 해당 파티셔닝을 제거하면, 굳이 DELETE 쿼리로 인한 오버헤드를 방지할 수 있죠.

그러나, 파티셔닝 적용 시, **“파티셔닝 키는 반드시 PK에 포함되어야 한다”, “추가 제약조건(유니크 속성)을 부여할 수 없다”**라는 대표적인 제약 조건으로 인하여, 유니크 속성을 가지는 데이터를 파티셔닝 적용이 불가한 경우가 있는데.. 이것을 해결할 수 있는 간단한 트릭을 이 자리에서 설명하고자 합니다. ^^

새벽 4시, 이유없이 디스크 유틸이 튄다면? 디스크 성능에 영향을 주는 크론잡

gywndi@gmail.com (gywndi) — Thu, 05 Feb 2015 12:44:51 +0000

Overview

새벽에 디스크 성능에 영향을 주는 요소로는 대표적으로 백업과 같은 디비 운영적인 업무가 있습니다. 각 운영 정책에 따라 다르겠지만, 순간적인 시스템 부하에도 굉장히 민감한 서비스 경우에는 별도의 스탠바이 용도의 슬레이브 서버를 두고 그곳에서 백업을 하기 마련입니다.

이런 상황 마스터에서는 백업과 같은 무거운 디스크 작업이 일어나지 않는 상황에서 알 수 없는 이유로 새벽 4시 혹은 4시 22분에 디스크가 유틸이 튀는 경우가 있습니다. 그리고 가벼운 쿼리일지라도 대거 슬로우 쿼리로 잡히기도 합니다.

범인은 의외로 리눅스 설치 시 기본적으로 등록되는 두 가지 크론잡에 있는데요, 얼마 전 이와 비슷한 사례를 경험하게 되어 공유 드립니다. (단, 고수님들은 출입금지!)

InnoDB의 Adaptive Hash Index로 쿼리 성능에 날개를 달아보자!!

gywndi@gmail.com (gywndi) — Thu, 08 Jan 2015 13:28:02 +0000

Overview

MySQL과 같은 RDBMS에서 대표적으로 가장 많이 사용되는 자료 구조는 B-Tree입니다. 데이터 사이즈가 아무리 커져도 특정 데이터 접근에 소요되는 비용이 크게 증가되지 않기 때문에 어느정도 예상할 수 있는 퍼포먼스를 제공할 수 있기 때문이죠. 그치만 상황에 따라서, B-Tree 사용에 따른 잠금 현상으로 최대의 퍼포먼스를 발휘하지 못하는 경우도 있습니다.

이에 대한 해결책으로 InnoDB에는 Adaptive Hash Index 기능이 있는데, 어떤 상황에서 효과가 있고 사용 시 반드시 주의를 해야할 부분에 대해서 정리해보겠습니다.

InnoDB B-Tree Index?

소개하기에 앞서서 먼저 InnoDB에서 B-Tree가 어떠한 방식으로 활용되는 지 알아볼까요?

MariaDB의 FederatedX 엔진으로 데이터를 주물러보자.

gywndi@gmail.com (gywndi) — Tue, 30 Dec 2014 13:12:02 +0000

Overview

FederatedX는 MariaDB에서 제공하는 확장된 기능의 Federated이며, 기본적으로 MariaDB에서는 별다른 옵션 없이 사용할 수 있습니다.

바로 이전 포스팅(MariaDB의 FederatedX 엔진을 활용한 9억 데이터 이관기)에서는 이 FederatedX 엔진을 활용하여 대용량 테이블을 서비스에 큰 지장없이 이관을 했던 사례에 대해서 정리를 했었는데요. 이 경험을 바탕으로 서비스에서 조금 더 유용하게 활용할 수 있을 방안에 대해서 상상(?)을 해보았습니다.

즉, 지금부터는 FederatedX 엔진 관련된 테스트를 바탕으로 정리하는 내용이오니, 만약 실 서비스에 적용하고자 한다면 반드시 검증 후 진행하셔야 합니다. ^^

MariaDB의 FederatedX 엔진을 활용한 9억 데이터 이관기

gywndi@gmail.com (gywndi) — Sat, 27 Dec 2014 14:16:23 +0000

Overview

대용량 로그 테이블은 때로는 서비스에 지대한 영향을 미치기도 합니다. 게다가 이 테이블을 파티셔닝 구성을 해야하는데, 이를 서비스 운영 중인 상태에서 마스터 장비에서 Import하는 것은 사실 대단히 위험한 시도이기도 하죠.

이런 상황에서 얼마 전 FederatedX엔진을 활용하여 9억 데이터를 이관한 사례가 있는데, 이에 대해 공유하도록 하겠습니다. ^^

Goal

9억 건의 데이터를 Import하는 동안 서비스에는 어떠한 영향도 없어야 하며, 구성 후 어플리케이션 적용 전까지 데이터가 정상적으로 동기화되어야 합니다.

데이터 이동하는 동안 기존 서비스 영향 최소화 및 문제 발생 시 빠른 원복
데이터 구성 후 어플리케이션 코드 배포 전까지 데이터 동기화
데이터 보관 주기 정책에 따른 유연한 대처
현재는 삭제 주기가 없으나, 추후 정책에 따라 변경 가능

Let me SEE..

가야할 골이 정해졌으니.. 현재 상황에 대해서 분석을 해봐야겠죠. ㅎㅎ 다음은 DB 사용 현황에 대한 내용입니다.

MariaDB의 FederatedX를 소개합니다.

gywndi@gmail.com (gywndi) — Fri, 05 Dec 2014 13:53:39 +0000

Overview

MySQL에는 Federated라는 스토리지 엔진이 있는데, 이는 원격의 테이블에 접근하여 제어하기 위한 용도로 사용됩니다. 얼마 전 이 엔진과 관련하여 재미있는 테스트를 하였는데, 이 내용을 소개하기에 앞서서 간단하게 정리해보도록 하겠습니다.

Features

FederatedX는 사실 MariaDB에서 Federated 엔진을 의미하는데, 이를 다른 이름으로 구분하는 것은 사실 더욱 확장된 기능을 가지기 때문입니다.

원격 서버 접근
원격에 있는 테이블을 로컬에 있는 것처럼 사용
트랜잭션
2-Phase Commit 형태로 데이터의 일관성을 유지
파티셔닝
각 파티셔닝 별로 다른 원격 테이블 참조 가능

Usage

FederatedX 스토리지 엔진은 MariaDB에서는 기본적으로는 활성화되어 있습니다. MySQL에서는 별도의 옵션을 줘야만 활성화되는 것과는 다른 측면이죠.

TokuDB? Fractal Index에 대해 알아보아요~!

gywndi@gmail.com (gywndi) — Thu, 29 May 2014 14:14:11 +0000

이 글은 제가 MySQL Power Group에 예전에 포스팅한 자료입니다.
참고 : http://cafe.naver.com/mysqlpg/189

과거와는 다르게 데이터 사이즈가 비약적으로 커지고 있습니다. 특히, 최근 들어 SNS 서비스가 성황을 이루면서, 개인화된 데이터는 날이 갈수록 기하 급수적으로 늘어나고 있습니다. 최근 Fratical Index 기반의 TokuDB가 오픈 소스로 풀리면서 재조명을 받고 있는데, 이에 대해서 간단하게 설명해보도록 하겠습니다.

`B-Tree`?

TokuDB에 논하기에 앞서, 전통적인 트리 구조인 B-Tree에 대해 알아보도록 하죠.

일반적으로 RDBMS에서 인덱스는 대부분 B-Tree기반으로 동작하는데, 크게는 Internal Node와 Leaf Node로 나뉩니다. Internal Node는 데이터를 어느 방향(작으면 왼쪽, 크거나 같으면 오른쪽)으로 보낼 지 결정하는 Pivot과 다음 Pivot의 위치를 알려주는 포인터로 구성됩니다. Internal Node의 가장 마지막 포인터는 Leaf Node를 향하는데, Leaf Node에는 보통은 데이터가 저장이 되죠.

Linux Hot Copy(hcp) – Snapshot Tool

gywndi@gmail.com (gywndi) — Tue, 10 Dec 2013 03:53:02 +0000

Overview

몇 달전 Linux Hot Copy(HCP) 유틸리티가 무료로 풀리면서, 고가의 스냅샷 유틸리티를 구입 없이도 얼마든지 사용할 수 있게 되었습니다. 스냅샷을 멋지게 활용할 수 있다면, 단순히 데이터 백업 뿐만 아니라 DB 시스템과 같이 복잡하게 얽혀서 구동되는 데이터도 특정 시점으로 데이터를 복사할 수 있습니다.

이 경우 Linux Hot Copy(hcp)에 대해 알아보도록 하겠습니다.

Feature

Point-in-Time 디스크 볼륨 스냅샷
Copy on Write 방식의 Snapshot
서비스 영향없이 스냅샷을 생성

<Snapshot 비교>

Copy-on-Write
Write 시 원본 데이터 Block을 Snapshot 스토리지로 복제하는 방식으로 Snapshot 데이터 Read 시 변경되지 않은 데이터는 원본 블록에서,변경된 데이터는 Snapshot 블록에서 처리
데이터 변경 분만 저장하므로 공간을 효율적으로 활용하나 블록 변경 시 원본 데이터와 스냅샷 데이터 양쪽 모두에서 Write이 발생
Redirect-on-Write
Copy-on-Write와 유사하나, 원본 볼륨에 대한 Write을 별도의 공간에 저장하는 방식으로 Copy-on Write(원본 Read, 원본 Write, 스냅샷 Write)에 비해 Write이 1회만 발생하나, 스냅샷 해제 시 변경된 블록들을 원본 데이터 블록으로 Merge시켜야함
Split mirror
원본 볼륨과 동일한 사이즈의 별도 복제 볼륨 생성하는 방식으로 데이터를 Full Copy하므로 즉시 생성이 어렵고 용량 또한 많이 필요

Installation

설치 버전을 다운로드 하기 위해서는 하단 페이지에서 등록해야하는데, 등록하게 되면 설치 바이너리를 다운로드 받을 수 있는 별도의 링크를 메일로 보내줍니다. 완벽한 오픈소스는 아닌지라.. 설치하기가 조금은 짜증이 나지만.. 일단은..뭐.. ㅎㅎ

MySQL의 User Level Lock를 활용한다면?

gywndi@gmail.com (gywndi) — Mon, 02 Dec 2013 02:13:40 +0000

Overview

DB에는 크게는 두 가지 타입의 Lock이 있습니다. Table Level Lock, Row Level Lock.. 두 가지 타입의 Lock은 RDBMS에서 대표적인 Lock이라고 지칭할 수 있습니다.

Table Level Lock은 데이터 변경 시 테이블 자체를 Lock을 걸어 안전하게 데이터를 변경하는 방식이고, Row Level Lock은 변경되는 칼럼의 Row에만 Lock을 걸어서 데이터를 조작하는 방식입니다. 일반적인 상황에서는 두 가지의 Lock만으로도 충분히 다양한 사용자의 요구사항을 충족할 수가 있습니다.

그러나, 테이블 파티셔닝을 하는 경우나, 혹은 다양한 서버에 데이터가 분산 저장되는 경우 DB 내적인 제약사항 혹은 데이터 공간 자체의 한계로 인해 상황에 따라 더욱 확장된 Lock이 필요한 경우가 있습니다.

SQLite 3탄 – 미리알고, 풀스캔을 방지하자.(1)

gywndi@gmail.com (gywndi) — Sun, 08 Sep 2013 12:51:33 +0000

처가 과수원 사과 수확을 하고 왔습니다. 매주 빡빡한 스케줄.. 연예인 못지않군요.^^ 그렇지만, 오늘도 역시.. SQLite 시리즈를 이어보겠습니다. ^0^ (힘들어서 2회에 걸쳐서 진행하겠습니다. ^^)

Overview

어떤 DBMS를 막론하고, Searching은 가장 중요한 요소입니다. 특히 데이터 건 수가 많을수록, 원하는 데이터를 찾아내기 위해 처음부터 끝까지 모두 파일을 뒤지게 된다면.. 쿼리 시간을 떠나 사용하는 전력 또한 상당할 것입니다. 특히 SQLite가 모바일 환경에서 대부분 활용된다는 상황에서, CPU 자원을 최소화한다는 것은 결과적으로 배터리 소모를 최소한으로 이룰 수 있음을 의미하죠. ^^

SQLite 2탄 – 데이터와 인덱스 구조!!

gywndi@gmail.com (gywndi) — Sun, 01 Sep 2013 13:29:33 +0000

여름은 거의 막바지로 치닫은 지금, 벌초 시즌이 찾아왔네요. 시원할줄만 알았던 산속 아침이 왜이렇게 따갑고, 오늘따라 산은 왜이렇게 가파르게 느껴지던지.. 집에 돌아오자마자, 쓰러졌습니다. ^^;

Overview

지난 1탄에 이어 SQLite에 대해 간단하게 포스팅하려 합니다. 어떤 솔루션을 사용하든, DB를 사용함에 있어서, 논리적인 데이터 모델을 정확하게 알고 있는 것이 중요하다고 생각합니다.

SQLite 역시 Database이고, 데이터 또한 나름의 구조를 가지고 있고, 재미있는 특성이 있죠. ^^

Data 구조

먼저 Data의 생김새를 먼저 살펴보도록 하겠습니다. SQLite의 각각의 Row는 고유의 8Byte 정수 타입의 RowID를 가집니다. 그리고 RowID 순서로 데이터는 저장됩니다. RowID가 생소한 분이 계실 수도 있겠네요. ^^ 특히 MySQL을 거의 사용하셨던 분에게는 낯선 용어가 될 수도 있겠죠.

SQLite 1탄, 이것만은 알고 넘어가자!

gywndi@gmail.com (gywndi) — Sun, 25 Aug 2013 13:21:24 +0000

안녕하세요. 오랜만에 포스팅을 합니다. 그동안 너무 소홀하게 블로그 관리를 한 듯..ㅜㅜ 뜬금없기는 하지만, 당분간 제가 공유할 주제는 바로 SQLite입니다. ^^;

SQLite?

SQLite는 간단하게 말하면, 트랜잭션을 제공해주는 파일 기반의 DBMS입니다. 모바일 서비스가 대세가 된 요새, SQLite 역시 가장 많이 사용되는 DB로 떠오르고 있습니다. 대충만 적어도 쟁쟁한 회사들이 애용을 하고 있는 상황이죠. ^^

일반적인 타 DBMS 처럼 데몬처럼 동작하는 방식이 아닌, 마치 라이브러리와 같이 프로그램에 직접 Embed하여 사용하죠. 그리고 간과하지 말아야하는 것은 SQLite는 기존 서버에서 구동하는 대형 DBMS를 대체하자는 개념으로 탄생한 DB가 아닙니다. 그것보다는 프로그램 내부에서 잦은 파일 접근(fopen)을 최대한으로 적게하자는 취지로 만들어진 DB이죠. 그렇지만 강력합니다. ㅎㅎ

InnoDB에서 Auto_Increment를 맹신하지 말자.

gywndi@gmail.com (gywndi) — Sun, 17 Feb 2013 15:01:55 +0000

Overview

MySQL에서는 시퀀스 개념이 없지만, 테이블 단위로 움직이는 Auto_Increment라는 강력한 기능이 있습니다. Auto_Increment 속성은 숫자 형 Primary Key를 생성하는 데 많이 사용됩니다.

특히나 InnoDB 경우에는 Primary Key 사이즈가 전체 인덱스 사이즈에 직접적인 영향을 미치기 때문에, 저도 테이블 설계에 많이 권고하는 사항이기도 합니다.

그러나 InnoDB에서 Auto_Increment가 동작하는 방식을 정확하게 알지 못하고 사용하면, 대형 장애 상황으로도 치닫을 수 있습니다.

오늘은 간단한 사례를 바탕으로 관련 내용을 공유할까 합니다. ^^

Auto_Increment In InnoDB

Auto_Increment는 스토리지 엔진 별로 다르게 동작합니다. 파일 기반의 스토리지 엔진인 MyISAM 경우에는 현재 Auto_Increment값이 파일에 일일이 기록되는 방식으로 관리됩니다. 그러나 메모리 기반의 스토리지 엔진인 InnoDB에서는 조금 다른 방식으로 관리됩니다.

대용량 테이블에서 카운트 정보를 효과적으로 관리하자.

gywndi@gmail.com (gywndi) — Sun, 28 Oct 2012 15:40:46 +0000

Overview

대부분 서비스에서는 데이터 카운트를 합니다. 커뮤니티에서는 사용자 아티클 수를, 결제 서비스에서는 남은 물폼 수를 관리하기 위해서 사용하죠. 그리고 트랜잭션이 중요한 서비스라면, 데이터 일관성 유지를 위해 카운트 시 매번 데이터를 다시 읽어옵니다.

데이터가 적으면 큰 문제가 되지 않겠지만, 데이터 지속적으로 누적됨에 따라 성능 또한 기하급수적으로 저하됩니다.

그렇다면 이러한 환경에서 어떻게 카운트 퍼포먼스를 향상할 수 있을까요? 오늘 포스팅할 내용은 MySQL뿐만 아니라 행 단위 잠금을 지원하는 환경도 포함합니다.

통계 테이블 사용

빠른 데이터 건 수를 가져오는 방법으로는 별도의 통계 테이블을 관리하는 것입니다. 다음과 같이 통계 테이블을 별도로 구성하여 카운트 정보를 관리합니다. 이렇게 되면, 굳이 덩치가 큰 테이블에서 일일이 카운트를 하지 않고, 통계 테이블에서 한 건의 데이터만 읽어오므로, 카운트 성능을 크게 향상할 수 있죠.

CentOS 6.x에서 MySQL 운영 시 반드시 확인해봐야 할 파라메터!

gywndi@gmail.com (gywndi) — Tue, 16 Oct 2012 07:48:35 +0000

Overview

MySQL 내부에서는 최대 허용 가능한 Connection을 설정할 수 있습니다. 하지만 OS 파라메터의 제약으로 때로는 임계치만큼 Connection을 늘릴 수 없는 경우가 발생하기도 합니다. 게다가, 만약 OS가 업그레이드되면서 관련 Default Value 가 변경되었다면? 이유없는 장애가 발생할 수도 있는 것이죠.

오늘은 OS 파라메터 중 CentOS 버전 별 nproc 값에 의한 Max Connection 제한에 대해 포스팅하겠습니다.

Environment

1) CentOS 5.8

CentOS 5.x버전의 nproc(Max User Processes) 기본 값은 다음과 같습니다.

$ ulimit -a | grep processes
max user processes          (-u) 4095

2) CentOS 6.3

이에 반해 CentOS 6.x버전부터는 /etc/security/limit.conf에 nproc에 특별한 설정을 하지 않는 한 1,024를 기본값으로 가집니다.

MySQL InnoDB에서 데이터 1건 변경 시에도 테이블 잠금 현상이 발생할 수 있다!!

gywndi@gmail.com (gywndi) — Sat, 06 Oct 2012 04:36:45 +0000

Overview

MySQL 트랜잭션 Isolation Level로 인한 장애 사전 예방 법 포스팅에서 관련 주제를 다룬 적이 있습니다. InnoDB에서 Create Table .. As Select .. 과 같이 사용하는 경우 테이블 잠금이 발생할 수 있는 상황과 회피할 수 있는 팁이었죠.

테이블 Full-Scan 구문이 실행 시 발생할 수 있는 문제에 관한 것입니다. 하지만 때로는 변경 대상이 1 건이라도 쿼리 타입에 따라 테이블 잠금 같은 현항이 발생할 수도 있습니다.

이번 포스팅에서는 이에 관해 정리해보도록 하겠습니다. ^^

서비스 로직 흐름을 변경하여 DB 튜닝을 해보자!

gywndi@gmail.com (gywndi) — Sun, 23 Sep 2012 07:43:12 +0000

Overview

오래전 메가존(현 혜택존) 서비스를 담당하던 시기, 포인트 관련된 부분에서 심각한 성능 저하 및 유효성 취약 문제가 발생하였습니다. 장비 고도화를 통해 관련 문제를 해결하기에 앞서, 서비스 로직 및 테이블 재구성을 통한 최적화 작업을 통해 문제를 해결하였습니다.

이에 관해 간단하게 소개하도록 하겠습니다.

Problems

다음과 같이 크게 두 가지 문제가 있었습니다.

성능 이슈
- 로그 테이블은 거대한 한 개의 테이블로 구성
- 데이터 누적에 따라 성능이 급격하게 저하
유효성 이슈
- 자바 어플리케이션에서만 유효성 체크, 비 정상적인 사용 존재
- 포인트가 현금처럼 사용될 수 있으므로 반드시 필요함

Solutions

1) 파티셔닝을 통한 성능 최적화

오라클 엔터프라이즈 버전에서는 테이블 파티셔닝을 제공하지만, 아쉽게도 오라클 스탠다드에서는 관련 기능이 없습니다. 즉, 어플리케이션 레벨에서 적당히 데이터 분산을 유도하는 방법 밖에는 없습니다. 데이터를 분산하는 방법으로는 여러가지가 존재하겠지만, 저는 월별로 테이블을 분산 저장하는 방식을 사용하였습니다.

KTH에서 5년간의 생활을 마무리하며..

gywndi@gmail.com (gywndi) — Wed, 12 Sep 2012 15:43:36 +0000

5년동안 재미있게 다녔던 KTH와 이별합니다. 시간이란 참으로 전광석화 순식간에 지나가네요. 입사한 당시가 엊그제 같은데..

대학 마지막 한 학기, 취업 자리를 알아볼 때, 취업 공고에서 가장 눈에 들어왔던 것은 “보라매"라는 지리적인 명칭이었습니다. 강남역에서 병특을 할 때나 역삼역에서 알바를 할 당시 모두 사람에게 치이는 생활 자체에 너무 치가 떨렸기 때문이죠.

일단 거리에서 매혹당한 후에 KTH가 도대체 무슨 일을 하는 회사였는지 찾아봤습니다.

당시 금전적인 가치보다는 제가 얻을 수 있는 경험의 가치를 최우선으로 생각을 해왔었기 때문에, 제가 반드시 거쳐가야할 회사라는 것을 예감했습니다. 포털/컨텐츠/IPTV/게임 등등 온갖 다양한 경험들을 얻을 수 있는 최고의 환경이라고 판단했기 때문이죠.

MariaDB/Galera Cluster 기술 노트!!

gywndi@gmail.com (gywndi) — Wed, 12 Sep 2012 06:38:23 +0000

Overview

MariaDB에서 MariaDB/Galera Cluster 제품군을 새롭게 출시하였습니다.MariaDB/Galera는 MariaDB의 Synchronous 방식으로 동작하는 다중 마스터 클러스터입니다.

MariaDB/Galera Cluster은 Galera 라이브러리를 사용하여 노드 간 데이터 복제를 수행합니다. 물론 아직은 Alpha 버전으로 발표되기는 했지만, 조만간 안정적인 버전이 릴리즈 되면 상당한 물건이 될만한 놈입니다.

오늘은 이에 관해 간단하게 리뷰를 하겠습니다.

Feature & Benefits

먼저 MariaDB/Galera Cluster의 특징은 다음과 같이 몇 가지로 나눠볼 수 있습니다.

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

출처 : http://www.percona.com/doc/percona-xtradb-cluster/_images/cluster-diagram1.png

MySQL 성능 최적화를 위한 몇 가지 팁!!

gywndi@gmail.com (gywndi) — Tue, 11 Sep 2012 07:25:17 +0000

Overview

트위터에서 우연히 성능 관련 가벼운 아는척(?)을 시작으로 일이 커지고 말았네요. ^^;; 성능 관련된 트윗을 보고 몇 가지 코멘트만 한다는 것이.. ㅎㄷㄷ한 멘션이 되고 말았습니다.

그래서 부족하나마, MySQL 성능 최적화 시 본능적으로 이행하는 몇 가지를 정리해보겠습니다.

Global Variable

성능과 연관이 되는 몇 가지 파라메터 변수는 반드시 체크를 하시기 바랍니다. MySQL에서 주로 InnoDB를 사용하는 상태라면 innodb_buffer_pool_size, innodb_log_file_size, innodb_log_files_in_group, innodb_flush_log_at_trx_commit, innodb_doublewrite, sync_binlog 정도가 성능에 직접적인 영향을 미치는 요소라고 볼 수 있습니다.

innodb_buffer_pool_size
InnoDB에게 할당하는 버퍼 사이즈로 50~60%가 적당하며, 지나치게 많이 할당하면 Swap이 발생할 수 있습니다.
innodb_log_file_size
트랜잭션 로그를 기록하는 파일 사이즈이며, 128MB ~ 256MB가 적당합니다.
innodb_log_files_in_group
트랜잭션 로그 파일 개수로 3개로 설정합니다.
innodb_flush_log_at_trx_commit
서비스 정책에 따라 다르게 설정하겠지만, 저는 일반적으로 2값으로 세팅합니다.
- 0: 초당 1회씩 트랜잭션 로그 파일(innodb_log_file)에 기록
- 1: 트랜잭션 커밋 시 로그 파일과 데이터 파일에 기록
- 2: 트랜잭션 커밋 시 로그 파일에만 기록, 매초 데이터 파일에 기록
innodb_doublewrite
이중으로 쓰기 버퍼를 사용하는지 여부를 설정하는 변수로 활성화 시 innodb_doublewrite 공간에 기록 후 데이터 저장합니다. 저는 활성화합니다.
sync_binlog
트랜잭션 커밋 시 바이너리 로그에 기록할 것인지에 관한 설정이며, 저는 비활성 처리합니다.

참고로 innodb_buffer_pool_size를 32G 메모리 서버에서 24G로 할당한 적이 있는데, SQL트래픽이 많아짐에 따라 Swap이 발생하더군요. 버퍼풀에는 대략 한 시간 정도 Active한 데이터와 인덱스를 담을 수 있는 사이징이라면 적절할 것 같습니다.

SQL 작성 시 묵시적 형 변환 함정에 빠지지 말자!!

gywndi@gmail.com (gywndi) — Fri, 07 Sep 2012 04:54:21 +0000

Overview

정말 오랜만에 포스팅합니다. 그동안 개인적인 일이 조금 있어서.. 조금 소홀이 했었네요. ^^

오늘은 묵시적인 형 변한에 대해서 설명을 드릴까 합니다. 서비스 쿼리를 작성하다보면, 이상이 없는 데 성능이 이상하게 안좋은 경우가 있습니다. 명시적으로 쿼리 내용을 볼 수 있다면 괜찮겠지만, 어플리케이션에서 변수를 바인딩하여 SQL을 실행하는 경우는 더욱 찾기가 어렵습니다.

묵시적 형 변환은 단순히 MySQL 뿐만 아니라 Oracle, MS-SQL 등 다른 DBMS에서도 반드시 주의를 해야하는 사항입니다.

묵시적 형 변환이란?

묵시적 형 변환이란 조건절 데이터 타입이 다르면 우선 순위가 있는 쪽으로 형 변환이 내부적으로 발생하는 것을 말합니다.

아마존의 가상 RDBMS인 Amazon RDS의 특성 몇 가지

gywndi@gmail.com (gywndi) — Fri, 10 Aug 2012 05:26:37 +0000

Overview

지난 해 말 글로벌 서비스를 겨냥하여 Amazon 가상 플랫폼 상에 인증 서비스를 오픈하였고, 올해 초에는 푸딩.투 서비스 또한 런칭하여 서비스 중에 있습니다.

글로벌 서비스를 위한 저장소로는 아마존에서 제공하는 가상 관계형 DBMS인 Amazon RDS를 사용 중입니다.

이번 포스팅에서는 Amazon RDS에 대한 특성 몇 가지를 설명 드리겠습니다.

Virtual Database Instance

Amazon RDS는 Virtual Database Instance입니다.

DBMS는 데이터를 처리하는 미들웨어이고, 미들웨어는 OS 기반 위에서 동작합니다. 일반적인 상황이라면 OS에 접근하여 그에 맞게 DBMS를 설치하고, 관련 파라메터도 정의를 해야만 하지만, 모든 것이 “웹 콘솔” 상에서 간단하게 처리합니다.

Maria 2탄 – 진화하는 Maria, 함께하는 MySQL!!

gywndi@gmail.com (gywndi) — Tue, 17 Jul 2012 02:13:57 +0000

Overview

MySQL 오픈 소스 진영은 더이상 단순 데이터 처리에만 강한 DBMS이기를 거부합니다. 이제는 대용량 처리에 적합하도록 탈바꿈 중입니다.

지금까지 MySQL에서는 단일 쓰레드로 Nested Loop 방식으로 쿼리를 처리하였기 때문에, 조인 건 수가 대형화될 수록 성능이 급속도로 악화되었습니다.

MariaDB는 5.3버전부터 DB 엔진과 스토리지 엔진 간의 데이터 전송이 개선되었고, 조인 시 추가적인 블록 기반의 조인 알고리즘을 제공합니다. 물론 MySQL도 5.6버전부터는 관련 기능을 어느정도 지원합니다.

변화하는 MariaDB에 대해 몇 가지 소개하도록 하겠습니다.

Disk access optimization

1) Index Condition Pushdown

MySQL/MariaDB는 구조적으로 DB 엔진과 스토리지 엔진 역할이 명확하게 구분됩니다.

MySQL에서 Replication Driver 사용 시 장애 취약점 리포트

gywndi@gmail.com (gywndi) — Fri, 06 Jul 2012 03:19:24 +0000

Overview

MySQL에서 슬레이브 부하 분산을 하는 방안으로 Replication Driver 기능을 제공하는 jdbc 내부적으로 지원합니다. Replication Driver를 사용하면 상당히 간단하게 마스터/슬레이브 활용을 할 수 있고 어느정도의 Failover는 가능합니다.

하지만 서비스 적용을 위해 Failover테스트 도중 치명적인 문제점이 발생하였습니다. 관련 포스팅을 하도록 하겠습니다. ^^

사용 방법

Replication Driver 사용 시 ReadOnly 옵션을 True/False 상태에 따라 마스터/슬레이브 장비를 선택합니다.

아래 그림처럼 ReadOnly이 False이면 마스터 장비에 쿼리를 날리고, True이면 슬레이브에 쿼리를 날리는 구조입니다. 그리고 로드발란싱 기능을 사용하면, 슬레이브 서버 부하 분산할 수 있습니다.

메모리 기반 RDBMS, MemSQL을 알아봅시다

gywndi@gmail.com (gywndi) — Wed, 27 Jun 2012 10:18:56 +0000

MemSQL이란?

MemSQL은 디스크 병목을 최소화하기 위해 만들어진 메모리 기반의 관계형 DBMS입니다. 메모리 기반으로 데이터 처리가 이루어지기 때문에, 엄청난 속도로 Read/Write이 가능하며, 기존의 NoSQL 또는 캐시로만 가능했던 퍼포먼스 향상이 있습니다. 실제로 디스크 기반 DBMS 대비 약 30배 이상의 성능 향상이 있다고 하니, 놀라울 따름입니다.

최근 들어 메모리 가격이 하루가 다르게 저렴해지고 있기 때문에 메모리 사이즈를 최대한 늘려서 가격 대비 성능 비를 최대로 이끌어 내는 DB입니다.

MemSQL 특징

1) 강력한 SQL기반의 통신

SQL 기반으로 통신하며, MySQL API를 따릅니다. 그렇기 때문에 기존 MySQL을 사용하는 서비스 경우 로직 변경이 불필요하다고 합니다. 하다못해 라이브러리 또한 기존 MySQL에서 사용하던 그대로 재사용해도 상관 없습니다.

Maria 1탄 – MySQL의 쌍둥이 형제 MariaDB를 소개합니다.

gywndi@gmail.com (gywndi) — Mon, 18 Jun 2012 10:27:47 +0000

MariaDB란?

MySQL이 Sun Microsystems로 넘어가면서 당시 MySQL AB 출신들이 따로 나와서 MySQL을 기반으로 한 다른 오픈 소스 기반의 DBMS를 배포했다고 합니다. 바로 MariaDB가 그것이며 MySQL과 유전 정보를 그대로 고수한 진짜 오픈 소스 기반의 DBMS입니다.

현재 Monty Program AB와 MariaDB Community에서 개발하고 있으며, MySQL과 기본적으로 구조 및 사용 방법 등 모두 동일합니다. (동일 소스에서 개발되고 있으니 당연한 말입니다.)

Monty Program AB에 따르면 많은 기능들이 MariaDB에서 먼저 구현을 하고 그 후 MySQL에도 반영이 된다고 하는데, 마치 CentOS와 Redhat 리눅스 관계 같다는 생각이 듭니다.^^

MySQL에서 Temporary Table을 활용한 데이터 질의..그 효과는?

gywndi@gmail.com (gywndi) — Fri, 15 Jun 2012 06:15:02 +0000

Overview

오늘은 Temporary Table에 관해 포스팅을 하겠습니다. Select및 Update 등을 이따금씩 Temporary Table을 활용하여 수행하는 경우가 있습니다. 동시에 많은 데이터를 일괄 변경하는 것에서는 분명 강점이 있을 것이라 판단되는데, 어떤 상황에서 적절하게 사용하는 것이 좋을까요? 관련 성능 벤치마크 결과를 공개하겠습니다.

Environment

테이블에는 약 1000만 건 데이터가 존재하며, Primary Key외에는 추가 인덱스는 생성하지 않았습니다. 서로 동등하게 빠른 데이터 접근이 가능하다는 가정 하에 PK외 인덱스에서 발생할 수 있는 성능 저하 요소를 배제하기 위해서 입니다.^^

Amazon RDS에서 유실된 데이터 복원하기

gywndi@gmail.com (gywndi) — Tue, 05 Jun 2012 09:48:52 +0000

Overview

**Amazon Relational Database Service(Amazon RDS)**는 클라우드에서 관계형 데이터베이스를 쉽게 설치, 운영 및 확장할 수 있는 서비스입니다.

자원을 유연하게 배분할 수 있는 이점이 있는 클라우드이지만, 모든 서비스는 결국에는 사람 손을 거쳐야 하고, 때로는 인재로 인한 데이터 유실 사고가 발생할 수 있습니다.

사용이 편리하게 구현되어 있지만, 사용자에게 제공하는 권한 또한 상당히 제약적(인스턴스 관리자일지라도)입니다.

오늘은 Amazon RDS 상에서 데이터 유실 장애가 발생한 경우 대처할 수 있는 방안에 관하여 포스팅하도록 하겠습니다. (기준은 MySQL이나 타 DBMS도 큰 차이가 없을 것 같네요^^)

Tumblr에서는 MySQL로 어떻게 대용량 데이터를 관리하였을까?

gywndi@gmail.com (gywndi) — Fri, 25 May 2012 06:17:13 +0000

Overview

트위터의 새로운 분산 관리 라이브러리 Gizzard를 소개합니다.를 알아보던 당시 부사수 임창선님과 진행했던 또 다른 해외 사례 Tumblr를 정리해보았습니다.

Tumblr는 국내에서는 사용자가 많지는 않지만, Twitter 정도의 트래픽을 자랑하는 Micro Blog 서비스입니다. 하루 평규 5억 이상의 PV가 나오고, 초당 4만 건 이상 Request가 나오며, 하루 평균 3TB 이상의 데이터를 쌓는다고 하니 엄청난 서비스인 것은 틀림 없습니다.

이정도 데이터를 관리하기 위해서 수 천대 이상의 서비스를 운영한다고 하는데, 데이터 관리를 MySQL을 활용하여 제공한다고 합니다. 그렇다면 MySQL로 어떻게 대용량 데이터를 멋지게 다뤘을까요?

MySQL에서 테이블 스키마를 “무중단”으로 변경해보자!!

gywndi@gmail.com (gywndi) — Tue, 22 May 2012 09:47:10 +0000

Overview

MySQL은 단순 쿼리 처리 능력은 탁월하나 테이블 스키마 변경 시에는 상당히 불편합니다. 일단 테이블 스키마 변경 구문을 실행하면 임시 테이블 생성 후 데이터를 복사하고, 데이터를 복사하는 동안에는 테이블에 READ Lock이 발생하여 데이터 변경 작업을 수행하지 못합니다. (Table Lock이 걸리죠.)

이 같은 현상은 인덱스, 칼럼 추가/삭제 뿐만 아니라 캐릭터셋 변경 시에도 동일하게 발생합니다. (최근 5.5 버전에서는 인덱스 추가/삭제에서는 임시 테이블을 생성하지 않습니다.)

얼마 전 서비스 요구 사항 중 테이블 칼럼을 무중단으로 변경하는 것이 있었는데, 이에 관해 정리 드리겠습니다.^^

MySQL 트랜잭션 Isolation Level로 인한 장애 사전 예방 법

gywndi@gmail.com (gywndi) — Wed, 16 May 2012 00:48:59 +0000

Overview

MySQL에서 전체 데이터를 Scan 하는 쿼리를 질의하여 서비스에 큰 영향이 발생할 수 있습니다.

InnoDB 스토리지 엔진의 기본 Isolation Level이 REPEATABLE-READ이기 때문에 발생하는 현상인데, 이것은 세션 변수 일부를 변경하여 문제를 사전에 해결할 수 있습니다.

얼마 전 이와 비슷한 장애가 발생하여 원인 분석 및 해결 방안을 포스팅합니다.

Symptoms

Transaction Isolation Level이 REPEATABLE-READ(MySQL Default) 상태에서 Insert into Select 혹은 Create Table As Select 로 전체 테이블 참조 쿼리 실행 시 참조 테이블에 데이터 변경 작업이 대기 상태에 빠지는 현상이 있습니다.

MySQL 성능 죽이는 잘못된 쿼리 습관

gywndi@gmail.com (gywndi) — Fri, 11 May 2012 06:12:07 +0000

Overview

안정적인 서비스 유지를 위해서는 쿼리 작성이 상당히 중요합니다. 잘못된 쿼리 하나가 전체적인 퍼포먼스를 크게 저해하기도 하고 최악의 경우 장애 상황까지 치닫기 때문이죠

단일 코어에서 Nested Loop Join으로 데이터를 처리하는 MySQL 특성 상 쿼리 구문에 큰 영향을 받습니다. (반드시 알아야할 MySQL 특징 세 가지 참고)

그래서 오늘은 쿼리 작성 시 기피해야 하는 사항 세 가지정도 골라봅니다.

Case 1

SELECT @RNUM:=@RNUM+1 AS RNUM, ROW.*
FROM (SELECT @RNUM:=0) R,
(
    SELECT
        M.MASTER_NO,
        M.TITLE,
        MI.PATH,
        M.REGDATE,
        CM.TYPE
    FROM MAIN AS M
    LEFT OUTER JOIN TAB01 AS MI
        ON M.MASTER_NO = MI.MASTER_NO
    INNER JOIN TAB02      AS CM
        ON M.MASTER_NO = CM.MASTER_NO
    WHERE M.DEL_YN = 'N'
    ORDER BY M.MASTER_NO DESC
) ROW
LIMIT 10000, 10

MySQL 사용 시 주의해야 할 몇 가지

gywndi@gmail.com (gywndi) — Fri, 04 May 2012 07:27:34 +0000

안녕하세요. 오늘은 MySQL을 사용할 때 지켜야할 사항 몇 가지 정리합니다.

나름 혼자서 정리를 해 본 것들인데, MySQL로 서비스를 준비 중이라면 한 번쯤은 고려를 해봤으면 하는 내용입니다.^^

테이블 설계 시 유의 사항

1. 반드시 Primary Key를 정의하고 최대한 작은 데이터 타입을 선정한다.

로그 성 테이블에도 기본적으로 PK 생성을 원칙으로 함
InnoDB에서 PK는 인덱스와 밀접한 관계를 가지므로 최대한 작은 데이터 타입을 가지도록 유지

2. 테이블 Primary Key는 auto_increment를 사용한다.

InnoDB에서는 기본 키 순서로 데이터가 저장되므로, Random PK 저장 시 불필요한 DISK I/O가 발생 가능
InnoDB의 PK는 절대 갱신되지 않도록 유지
(갱신 시 갱신된 행 이후 데이터를 하나씩 새 위치로 옮겨야 함)

3. 데이터 타입은 최대한 작게 설계한다.

시간정보는 MySQL데이터 타입 date/datetime/timestamp 활용
IP는 INET_ATON(‘IP’), INET_NTOA(int) 함수를 활용
정수 타입으로 저장 가능한 문자열 패턴은 최대한 정수 타입으로 저장

4. 테이블 내 모든 필드에 NOT NULL 속성을 추가한다.

NULL을 유지를 위한 추가 비용 발생
(NULL 허용 칼럼을 인덱싱 할 때 항목마다 한 바이트 씩 더 소요)

5. Partitioning을 적절하게 고려하여 데이터를 물리적으로 구분한다.

데이터 및 인덱스 파일이 커질수록 성능이 저하되므로Partitioning 유도
PK 존재 시 PK 내부에 반드시 Partitioning 조건이 포함되어야 함

인덱스 설계 시 유의 사항

1. 인덱스 개수를 최소화 한다.

현재 인덱스로 Range Scan이 가능한지 여부를 사전에 체크
인덱스도 서버 자원을 소모하는 자료구조이므로 성능에 영향을 줌

2. 인덱스 칼럼은 분포도를 고려하여 선정한다.

인덱스 칼럼 데이터의 중복이 줄어들수록 인덱스는 최대의 효과를 가짐
하단 쿼리 결과 값이 1에 가까울수록(0.9이상 권고) 인덱스 컬럼으로 적합함

SELECT count(distinct INDEX_COLUMN)/count(*)
FROM TABLE;

3. 커버링 인덱스(Covering Index)를 활용한다.

쿼리 조건이 인덱스 안에 포함된 경우 인덱스에서만 연산 유도
인덱스는 일반적으로 행 전체보다 작으므로 불필요한 Disk I/O 회피 가능
MySQL에서 커버링 인덱스로 쿼리 성능을 높여보자!! 편 참고

4. 스토리지 엔진 별 INDEX 특성을 정확히 인지한다.

InnoDB에서 데이터는 PK 순서로 저장되고, 인덱스는 PK를 Value로 가짐
MyISAM은 PK와 일반 인덱스의 구조는 동일하나, Prefix 압축 인덱스를 사용
(MyISAM 엔진에서 ORDER BY 시 DESC는 가급적 지양)

5. 문자열을 인덱싱 시 Prefix 인덱스 활용한다.

긴 문자열 경우 Prefix 인덱스(앞 자리 몇 글자만 인덱싱)를 적용

CREATE INDEX IDX01 ON TAB1(COL(4), COL(4))

Prifix Size는 앞 글자 분포도에 따라 적절하게 설정
(하단 결과가 1에 가까울 수록 최적의 성능 유지, 0.9이상 권고)

  SELECT count(distinct LEFT(INDEX_COLUMN,3))/count(*)
FROM TABLE;

6. CRC32함수 및 Trigger를 활용하여 인덱스 생성한다.

URL/Email같이 문자 길이기 긴 경우 유용
INSERT/UPDATE 발생 시 Trigger로 CRC32 함수 실행 결과 값을 인덱싱
CRC32 결과값을 저장할 칼럼 추가 및 인덱스 생성

alter table user_tbl add email_crc int unsigned not null;
create index idx01_email_crc on user_tbl (email_crc);

Insert Trigger 생성

create trigger trg_user_tbl_insert
before insert on user_tbl
for each row
begin
  set new.email_crc = crc32(lower(trim(new.email)));
end$

Update Trigger 생성

create trigger trg_user_tbl_update
before update on user_tbl
for each row
begin
  if old.email &lt;&gt; new.email then
      set new.email_crc = crc32(lower(trim(new.email)));
  end if;
end$

검색 쿼리

select *
from user_tbl
where email_crc = crc32(lower(trim('mail@domain.com')))
and email= 'mail@domain.com'

CRC32 결과가 중복되어도, email값을 직접 비교하는 부분에서 중복이 제거됩니다.

MySQL DB 데이터 이관 자동화 구현하기

gywndi@gmail.com (gywndi) — Fri, 27 Apr 2012 07:15:33 +0000

Overview

DB를 운영하다 보면, 한 개의 MySQL 인스턴스에 여러 개의 데이터베이스를 모아서 보관하는 경우가 있습니다. 그러면 가끔 DB명이 충돌나는 경우도 발생하죠. 오늘은 Dump/Rename/Import 등 모든 프로세스를 자동화할 수 있는 방안을 제시해 봅니다.

요구사항

무조건 자동으로 동작해야 하고, 기억력이 나쁜 제가 나중에 사용하기 쉽게 재사용성도 좋아야한다는 것입니다. 그리고 사용 방법을 잊어도 쉽게 상기할 수 있는 방안도 있어야겠죠.ㅋ (제가 정한 요구사항입니다. ㅋ)

모든 프로세스는 자동화되어야 한다.
스크립트 수정 없이 재사용이 가능해야 한다.
사용 매뉴얼이 있어야 한다.

자동화 구현

프로세스 순서는 다음과 같고 2단계부터는 파이프( | )로 한번에 처리합니다.

MySQL에서 커버링 인덱스로 쿼리 성능을 높여보자!!

gywndi@gmail.com (gywndi) — Thu, 19 Apr 2012 15:21:20 +0000

안녕하세요. 오늘 짧지만 재미있는 내용을 하나 공유할까 합니다.

커버링 인덱스(Covering Index)라는 내용인데, 대용량 데이터 처리 시 적절하게 커버링 인덱스를 활용하여 쿼리를 작성하면 성능을 상당 부분 높일 수 있습니다.

커버링 인덱스란?

커버링 인덱스란 원하는 데이터를 인덱스에서만 추출할 수 있는 인덱스를 의미합니다. B-Tree 스캔만으로 원하는 데이터를 가져올 수 있으며, 칼럼을 읽기 위해 굳이 데이터 블록을 보지 않아도 됩니다.

인덱스는 행 전체 크기보다 훨씬 작으며, 인덱스 값에 따라 정렬이 되기 때문에 Sequential Read 접근할 수 있기 때문에, 커버링 인덱스를 사용하면 결과적으로 쿼리 성능을 비약적으로 올릴 수 있습니다.

DB Link와 Export/Import를 활용한 데이터 이관 성능 리포트

gywndi@gmail.com (gywndi) — Fri, 13 Apr 2012 07:41:39 +0000

안녕하세요. 한동안 MySQL에 빠져 있다가, 최근 Oracle 데이터 이관 작업 도중 재미난 사례 공유 합니다. DB Link를 통한 CTAS(Create Table As Select)와 Export/Import를 통한 데이터 이관 비교입니다.

서비스 요구 사항

서비스 DBMS 버전 : Oracle 9i
전체 데이터 파일 사이즈 : 120G (인덱스 포함)
타겟 테이블 데이터 사이즈 : 26G (인덱스 제외)
네트워크 속도 : 100Mbps (max: 12.5MB/s)
일 1회 현재 서비스 데이터 동기화 수행
모든 작업은 자동화하여 운영 이슈 최소화

위 환경을 고려하였을 때, 전체 데이터 파일 Copy는 동기화 시간 및 스토리지 낭비 요소가, Archive Log 활용하기에는 운영 이슈가 존재했습니다.

디스크 병목 현상에 따른 DB 성능 리포트

gywndi@gmail.com (gywndi) — Sun, 18 Mar 2012 10:05:35 +0000

Overview

어느 시스템에서도 병목 현상은 어딘가에 있습니다. DBMS 또한 CPU, Memory, Disk로 구성된 하나의 시스템이기 때문에 당연히 특정 구역에서 병목현상이 발생할 수 있죠. 오늘은 Disk에서 발생하는 병목에 관해서 말씀드리겠습니다.

Memory Processing

Permanent Link: 디스크 배열(RAID)에 따른 DB 성능 비교 에서, 메모리가 충분하면 아래와 같다는 그래프를 보여드렸습니다.

어떤 경우든 메모리에만 연산이 가능하다면, CPU자원을 거의 활용 가능하다고 할 수 있죠. 그러나 만약 디스크 I/O가 발생하는 순간부터 CPU는 전혀 연산하지 않는 현상이 발생합니다. 바로 디스크 I/O Wait 으로 인한 시스템 병목 현상 발생입니다.

디스크 배열(RAID)에 따른 DB 성능 비교

gywndi@gmail.com (gywndi) — Sun, 18 Mar 2012 09:43:46 +0000

Overview

MySQL DBMS 하드웨어 구성 시 어떠한 정책으로 움직이는 것이 가장 효율적일지, 메모리/디스크 설정을 변경하여 테스트를 진행하였습니다. 디스크는 RAID 레벨을 변경하였고, innodb_buffer_pool을 조정함으로써 메모리 환경을 구성하였습니다. 서비스 특성에 따라 하드웨어 구성을 달리함으로써, 장비를 더욱더 효율적으로 사용할 수 있을 것으로 기대됩니다.^^

디스크배열(RAID)란?

RAID란 Redundant Array of Inexpensive Disks의 약자로 디스크를 여러장 묶어서, 데이터 중복성 및 성능 향상을 유도할 수 있는 기법입니다. RAID 기법은 참으로 많이 있으나, 일반적으로 실무에서는 RAID0, RAID1, RAID5, RAID10또는 RAID01을 많이 사용합니다.

MySQL Replication 이해(3) – 활용

gywndi@gmail.com (gywndi) — Sat, 17 Mar 2012 09:19:07 +0000

Overview

MySQL Replication 시리즈 마지막 3탄, 활용에 관한 포스트입니다. 앞 선 시리즈 MySQL Replication 이해(1) – 개념와 MySQL Replication 이해(2) – 구성에서 기본적인 개념과 구성을 다뤘다면, 이 자리에서는 실제적으로 어떤 분야에 활용할 수 있는지 설명드리겠습니다.

Scale Out
High Availability
Data Partitioning

자, 그럼 시작해볼까요?

Scale out

MySQL Replication이 가장 많이 활용되는 분야입니다.
MySQL Replication은 READ관련 Scale out만 가능합니다. 만약 WRITE 이슈가 있다면, MySQL 레벨에서는 Scale out이 불가합니다. 특히나 Replication 운영 시 마스터 트래픽이 과도하게 발생하면, Master와 Slave 간 데이터 동기화 지연 현상이 발생합니다. 반드시 알아야할 MySQL 특징 세 가지 내용을 읽어보시면 이해가 조금더 수훨하겠네요.^^

트위터의 새로운 분산 관리 라이브러리 Gizzard를 소개합니다.

gywndi@gmail.com (gywndi) — Fri, 09 Mar 2012 04:45:12 +0000

Overview

바로 이전 하루 2.5억 트윗을 저장하는 트위터의 새로운 저장 스토어 포스팅에서 트위터의 새로운 저장 스토어에 관해서 전반적으로 설명 드렸는데요, 이번에는 그 중 Gizzard에 관해서 심층 분석(?)을 해볼까합니다.

Gizzard는 트위터에서 데이터를 분산 및 복제 관리하기 위한 자체 개발 프레임워크입니다. 클라이언트와 서버 사이에 위치하며 모든 데이터 요청을 처리하는 구조입니다. Gizzard 관련 몇 가지 키워드는 아래와 같습니다.

분산 관리(Sharding), 분할(Partitioning), 복제(Replication)
부하분산(Load-Balancing)
장애복구(Fail-Over)
멱등성(idempotent), 가환성(commutative)
- 멱등성 : 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질
- 가환성 : 연산의 순서를 바꾸어도 그 결과가 변하지 않는 일

분산 관리(Sharding)이란?

과거에는 서비스 성능 저하가 발생하면 곧바로 해당 서버에 CPU또는 Memory 사이즈를 증설하여 성능 이슈를 해결하였습니다. 하지만, 최근 Web 서비스에서 데이터 사이즈가 급증하여, 더 이상은 서버 성능 고도화만으로는 한계가 있기 때문에, 다수 장비에 데이터를 분산 위치(Data Sharding)하여 데이터를 처리하는 움직임이 일반화되고 있습니다.

하루 2.5억 트윗을 저장하는 트위터의 새로운 저장 스토어

gywndi@gmail.com (gywndi) — Thu, 08 Mar 2012 01:46:30 +0000

Overview

트위터는 하루 평균 2.5억 건의 트윗을 저장한다고 합니다. 과거 트위터는 날짜 기준으로 데이터를 분할 관리하여 저장을 하였고, 대략 3주에 한번씩 서버를 추가하여 Scale-out 하였습니다.

하지만 이 방식에는 다음과 같은 문제가 있었습니다.

부하 분산
고비용
복잡한 프로세스

문제를 해결하기 위해서 트위터에서 New Tweet Store를 고안했다고 합니다.

자, 그럼 기존 문제점부터 차근차근 알아보도록 합시다^^;

Problems

부하 분산(Load Balancing)
날짜 기준으로 데이터를 나눠서 분산 저장 및 관리하기 때문에, 시간이 지날수록 과거 데이터 조회 건수는 비약적으로 낮아집니다. 특히 대부분의 데이터 조회 요청은 현재 시각 기준으로 들어오기 때문에, 데이터 읽기 HOTSPOT이 발생할 수 밖에 없습니다.

MySQL Replication 이해(2) – 구성

gywndi@gmail.com (gywndi) — Fri, 10 Feb 2012 06:16:35 +0000

Overview

MySQL Replication 개념에 이어, 이번에는 실 구성에 관한 내용입니다.
각 서버 구성 방법은 리눅스에 MySQL 설치하기 편을 참고하시기 바랍니다.

시작에 앞서서 Server_id는 다른 숫자로 설정하세요^^.

Replication 구성은 다음 세 단계를 거쳐서 수행됩니다.

DB 유저 생성
DB 데이터 동기화(셋 중 택 1)
- DB Data File Copy
- MySQL Dump (All Lock)
- Export/Import (Single Transaction)
리플리케이션 시작

1. DB 유저 생성

복제 데이터 전송을 위한 리플리케이션 권한의 DB 유저를 마스터에 생성합니다. 각 슬레이브 IO 쓰레드들은 추가된 DB 유저를 통해 데이터를 받습니다.

MySQL Table Lock에 관한 이해

gywndi@gmail.com (gywndi) — Mon, 30 Jan 2012 06:01:51 +0000

Overview

Table Lock 스토리지 엔진 사용 시 반드시 알아야할 사항을 정리 드리겠습니다.

근래에는 물론 InnoDB가 아~주 많이 사용되고 있겠지만, 여전히 서비스에서는 MyISAM이 쓰이고 있습니다. MyISAM은 MySQL의 대표적인 스토리지 엔진이면서 내부적으로는 Table Lock으로 동작합니다.

관련 스토리지 엔진에 관한 설명은 MySQL특성을 정리한 반드시 알아야할 MySQL 특징 세 가지 포스팅을 참고하시면, 간단한 비교를 하실 수 있습니다. 자 그럼 Table Lock 스토리지 엔진 사용 시 반드시 알아야할 사항을 정리 드리겠습니다.

Table Lock 이해

MySQL에서 Table Lock은 다음 기준에 의해서 부여됩니다.

[H3 2011] 대형사이트 구축을 위한 MySQL 튜닝전략

gywndi@gmail.com (gywndi) — Mon, 02 Jan 2012 03:22:07 +0000

작년 11월 30일 KTH에서 주최한 H3 컨퍼런스에서 DB 관련 발표 동영상입니다.

MySQL Replication 이해(1) – 개념

gywndi@gmail.com (gywndi) — Wed, 28 Dec 2011 05:14:02 +0000

Overview

오늘은 조금더 제너럴한 주제를 가지고 정리를 할까합니다.
바로 MySQL Replication 입니다. MySQL Community에서 유일하게 HA 또는 분산 구성을 할 수 있는 유일한 기능입니다. 물론 MySQL+DRBD 구성와 같이 HA를 구성하는 방법도 있습니다만, MySQL 제품이 아니므로 스킵~!

먼저 Replication에 대해 간략하게 말씀 드리겠습니다.

MySQL Replication이란?

MySQL Replication이란 말 그대로 복제입니다. 영어 사전에 나온 듯한 DNA는 아니지만 데이터를 “물리적으로 다른 서버의 저장 공간” 안에 동일한 데이터를 복사하는 기술이죠.

다음 그림은 MySQL Replication을 가장 간단하게 나타낸 그림입니다. 데이터 변경을 마스터 장비에서만 수행하기 때문에 마스터 장애 시에는 전체 노드에 데이터 쓰기 작업이 불가능한 한계가 있습니다.

리눅스에 MySQL 설치하기(CentOS 5.6)

gywndi@gmail.com (gywndi) — Tue, 20 Dec 2011 09:26:13 +0000

MySQL DBMS 를 설치할 때 제가 적용하는 내용을 공유합니다. root 계정으로 설치 준비를 하고, mysql 계정으로 DB를 구동합니다.

일단 하단 내용들은 root계정으로 수행을 합니다.

OS 계정 추가

다음과 같이 dba 그룹을 추가하고 그 밑에 mysql 계정을 추가합니다.

groupadd -g 600 dba
useradd -g 600 -u 605 mysql
passwd mysql

Linux 설정 변경

세션 Limit 를 설정합니다.

vi /etc/security/limits.conf
##하단 내용 추가
mysql            soft    nproc  8192
mysql            hard    nproc  16384
mysql            soft    nofile 8192
mysql            hard    nofile 65536

OS에서 limits.conf 파일을 읽어들이도록 설정합니다. 없으면 생성합니다.

CentOS6 에 Apache+PHP+MySQL 구성

gywndi@gmail.com (gywndi) — Sun, 11 Dec 2011 12:44:24 +0000

서버를 구성하면서 사용한 스크립트..
나중에 재사용을 위해서 블로그에 올리자!!
Apache -> MySQL -> PHP 순으로 설치!

모든 설치 파일 혹은 소스는 하단 디렉토리에 위치한다.

Apache: http://apache.org
MySQL : http://dev.mysql.com
PHP : http://php.net

최근 릴리즈 버전을 /usr/local/src에 다운로드 한다.

Apache 설치

## 컴파일 및 설치
cd /usr/local/src
tar xvzf httpd-2.2.14.tar.gz
cd httpd-2.2.21
./configure --prefix=/usr/local/apache \
--enable-mods-shared=all \
--enable-so \
--enable-module=rewrite
make
make install

## 관리를 위해 Symbolic Link로 연결
cd /usr/local
mv apache apache-2.2.21
ln -s apache-2.2.21 apache

MySQL 설치

## 압축 해제 설치
tar xzvf mysql-5.5.19-linux2.6-x86_64.tar.gz
mv mysql-5.5.19-linux2.6-x86_64 /usr/local/
cd /usr/local

## 관리를 위해 Symbolic Link로 연결
ln -s mysql-5.5.19-linux2.6-x86_64 mysql

자세한 설치는 리눅스에 MySQL 설치하기(CentOS 5.6) 편을 참고하세요.

옴 마니 밧메 훔

gywndi@gmail.com (gywndi) — Tue, 06 Dec 2011 15:00:50 +0000

다음 이라는 말로 놓치는 수 많은 경험들..

당신들은 언제나 다음을 이야기 하죠. 하지만 다음이란 없어요. 내 날을 잘 들어요. 우리도 항상 다음으로 미루며 살아왔지만, 어느 날 갑자기 나라를 빼앗기고는 모든 것이 달라졌어요. 집을 잃고, 가족들이 뿔뿔이 흩어지고, 우리가 뒤로 미루기만 하던 일들을 하나도 할 수 없게 되었어요.

지구별 여행자 옴 마니 밧메 훔 내용 중

지금을 살고 있는 나에게 과연 다음이라는 것이 있을까?
내 자신을 돌아보게 해주는 나를 바늘로 찌르는 듯한 한마디..

반드시 알아야할 MySQL 특징 세 가지

gywndi@gmail.com (gywndi) — Mon, 05 Dec 2011 06:20:17 +0000

Overview

MySQL 요구가 전보다 급증하고 있습니다. 이제 친숙해서 사용하는 간단한 소용량 DBMS 이 아닌, 많은 대형 업체에서도 사용되고 있기 때문에 많은 이슈가 되고 있습니다. 트위터, 페이스북, 구글, 야후 뿐만 아니라 최근들어 SNS 열풍으로 국내에도 MySQL 관련하여 엄청난 붐이 시작되려는 찰나인 듯 하네요.

KTH에 입사를 한 당시에 주력 DB는 Oracle이었습니다. 그러나라이선스 비용 문제로 주력 DB 선정을 위한 저울질이 시작되었고, 그중 일반 개발자에게도 친숙한 MySQL을 선택했습니다.

MySQL 세가지 특성?

MySQL 3.X 버전으로 광고 시스템을 만든 적이 있습니다. 꽤나 오래된 얘기..

gywndi의 블로그 오픈!!

gywndi@gmail.com (gywndi) — Fri, 02 Dec 2011 04:51:05 +0000

2011.11.30

대형사이트 구축을 위한 MySQL 튜닝전략 세션 진행 블로그 필요성을 절감하여 설치형 블로그에 관해 수색!
그리고 Word Press로 결정!
집 개인 서버에 설치하자!

2011.12.01

URL이 안 이뻐서 mod_rewrite 재설정.
브라우저 캐시 때문에 삽질 100번 =_=;; 어이없는 삽질!
허탈한 마음에 연로하신 분들 술자리에 슬쩍 엉덩이를 밀어넣다.
사장님 죄송해요. 오늘 일 안했어요^^;;

2011.12.02 09:00

H3행사, DB프로젝트, 장애처리.. 쏟아지는 업무 요청..
그래서 쉬고 싶어서 휴가를 냈다. 여기는 집 앞 파스쿠찌..
어제 대충 세팅한 블로그가 맘에 안든다! 다 때려쳐!
다시 만들자!

About me

gywndi@gmail.com (gywndi) — Mon, 01 Jan 0001 00:00:00 +0000

나 이런사람이야!

소심해! 자존심이 세! 자신감이 지나쳐! 썰렁해~ 재미있는 얘기 좀 해봐!

DB를 좋아하던 개발자가, DBA를 거쳐, 이제는 데이터 엔지니어로!
곰돌마니아였던 시절을 지나, 지금은 효주·효창·효현 바라기인 철부지 아빠
“지르기”가 낙인 엉뚱한 부부의 일원, 일단 질러야 산다
만화책부터 웹툰까지 닥치는 대로 흡입하는 이야기 중독자
옥상에 바비큐장을 만들어 놓은 고기 러버
발표 시작 60초 동안은 얼굴 경련 오는 긴장쟁이, 하지만 끝엔 몸개그로 웃깁니다

과거 5년 정도 개발 진입 단계를 거쳐, KTH, 티몬를 거쳐 카카오에 3.5년정도 머물며 진하게 숙성을 하였고, 지금은 카카오뱅크에서 데이터 관련 엔지니어로 여전히 성장하고 있는 엉뚱한 아재입니다.