■ mysqlsh를 이용한 데이터 덤프 및 엑스포트 방법 앞에서 util.dumpTable, util.exportTable 이 2가지를 이용하여 엑스포트 및 로드를 해보았습니다. https://myinfrabox.tistory.com/278 [MySQL] mysqlsh의 util.exportTable, util.importTable를 이용하여 덤프 및 임포트하기 ■ mysqlsh를 이용한 데이터 덤프 및 엑스포트 방법 테이블 엑스포트 및 덤프 방법은 util.exportTable 및 util.importTable을 이용하여 하는 방법이 있습니다. 참고로 util.dumpTable(), util.dumpTable(), util.exportTabl myinfrabox.tistory.com 이번에는 레벨별로 ..
■ mysqlsh를 이용한 데이터 덤프 및 엑스포트 방법 테이블 엑스포트 및 덤프 방법은 util.exportTable 및 util.importTable을 이용하여 하는 방법이 있습니다. 참고로 util.dumpTable(), util.dumpTable(), util.exportTable() 및 util.loadDump을 이용하는 방법이 더 최근의 방법인데 이 방법은 다음에 바로 알아보도록 하겠습니다. 먼저 위의 2가지를 이용하여 테이블 단위로 덤프 및 임포트를 하는 방법에 대해 알아보겠습니다. ■ util.exportTable, util.importTable을 이용하여 데이터 엑스포트 및 임포트를 할시 장점 select... into outfile로 엑스포트 하는것보다 속도가 훨씬 더 빠릅니다. 마찬가..
■ Dynamic Parameter, Static Parameter(동적 파라미터, 정적 파라미터) Static parameter는 시스템에 바로 적용시 문제가 되는 파라미터들이 대부분입니다. 그래서 보통 DBMS 재시작을 요구하며 이때 적용됩니다. MySQL 파라미터는 크게 Dymic Parameter, Static Parameter가 있습니다. 이 다이나믹 파라미터는 현재 운영중인 MySQL DBMS에서 바로 변경이 가능하고 신규 컨넥션부터 바로 변경된 파라미터로 운영이 됩니다. 또한 다이나믹 파라미터는 현재 접속되어 있는 세션에만 적용할수도 있고 전체 파라미터에 설정을 할수도 있습니다. 그러나 한가지 문제가 DBMS를 재시작하게 되면 글로벌로 적용된 파라미터라도 my.cnf 환경파일에 작성되지 않은..
■ MySQL 로그 관리 필요성 MySQL 로그는 기본적으로 하나의 파일이 생성되면 계속 처음에 생성된 파일에 쌓이는 구조입니다. 만약 사용량이 많은 MySQL에서 로그 파일에 대해 그냥 두게 된다면 파일 하나에 몇기가로 쌓일 수도 있습니다. 이는 추후 문제 문석을 해야 할때 파일의 크기가 워낙 크기 때문에 문제가 될 수도 있습니다. 그래서 주기적으로 파일을 절단하여 크기를 관리해 주어야 합니다. ■ 로그 파일 관리 - Logrotate 리눅스 시스템엔 본적으로 로그관리를 해주는 기능이 기본적으로 탑재되어 있습니다. Logrotate라고 불리는 이 기능은 로그관리가 필요한 파일에 대하여 매일, 매주, 월간등등 주기를 정하여 그때마다 파일을 분할(logrrotate)하여 파일을 0바이트 크기부터 시작할 수..
■ 파일오픈갯수의변경및자원사용량변경의필요성리눅스를 설치하면 기본적으로 오픈할 수 있는 File의 갯수가 작습니다. 이게 중요한 이유는 오픈할 수 파일 갯수가 작다면 성능에 제약을 받기 때문입니다.예를 들어 파일 요청파일 갯수가 3000이 들어왔는데 열수 있는 파일이 1000개라면 1000개 이후의 모든 요청은 거절되거나 대기상태로 빠지기 때문입니다.서버의 성능이 어느정도 된다면 기본값보다 값을 늘려 성능을 향상시킬 수 있습니다. ■ Linux의 확인 및 환경 설정서버에서는 file-max 란 시스템 파라미터로 불리며 이것은 한번에 운영할 수 있는 파일수를 의미합니다.보통 4MB 메모리당 256개의 파일을 운용할 수 있다고 합니다. ▶︎ 오픈 가능한 파일 갯수 확인 및 적용 방법• 확인 방법현재 file-..
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_onlyinnodb Strage Engine을 사용하는 테이블들에 대해 모두 읽기로만 작동되게 합니다. 기존 5.7 이하 버전에서는 InnoDB Storage엔진을 사용하는 테이블들에 대해서만 삭제나 생성이 불가능했는데 8.0 이상부터는 모든 스토리지 엔진을 대상으로 읽기 상태로 바뀌게 됩니다.참고로 위의 innodb_read_only가 활성화 되면 다음과 같은 명령어들이 실패하게 됩니다.ANALYZE TABLE, ALTER TABLE tbl_name ENG..
■ MHA 체크 방법먼저 MHA 설치 및 환경설정까지는 완료가 되었습니다. 이제 MHA 설정에 이상이 없는지 체크를 진행합니다. ▶ MHA 주요 명령어 확인Script명설명masterha_check_sshSSH 접속 체크masterha_managerManager 실행(모니터링 시작) - 장애 발생시 failover 수행됨masterha_stopManager 중지masterha_master_switchTakeOver(relocate) 수행masterha_check_repl복제 현황(Master/Slave 노드 정보등)masterha_check_statusStatus 확인하기 위의 스크립트 수행은 mha 유저로 수행합니다. 또한 실행 역시 MHA Manager서버에서 수행합니다. ▶ 서버간 SSH 상태 확인..
■ MHA 구성 요소▶ Manager 패키지매니저 노드에 설치되며 복제 그룹을 모니터링하는 패키지와 장애조치 스크립트들이 포함되어 있습니다. ▶ 노드 패키지매니저 노드를 제외한 모든 노드에 설치되며 바이너리 로그, 릴레이 로그등을 관리하기 위한 패키지와 스크립트들이 포함되어 있습니다. ■ 실습환경호스트명IPROLEmhamgr192.168.0.100MHA Managerdb1192.168.0.101Masterdb2192.168.0.102Slave 1db3192.168.0.103Slave 2VIP192.168.0.105VIPKeep alived를 이용한 가상 IP관리 방법도 있으나 추후 알아보겠습니다.여기서는 ifconfig를 이용하여 가상 IP를 관리해보도록 하겠습니다. ■ MHA 사전 준비사항▶ MySQ..
■ MHA 소개MHA는 MySQL High Available의 약자로 MySQL의 HA솔루션중에 하나입니다. 구글에서 오픈소스로제공되었으나 현제는 중단되고 다른 개발자가 업데이트를 해오다 2018년도부터 중단되었습니다. 하지만 지금도 MySQL에서 가장 많이 쓰이는 HA솔루션중에 하나입니다.보통 DB의 HA솔루션은 Shared Disk를 이용하고 액티브 서버에 문제 발생시 HA솔루션이 문제를 감지하고 Shared Disk를 스탠바이 서버에 붙인 후 스탠바이 서버를 액티브로 기동하여 서비스를 정상화 시킵니다. 하지만 MHA는 특이하게 마스터 - 슬레이브 복제 구조에서 슬레이브중 하나를 마스터로 승격시키고 나머지 슬레이브들을 신규로 승격된 마스터에 모두 옮김으로서 HA를 완성시킵니다.물론 Peace Make..
■ 세미싱크 소개일반적으로 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들만을 한곳에 모을 수 있습니다. 또한 이 데이터를 통계데이터로..