■ 파일오픈갯수의변경및자원사용량변경의필요성 리눅스를 설치하면 기본적으로 오픈할 수 있는 File의 갯수가 작습니다. 이게 중요한 이유는 오픈할 수 파일 갯수가 작다면 성능에 제약을 받기 때문입니다. 예를 들어 파일 요청파일 갯수가 3000이 들어왔는데 열수 있는 파일이 1000개라면 1000개 이후의 모든 요청은 거절되거나 대기상태로 빠지기 때문입니다. 서버의 성능이 어느정도 된다면 기본값보다 값을 늘려 성능을 향상시킬 수 있습니다. ■ Linux의 확인 및 환경 설정 서버에서는 file-max 란 시스템 파라미터로 불리며 이것은 한번에 운영할 수 있는 파일수를 의미합니다. 보통 4MB 메모리당 256개의 파일을 운용할 수 있다고 합니다. ▶︎ 오픈 가능한 파일 갯수 확인 및 적용 방법 • 확인 방법 현..
MySQL 서버 변수중 back_log라는 시스템 변수가 있습니다. 이 변수는 MySQL 커넥션 성능과 굉장히 밀접한 관련이 있는데 OS 커널파라미터중 네트워크와 밀접한 관련이 있습니다. 이 시스템 변수에 대해 알아보겠습니다. ■ 서버 변수 back_log에 대한 설명 MySQL이 가질 수 있는 미해결 연결 요청 수 입니다. MySQL 스레드가 매우 짧은 시간에 매우 많은 연결 요청을 받을 때 작동합니다. 그런 다음 메인 스레드가 연결을 확인하고 새 스레드를 시작하는 데 약간의 시간(아주 짧지만)이 걸립니다. back_log 값은 MySQL이 일시적으로 새 요청에 대한 응답을 중지하기 전에 이 짧은 시간 동안 쌓일 수 있는 요청 수를 나타냅니다. 단기간에 많은 수의 연결이 예상되는 경우에만 이 값을 늘려..
MySQL 5.7 부터 read_only종류가 4가지 종류로 늘어나게 되었습니다. 단순히 복제 서버에서 Write를 막기위한 read_only뿐만이 아니라 특수한 read_only 파라미터도 있는데 이것에 대해 알아보겠습니다. ■ innodb_read_only innodb Strage Engine을 사용하는 테이블들에 대해 모두 읽기로만 작동되게 합니다. 기존 5.7 이하 버전에서는 InnoDB Storage엔진을 사용하는 테이블들에 대해서만 삭제나 생성이 불가능했는데 8.0 이상부터는 모든 스토리지 엔진을 대상으로 읽기 상태로 바뀌게 됩니다. 참고로 위의 innodb_read_only가 활성화 되면 다음과 같은 명령어들이 실패하게 됩니다. ANALYZE TABLE, ALTER TABLE tbl_name..
■ MHA 체크 방법 먼저 MHA 설치 및 환경설정까지는 완료가 되었습니다. 이제 MHA 설정에 이상이 없는지 체크를 진행합니다. ▶ MHA 주요 명령어 확인 Script명 설명 masterha_check_ssh SSH 접속 체크 masterha_manager Manager 실행(모니터링 시작) - 장애 발생시 failover 수행됨 masterha_stop Manager 중지 masterha_master_switch TakeOver(relocate) 수행 masterha_check_repl 복제 현황(Master/Slave 노드 정보등) masterha_check_status Status 확인하기 위의 스크립트 수행은 mha 유저로 수행합니다. 또한 실행 역시 MHA Manager서버에서 수행합니다. ..
■ MHA 구성 요소 ▶ Manager 패키지 매니저 노드에 설치되며 복제 그룹을 모니터링하는 패키지와 장애조치 스크립트들이 포함되어 있습니다. ▶ 노드 패키지 매니저 노드를 제외한 모든 노드에 설치되며 바이너리 로그, 릴레이 로그등을 관리하기 위한 패키지와 스크립트들이 포함되어 있습니다. ■ 실습환경 호스트명 IP ROLE mhamgr 192.168.0.100 MHA Manager db1 192.168.0.101 Master db2 192.168.0.102 Slave 1 db3 192.168.0.103 Slave 2 VIP 192.168.0.105 VIP Keep alived를 이용한 가상 IP관리 방법도 있으나 추후 알아보겠습니다. 여기서는 ifconfig를 이용하여 가상 IP를 관리해보도록 하겠습니..
■ MHA 소개 MHA는 MySQL High Available의 약자로 MySQL의 HA솔루션중에 하나입니다. 구글에서 오픈소스로제공되었으나 현제는 중단되고 다른 개발자가 업데이트를 해오다 2018년도부터 중단되었습니다. 하지만 지금도 MySQL에서 가장 많이 쓰이는 HA솔루션중에 하나입니다. 보통 DB의 HA솔루션은 Shared Disk를 이용하고 액티브 서버에 문제 발생시 HA솔루션이 문제를 감지하고 Shared Disk를 스탠바이 서버에 붙인 후 스탠바이 서버를 액티브로 기동하여 서비스를 정상화 시킵니다. 하지만 MHA는 특이하게 마스터 - 슬레이브 복제 구조에서 슬레이브중 하나를 마스터로 승격시키고 나머지 슬레이브들을 신규로 승격된 마스터에 모두 옮김으로서 HA를 완성시킵니다. 물론 Peace M..
■ 세미싱크 소개 일반적으로 MySQL에서 복제라 얘기하면 Master - Slave(Replica)구조의 복제방식입니다. 그리고 이 복제방식은 특별한 설정을 하지 않는다면 비동기 방식입니다. 동기 방식은 크게 반동기(세미싱크) 방식과 비동기 방식 2가지가 있습니다. 이걸 구분하는 방법은 슬레이브 바이너리 로그에 DML이 적용되었는지 여부를 판단하느냐 않하느야에 달려 있습니다. 먼저 비동기 방식에 대해 알아보겠습니다. 비동기 방식은 마스터에서 DML이 발생하면 바이너리 로그에 DML을 작성하고 이 바이너리 로그를 슬레이브로 보냅니다. 이때 비동기 방식은 바이너리 로그가 슬레이브 로그에 적용되었는지 여부에 관련없이 무조건 자신의 DML만 수행합니다. 이 방식은 마스터에서의 수행 여부만 판단하기 때문에 속도..
■ MSR (Multi Source Replication)이란? 간단하게 설명해서 여러개의 마스터 서버 발생하는 데이터를 하나의 슬레이브 서버에서 받아내는 방식입니다. 그림 1. MSR 구성도 이 방식을 이용하면 여러 마스터 서버의 특정 DB만을 슬레이브에서 받아서 한번에 조회가 가능하다는 장점이 있습니다. 예를 들어 MASTER 1번의 특정 DB, MASTER 2번의 특정 DB, MASTER 3은 전체 DB를 복제하여 이 DB들을 한곳에 모아서 조회를 할수가 있습니다. 이것을 응용한다면 아래와 같은 그림으로도 구성할 수 있습니다. 그림 2. MSR 다중 구성도 여러개의 마스터-슬레이브 복제 클러스터들이 있을때 이중에서 특정 마스터의 특정 DB들만을 한곳에 모을 수 있습니다. 또한 이 데이터를 통계데이터..
■ Timestamp 와 timezone과의 관계 timestamp 컬럼 속성을 가지는 데이터를 마이그레이션 할때 유의할 사항이 있습니다. 그것은 timezone의 속성이 굉장히 중요하다는 것입니다. 예를 들어 기존 MySQL 서버의 time zone이 KST(+9시간) 일때 만약 UTC tim zone(+0)시간을 가지는 MySQL 서버에 데이터를 입력할 경우 UTC의 시간으로 바뀝니다. 즉 현재 MySQL서버의 시간에 따라간다는 의미입니다. 테스트를 통해 알아보도록 하겠습니다. ■ 테스트 다음과 같은 데이터가 있다고 가정합니다. mysql> select @@time_zone; +-------------+ | @@time_zone | +-------------+ | +09:00 | +----------..
■ 복제 에러 건너뛰기 MySQL의 마스터-슬레이브 복제 환경에서 운영시 복제가 멈추는 상황이 발생합니다. 예를 들면 데이터 중복오류 슬레이브에 존재하지 않는 데이터베이스에 데이터 입력 슬레이브에 존재하지 않는 테이블에 데이터 입력 시도 등 여러가지가 있습니다. 이런 이유들로 인해 데이터 복제가 멈추게 됩니다. 여기에서는 이런 에러에 대해 해결하는 방법에 대해 알아보겠습니다. ■ 에러 상황 복제 중지 에러가 발생하게 되면 보통 다음과 같은 에러가 발생하게 됩니다. 아래에 나와있는 show slave status 명령을 입력하게 되면 에러 내용에 대해 자세히 나오게 됩니다. 위에 보면 Last_Errno와 Last_Error가 있습니다. 이곳에서 왜 에러가 발생했는지 원인을 파악해 볼 수 있습니다. mys..