노땅의 IT 세계

안정적인 IT 지원의 시작과 끝' 무료 헬프데스크 티켓팅 툴 6가지

Eric Geier | Computerworld

기업의 IT 부서든 매니지드 서비스 업체(Managed Service Provider, MSP)든, 헬프데스크 티켓팅 시스템을 안정적으로 기술 지원을 제공하기 위해 꼭 필요하다. 이러한 애플리케이션은 IT 직원과 최종 사용자가 기술적인 문제와 궁금한 점을 소통하고 추적하는 방법을 제공한다. 또한, 티켓팅 시스템은 기업 내 사용자에게 배포된 모든 하드웨어와 소프트웨어를 추적하는 자산 관리 기능을 제공하며, 일부는 새로운 재택근무 환경에서 필요한 원격 모니터링과 관리, 패치 기능을 제공하기도 한다.

무료로 제공되는 IT 티켓팅 애플리케이션이 다양하므로, 사용하지 않을 이유가 없다. 아직 헬프데스크 제품이 없거나 다른 제품을 찾는 이들을 위해 무료 제품을 소개한다. 대부분은 유료 제품의 기능이 제한된 무료 버전으로, 기업이 성장함에 따라 유료 서비스로 쉽게 전환할 수 있고, 완전 무료 서비스도 있다.

매니지엔진 서비스데스크 플러스

매니지엔진(ManageEngine)은 서비스데스크 플러스(ServiceDesk Plus)라는 IT 관리 기능이 포함된 헬프데스크 도구를 제공하며 클라우드와 온프레미스에서 사용할 수 있다. 하지만 무료 버전은 온프레미스 기능만 제공하고 윈도우와 리눅스 컴퓨터에 설치할 수 있다.

서비스데스크 플러스는 3가지 버전(스탠더드, 프로페셔널, 엔터프라이즈)이 있다. 스탠더드 에디션만 무료이며 최대 5명의 기술 상담원과 500개의 노드를 지원한다. 스탠더드 요금제에서 10명의 기술 상담원과 500개의 노드로 지원하는데 가격은 월 100달러부터 시작한다. 프로페셔널과 엔터프라이즈 요금제에서 5명의 기술 상담원과 500개의 노드 지원 가격은 각각 월 100달러와 250달러다. 이 가격은 연간 계약 기준이고, 약간 금액을 더 지불하면 월 단위로 결제하는 것도 가능하다.

무료 서비스데스크 플러스(ServiceDesk Plus) 버전으로 자산을 관리하려면, 서비스데스크 플러스 인터페이스와 통합된 매니지엔진의 RMM(Remote Monitoring and Management) 도구인 데스크톱센트럴(DesktopCentral)을 사용해야 한다. 데스크톱센트럴 무료 버전은 최대 25대의 컴퓨터와 25대의 모바일 기기를 지원하며, 온프레미스 배포(윈도우만 해당) 또는 클라우드(애저와 AWS)를 통해 제공된다. 유료 버전도 있다. 프로페셔널과 엔터프라이즈, UEM(Unified Endpoint Management) 버전으로 각각 연간 795달러, 945달러, 1,095달러에 한 명의 기술 전문가와 50대의 컴퓨터가 지원된다.

서비스데스크 플러스를 활용하면 사용자 요청과 솔루션을 추적, 관리할 수 있다. 스케줄러를 사용해 작업과 미리 알림, 기술 개발 여부를 설정할 수 있다. 데스크톱센트럴 통합을 설정하면, 인벤토리 기능을 통해 하드웨어와 소프트웨어 자산을 관리할 수 있다. 또한 기본 원격 데스크톱 지원, 소프트웨어 및 구성 배포, 패치 관리 기능도 제공한다.

민트 서비스 데스크

민트 서비스 데스크(Mint Service Desk, MintSD)는 IT 서비스 데스크 관리 툴로, 도커(Docker)를 사용하는 리눅스나 맥OS용으로 활용할 수 있는 온프레미스 솔루션이다. 또한 유료 옵션으로 매니지드 버전도 제공한다. 무료 버전은 3명의 상담원을 지원하고, 모든 기능을 포함한다. 민트SD는 프리미엄 버전 가격을 공개하지 않았지만, 비영리 단체에는 무료로 제공한다고 밝혔다.

민트SD의 인시던트관리 기능을 사용하면 티켓을 볼 때 사용자 지정 양식과 사용자 지정 사전, 필터링 옵션 등 일부 사용자 지정 기능을 활용해 티켓을 관리할 수 있다. 또한 최종 사용자와의 라이브 채팅을 지원하고, FAQ를 만들 수도 있다. 자산 관리 기능을 사용하면 사용자 지정 범주와 자산 관계를 만들 수 있고, QR 코드를 사용한 자산 태그 생성도 지원한다.

민트SD의 서비스 수준 관리 기능을 이용하면 SLA 매개변수를 입력하고 성능을 모니터링할 수 있다. 매개변수는 특정 서비스 유형에 따라 설정할 수 있고, 각 티켓당 응답, 업데이트, 해결 시간을 추적하는 것도 가능하다.

OTRS

OTRS(Open Technology Real S)는 IT 관리 기능이 있는 헬프데스크 소프트웨어로, 리눅스와 유닉스 계열, 맥OS 컴퓨터에 설치할 수 있는 온프레미스 오픈소스 버전이 있다. 유료 버전은 온프레미스와 클라우드 배포가 모두 가능하며, SMS 알림과 채팅, 보고 등의 기능을 추가로 제공한다.

OTRS 프리(OTRS Free)를 사용하면 기본적인 티켓 관리를 수행하고, 최종 사용자와 상담원을 위한 지식 기반을 구축하고, 상담원 예약 스케줄을 관리할 수 있다. ITSM 모듈(ITSM Module)을 통해 추가된 기본 구성 관리 데이터베이스 기능을 사용하면 항목을 수동으로 추가해 간단하게 자산 관리를 수행할 수 있다.

OTRS는 매우 간단하고 단순해 보이지만, 티켓팅 부분은 오픈소스이므로 펄과 자바스크립트에 대해 잘 알고 있다면 높은 수준으로 사용자 정의를 추가할 수 있다. 실제로 OTRS는 개발자가 OTRS 프리 프로젝트에 기여하도록 권장한다.

심리스데스크

심리스데스크(SeamlessDesk)는 티켓과 자산, 프로젝트 관리를 제공하는 클라우드 기반 IT 서비스 데스크 플랫폼이다. 무료 버전에서는 상담원을 한 명만 지원하며 유료 버전에서 제공하는 이메일과 웹, SMS, 소셜 포털 지원 중 일부를 사용할 수 없다. 그러나 최종 사용자 기기는 대수에 제한 없이 지원한다.

심리스데스크는 유료 에디션인 스타터(Starter, 상담원 3명), 그로우스(Growth, 6명), 프리미엄(9명)의 30일 무료 평가판도 있다. 각 버전의 가격은 연간 계약 기준 월 60달러, 120달러, 180달러부터 시작한다. 12개월 약정을 하지 않으면 비용이 더 올라간다.

심리스데스크 기능에는 기본 IT 티켓 관리 외에도 하드웨어 및 소프트웨어뿐만 아니라 공급업체와 계약에 대한 자산 관리도 있다. 공개 지식 기반을 생성할 수도 있고 특히 프로젝트 관리 기능을 제공하는 유일한 무료 헬프데스크 툴이다.

스파이스웍스 헬프데스크

스파이스웍스(Spiceworks)는 제한 없이 완전히 무료인 (반면 광고가 포함된다) IT 헬프데스크 툴을 제공한다. VM웨어 또는 리눅스 컴퓨터에 온프레미스로 설치하거나 클라우드 기반 버전으로 사용할 수 있다. 무료로 네트워크 인벤토리와 네트워크 모니터링 애플리케이션을 제공하는 것도 장점이다. 그 외에도 온라인 커뮤니티를 주최하고, 지역 모임을 주관하며, 연례 IT 컨퍼런스를 개최한다.

스파이스웍스 헬프데스크의 클라우드 버전은 기본적인 티켓팅과 보고 기능, IT 지식 기반을 참조하거나 추가할 수 있는 기능을 제공한다. 또한 소프트웨어와 하드웨어 인벤토리를 관리하고 IT 연락처를 추적할 수 있다. 클라우드 버전용 서드파티 애드온 앱도 있어, 모니터링하는 PC에서 소프트웨어의 제품 키를 관리하거나 사용자 포털에 사용자 지정 기능을 추가할 수도 있다.

온프레미스 버전의 헬프데스크는 최종 사용자 포털을 더 상세하게 설정하고, 지식 기반 또는 FAQ를 만드는 등 더 많은 기능을 지원한다. 또한 티켓팅과 IT 자산에 대한 보고서 작성 기능도 더 다양하다. 온프레미스 버전에 사용할 수 있는 서드파티 앱은 150개가 넘으며, (종료된 티켓뿐만이 아니라) 열려있는 티켓을 삭제하는 기능부터 기기 사용 시간이나 SQL 서버를 모니터링하는 새로운 기능까지 모든 것을 제공한다.

무료 인벤토리 앱은 온프레미스 버전에도 포함돼 있으며 윈도우 워크스테이션과 네트워크 스캔을 지원한다. 기본적인 IT 자산 관리 외에도 구매, 공급업체, 견적을 추적할 수 있다. 또한 몇 가지 기본적인 네트워크와 패치 모니터링을 제공하며, 스파이스웍스의 무료 네트워크 모니터(Network Monitor) 앱을 설치하면 더 많은 세부 정보와 기능을 추가할 수 있다.

시스에이드

시스에이드(SysAid)는 기능이 제한된 IT 헬프데스크 소프트웨어 무료 버전을 제공한다. 최대 2명의 상담원이 최대 100개의 자산과 100명의 최종 사용자를 관리할 수 있다. 온프레미스(윈도우 또는 리눅스 컴퓨터에 설치 가능)와 클라우드 기반 서비스 방식으로 사용할 수 있다(시스에이드는 프리미엄 옵션에 대해 가격을 공개하지 않았으므로, 직접 견적을 요청해야 한다).

무료 버전에서는 인시던트와 활동, 예정된 이벤트를 별도로 관리할 수 있다. 최종 사용자와 상담원이 참고할 지식 기반을 개발할 수 있으며, 이들과 즉시 소통할 수 있는 채팅 기능도 있다. 또한 무료 버전은 알림과 기본 원격 데스크톱 기능과 함께 자산 추적, 패치 관리, 워크스테이션 모니터링 기능을 제공한다. 많은 헬프데스크와 IT 자산 세부 정보에 대한 보고서와 분석도 제공한다. 그 외에도 다양한 계정과 인증, 모니터링, 원격 데스크톱 도구에 사용할 수 있는 여러 가지 애드온과 서드파티 기능이 있다.

그 외의 무료 일반 헬프데스크 툴

이외에도 몇 가지 무료 헬프데스크 툴이 있다. 대부분 IT 자산 관리 기능이 없는 일반적인 티켓팅 제품이다.

• 헬프스팟(HelpSpot): 무료 버전은 몇 가지 제한 사항이 있는 온프레미스 소프트웨어로 제공된다. 최대 3명의 상담원을 지원하며 3개의 메일 박스와 1개의 포털로 제한된다. 유료 온프레미스 버전과 호스팅 버전도 있다.

• 지라 서비스 매니지먼트(Jira Service Management): 무료 클라우드 버전은 최대 3명의 상담원을 지원한다. 다운로드 가능한 온프레미스 버전은 무료가 아니지만 일회성 요금으로 10달러부터 시작할 수 있다.

• 오에스티켓(osTicket): 인핸스소프트(Enhancesoft)에서 PHP 기반 도구를 다운로드해 설치할 수 있다. 모든 기능을 제한 없이 무료로 사용할 수 있고, 유료 호스팅 버전도 있다.

출처: <https://www.itworld.co.kr/tags/1605/%ED%97%AC%ED%94%84%EB%8D%B0%EC%8A%A4%ED%81%AC/176829>

MariaDB [(none)]> set global general_log=off;

Query OK, 0 rows affected (0.000 sec)

MariaDB [(none)]> show variables like 'general%'

    -> ;

+------------------+------------+

| Variable_name    | Value      |

+------------------+------------+

| general_log      | OFF        |

| general_log_file | master.log |

+------------------+------------+

2 rows in set (0.002 sec)

[mysql] too many connections 에러 이유와 해결방안

lku (45)in #server • 2년 전

too many connections 에러의 경우

mysql에 연결된 클라이언트의 수가 일정수치 이상인 경우 나타는 에러메시지이다.

<확인>

• mysql 연결할 수 있는 최대 클라이언트 갯수 확인
  -> mysql> show variables like '%max_connect%';

• mysql 지속시간 확인
  -> mysql> show variables like 'wait_timeout';
  

• mysql 현재 상태 확인
  -> mysql> show status like '%CONNECT%';

<해결 방안>

1. mysql 설정파일 변경 후 mysql 재시작
   -> [mysqld]
   max_connections = 500
   wait_timeout = 300
   -> 해당방법의 경우 max_connections는 214까지만 변경이되고 wait_timeout은 변경되지 않아 다음 방법으로 진행
2. mysql에 접속하여 세팅
   mysql> set global max_connections=500;
   mysql> set wait_timeout=60;

출처: <https://steemit.com/server/@lku/mysql-too-many-connections>

MySQL 복제를 이용한 실시간 백업

원문: http://www.onlamp.com/pub/a/onlamp/2005/06/16/MySQLian.html

대규모로 운영중인 MySQL 데이터베이스의 문제는 서버를 중단시키지 않고 전체 백업(clean backup)을 하는 것이다. 백업은 시스템을 느리게 만들며, 백업을 수행중인 테이블과 관련된 데이터가 변경될 수 있기 때문에 데이터 일관성을 해칠 수도 있다. 서버를 다운시키면 일관된 데이터를 얻을 수 있지만 이는 사용자에게 서비스 중단을 의미한다. 반드시 필요하고 어쩔 수 없는 경우라면 서버를 다운시킬 수 있지만, 데이터를 백업하기 위해 매일 서버를 중단하는 것은 받아들이기 어려운 일이다. 날마다 서버를 중단하지 않고 안정적인 백업을 받는 방법은 MySQL에 복제(replication)를 설정하는 것이다.

역주1: 업무상 DB 전체 백업에 해당하는 것이 원어에서는 clean backup이다. 따라서 클린 백업 대신 전체 백업으로 옮겼다.

역주2: MySQL 복제 서비스는 MySQL 3.2 부터 지원한다.

복제는 MySQL 서버의 시스템 구성으로 설정할 수 있으며, 마스터 서버는 데이터를 저장하고, 클라이언트 요청을 처리하며, 슬레이브 서버는 마스터 서버 데이터의 완전한 복사본을 갖고 있으며, 마스터 서버에 변경이 일어나자마자 그에 해당하는 모든 SQL 문장을 복제한다. 로드 밸런싱을 위해 복제를 사용하는 경우도 있지만, 여기서는 데이터 백업을 위해 복제를 사용하는 것에만 관심을 둘 것이다. 슬레이브로 사용할 별도의 서버를 설정하고, 매일 전체 백업을 받기 위해 복제를 중단할 수 있다. 전체 백업이 끝난 다음에 복제를 재시작하면 슬레이브에서는 마스터와 연결되어 있지 않은 시간 동안 변경된 내용들을 마스터에 자동으로 요청한다. 복제는 매우 훌륭한 기능이며 MySQL에 있는 기능이다. 여러분이 할 일은 복제를 설정하는 것 뿐이다.

복제 수행 과정

복제를 설정하는 방법을 설명하기 전에 MySQL이 복제 서버를 어떻게 관리하는지부터 간단하게 살펴봐야 한다. MySQL 복제 서버 관리는 MySQL 버전에 따라 다르지만, 대부분의 시스템에서는 최신 버전을 사용하고 있기 때문에 여기서는 MySQL 4.0 이상의 버전에 대해서만 설명할 것이다.

복제를 사용중일 때 마스터 서버에서 SQL 문장이 실행되면 MySQL은 바이너리 로그(bin.log)에 이를 로그 식별 번호와 같이 기록한다. 그러면 슬레이브 서버는 IO 스레드를 사용해서 정기적으로 변경사항을 추적하기 위해 마스터 서버의 바이너리 로그 파일을 읽어들인다.

변경사항이 있으면 릴레이 로그(relay.log)에 문장을 복사하고, 슬레이브 서버에 마스터 파일(master.info)에 새 식별 번호를 기록한다. 슬레이브 서버는 같은 IO 스레드를 사용해서 마스터 서버의 바이너리 로그를 확인한다. 릴레이 로그에 변경된 내용이 있으면 슬레이브 서버는 SQL 스레드를 사용해서 릴레이 로그에 새 SQL 문장을 기록한다. 슬레이브 서버는 안전 장치로 SQL 스레드를 사용해서 슬레이브 서버의 데이터와 마스터 서버의 데이터가 일치하는지 확인하기 위해 마스터 서버에 질의한다. 비교 결과가 일치하지 않는다면 복제는 중단되고 슬레이브 서버의 에러 로그(error.log)에 에러 메시지를 기록한다. 비교 질의 수행 결과가 일치한다면 슬레이브 서버의 릴레리 로그 파일(relay-log.info) 파일에 새 로그 식별 번호를 기록하고, 마스터 서버의 릴레이 로그 파일의 변경을 모니터링한다.복제 과정은 복잡해 보이지만, 모든 과정은 빠르게 수행되며 마스터 서버 자원을 많이 소비하지 않으면서 안정적인 복제를 보장한다. 또한, 복제 서비스는 마스터 서버와 슬레이브 서버의 my.cnf 설정 파일에 옵션을 몇 줄 추가하는 것으로 설정할 수 있으며, 설정과정도 쉽다. 새로운 서버를 설치하는 경우에도 단순히 마스터 서버의 데이터베이스를 슬레이브 서버에 복사하고, 슬레이브 서버에서 복제를 시작하면 된다.

복제 사용자

복제를 설정하기 위해서는 몇 가지 간단한 절차를 수행하면 된다. 첫번째는 복제 용도로만 사용할 사용자 계정을 설정하는 것이다. 보안상 기존 계정은 사용하지 않는 것이 가장 좋다. 사용자 계정을 설정하기 위해 마스터 서버에 다음 명령을 수행한다. 다음 명령은 root나 GRANT OPTION 권한을 가진 사용자 계정으로 로그인해서 수행해야한다.

GRANT REPLICATION SLAVE, REPLICATION CLIENT

      ON *.*

      TO "replicant"@"slave_host"

      IDENTIFIED BY "my_pwd";

SQL 문장에서 사용자 계정 replicant는 복제에 필요한 권한만 설정되었다. 사용자 이름은 어떤 것이든 사용할 수 있다. "replicant" 대신에 호스트 이름이나 IP 주소를 사용할 수도 있다. 슬레이브 서버에서도 위와 같은 질의를 수행시키면 된다. "slave_host"는 마스터 서버의 호스트 이름이나 IP 주소로 변경하면 된다. 이와 같이 설정하면, 마스터 서버에 장애가 발생해서 잠시 사용할 수 없는 경우 사용자를 DNS 설정이나 다른 방법을 사용해서 슬레이브 서버를 이용하게 할 수 있다. 마스터 서버가 복원된 이후에는 슬레이브 서버에 변경된 데이터를 마스터 서버에 반영하기 위해 복제를 사용할 수 있다. 공교롭게도 이전 버전의 MySQL에서 4.0 버전으로 업그레이드한 경우에 mysql 데이터베이스는 업그레이드되지 않기 때문에 위의 GRANT 문장이 실행되지 않는다. 이전 버전에는 복제와 관련된 권한이 없기 때문이다. 이 문제를 해결하기 위해서는 MySQL 문서에서 Grants 테이블 업그레이드하기를 참고하기 바란다.

서버 설정하기

마스터와 슬레이브에 복제 사용자를 모두 설정했으면, 이번에는 두 서버의 MySQL 설정 파일을 수정해야 한다. 운영중인 운영체제의 종류에 따라 설정 파일은 my.cnf 또는 my.ini일 것이다. Unix 계열 운영체제에서 설정 파일은 /etc 디렉터리에 있으며, 윈도우 시스템에서는 c:\ 또는 c:\windows에 있다. 텍스트 편집기를 사용해서 설정 파일에 [mysqld] 그룹 아래에 다음을 추가한다.

server-id = 1

log-bin = /var/log/mysql/bin.log

서버 식별 번호는 마스터 서버를 식별하기 위한 임의의 숫자다. 대부분의 경우에 어떤 숫자든 사용할 수 있다. 슬레이브 서버에 다른 식별 번호만 부여하면 된다. 두번째 줄은 MySQL에서 바이너리 로그를 수행할 경로와 파일명을 지정하는 것이다. 실제로 사용할 경로와 파일 이름은 원하는 대로 지정할 수 있다. 설정 파일의 디렉터리고 실제로 있는지 확인하고 mysql 사용자가 소유자이거나 또는 디렉터리에 쓰기 권한이 있기만 하면 된다. 또한, 여기서는 파일 이름의 접미어로 ".log"를 사용했지만 서버가 재시작하거나 로그 정보를 다시 시작할 때 ".000001"과 같은 일련번호로 대체된다.

슬레이브 서버의 설정 파일에도 다음을 추가해야 한다. 마스터 서버 연결을 위한 정보와 로그 파일 옵션을 추가한다.

server-id = 2

master-host = mastersite.com

master-port = 3306

master-user = replicant

master-password = my_pwd

log-bin = /var/log/mysql/bin.log

log-bin-index = /var/log/mysql/log-bin.index

log-error = /var/log/mysql/error.log

relay-log = /var/log/mysql/relay.log

relay-log-info-file = /var/log/mysql/relay-log.info

relay-log-index = /var/log/mysql/relay-log.index

꽤 많은 내용을 추가하는 것 같지만 실제로 들여다보면 어렵지 않게 이해할 수 있을 것이다. 첫번째 줄은 슬레이브 서버의 식별 번호이며, 슬레이브 서버를 여러 대 설정할 경우에는 다른 번호를 부여하면 된다. 그러나 단순히 데이터를 백업하는 것을 원하는 경우에는 슬레이브 서버를 한 대이상 설정할 필요는 없을 것이다. 그 다음 섹션은 마스터 서버의 호스트 이름, IP 주소와 같은 마스터 서버 정보에 대한 것이다. 마스터 포트는 MySQL 기본 설정인 3306 포트를 사용하지만 수행성능이나 보안상의 이유로 다른 포트 번호를 사용할 수도 있다. 그 다음은 마스터 서버에 로그인하기 위한 사용자 이름과 비밀번호다.

다음 두 섹션은 로그를 설정하기 위한 것이다. 처음 섹션은 마스터 서버에서 했던 것처럼 슬레이브 서버에서 바이너리 로그를 기록하기 위한 것이다. 이 설정은 앞에서 얘기한 것처럼 필요시 마스터 서버와 슬레이브 서버간에 역할을 서로 바꿀 수 있게 하기 위한 것이다. 바이너리 로그 인덱스 파일(log-bin.index)는 현재 사용하는 바이너리 로그 파일 이름을 기록하기 위한 것이다. 서버가 재시작되거나 로그들을 정리한 경우에 현재 로그 파일이 변경되며, 변경된 로그 파일 이름이 log-bin.index 파일에 기록된다. log-error 옵션은 에러 로그를 기록한다. 복제와 관련된 문제가 모두 기록되기 때문에 반드시 이 설정을 해야한다. 마지막 섹션은 릴레이 로그와 관련된 파일들을 설정한다. 릴레이 로그는 성능을 위해 마스터 서버 바이너리 로그의 각 항목을 복사한다. relay-log-info-file 옵션은 마스터 서버의 바이너리 로그에 대한 슬레이브 서버의 로그 파일 위치를 설정한다. 릴레이 로그 인덱스 파일은 복제를 위해 현재 사용중인 릴레이 로그 파일 이름을 관리한다.

데이터베이스 복사와 복제 시작하기

새 마스터 서버에 데이터가 없다면 슬레이브 서버를 재시작하면 된다. 그러나, 데이터가 있는 운영중인 서버에 복제를 설정했다면 복제를 위한 데이터베이스 초기 백업을 수행하는 것과 이 백업을 슬레이브 서버에 복사해야 한다. 데이터베이스를 백업하는 방법은 다양하다. 예를들어, mysqldump를 사용해서 운영중인 서버를 백업할 수 있다. 그러나, 여기에는 운영중인 서버의 데이터 일관성 문제가 남는다. 복제를 설정한 후에는 백업을 받기 위해 서버를 중단시키지 않아도 된다는 사실을 생각해보자. 즉, 일관성을 유지하면서 전체 백업을 받기 위해 사용자가 연결하지 못하게 하는 것도 생각해 볼 수 있다. root만 접근할 수 있는 마스터 서버를 만들기 위해 max_connections 변수를 다음과 같이 초기화할 수 있다.

SHOW VARIABLES LIKE "max_connections";

+-----------------+-------+

| Variable_name   | Value |

+-----------------+-------+

| max_connections | 100   |

+-----------------+-------+

SET GLOBAL max_connections = 0;

첫번째 SQL 문장은 필요없지만, 백업이 완료된 후에 max_connections 변수 값을 원래대로 복원하기 위해 초기 값을 알 필요는 있을 것이다. max_connections 값을 0으로 하는 것은 어떤 연결도 허용하지 않지만, 실제로 1개의 연결은 root 사용자를 위해 남겨져 있다. 물론, 이것은 새로운 연결만을 받아들이지 않는다. 따라서 현재 실행중인 연결을 보기 위해서는 SHOW PROCESSLIST;를 입력한다. 수행중인 프로세스를 종료하기 위해 KILL 문장을 사용할 수 있다.

서버에 독점적으로 액세스할 수 있으면 mysqldump는 매우 빠르게 수행된다. 마스터 서버의 명령줄에서 다음 명령을 입력한다.

mysqldump --user=root --password=my_pwd \

         --extended-insert --all-databases \

         --master-data   > /tmp/backup.sql  

위 문장은 모든 데이터베이스와 테이블을 생성하고, 데이터를 생성하는 SQL 문장으로 구성된 텍스트 파일을 생성한다. --extended-insert 옵션은 한번에 여러 줄을 넣을 수 있는 INSERT 문장을 만들어 주기 때문에 결과적으로 보다 빠르게 백업을 수행할 수 있으며, 최소한의 다운 타임을 갖는데 도움이 된다. --master-data 옵션은 덤프하는 동안 데이터가 변경되지 못하게 모든 테이블을 잠그지만, 사용자가 테이블을 읽어들이는 것은 허용한다. 독점적인 액세스 환경인 경우 이 기능은 필요하지 않다. 그러나, 이 옵션은 덤프 파일의 마지막에 다음과 같은 내용을 추가해준다.

--

-- Position to start replication from

--

CHANGE MASTER TO MASTER_LOG_FILE="bin.000846" ;

CHANGE MASTER TO MASTER_LOG_POS=427 ;

슬레이브 서버에서 덤프 파일이 실행될 때, 위 내용은 테이블이 잠겨 있는 동안 마스터 서버의 바이너리 로그 파일 이름과 백업 시점에서의 로그 위치를 기록한다. 복제가 시작될 때 이 로그 파일에 액세스하게 되고, 해당 위치부터 시작해서 기록된 SQL 문장을 수행한다. 즉, 슬레이브 서버가 설정되는 동안 변경된 데이터가 누락되지 않게 해준다. 슬레이브 서버에서 데이터베시으와 데이터를 설정하기 위해 덤프 파일을 실행하기 위해 덤프 파일을 슬레이브 서버에 복사한다. MySQL이 실행중인지 확인하고 슬레이브 서버에서 다음과 같이 입력한다.

mysql --user=root --password=my_pwd < /tmp/backup.sql

위 명령은 덤프 파일에 있는 CREATE, INSERT 문을 포함한 모든 SQL 문장을 실행한다. 백업된 데이터베이스가 슬레이브 서버에 모두 올라온 다음에는 슬레이브에 root로 로그인해서 다음 SQL 문장을 실행한다.

START SLAVE;

이 문장을 실행하면, 슬레이브는 마스터에 연결하고, 백업 이후로 누락된 변경사항을 가져온다. 이 시점부터 마스터 서버의 바이너리 로그 파일을 지속적으로 검사하면서 항상 최신의 상태를 유지한다.

복제를 이용한 백업

복제가 실행중일 때, 데이터 백업을 하는 것은 쉬운 작업이다. 먼저, 슬레이브 서버에 root 또는 SUPER 권한이 있는 사용자로 로그인하여 다음 SQL 문을 입력해서 슬레이버 서버의 복제를 잠시 중단시킨다.

STOP SLAVE;

슬레이브 서버는 마스터 서버의 바이너리 로그에 남겨진 위치를 알고 있다. 따라서, 슬레이브 서버에서 복제된 데이터베이스를 백업하면 된다. 백업 유틸리티 등을 사용하여 백업을 하고, 백업이 모두 완료되면 다음 명령을 실행해서 복제를 재시작하면 된다.

START SLAVE;

위 문장을 입력하면, 슬레이브 서버는 중단된 시점부터의 SQL 문장을 실행하고, 다시 최신의 상태를 유지하게 된다.

백업 자동화하기

복제와 백업이 올바르게 동작한다면 슬레이브 서버에서 복제를 중단하고, 데이터를 백업받고, 다시 슬레이브를 시작하는 간단한 쉘 스크립트를 작성할 수 있다.

#!/bin/sh

date = `date +%Y%m%d`

mysqladmin --user=root --password=my_pwd stop-slave

mysqldump --user=root --password=my_pwd --lock-all-tables \

         --all-databases > /backups/mysql/backup-${date}.sql

mysqladmin --user=root --password=my_pwd start-slave

이 예제에서는 슬레이브에서 복제를 중단하고 시작하기 위해 mysqladmin을 사용했다. 첫번째 줄에서 시스템 함수 date와 적절한 형식(예, 20050615)을 사용한 데이터를 사용해서 스크립트에서 mysqladmin에서 날마다 덤프 파일의 이름을 변경할 수 있게 했다. 물론, 덤파 파일의 경로와 이름을 원하는 대로 설정할 수 있다. date 함수와 서식지정 코드는 (")아 아니라 (`)을 사용한 것에 주의해야한다.

이것은 간단한 스크립트이고, 여러분은 보다 정교한 것을 작성하거나 오류 점검을 할 수 있는 것을 작성할 수도 있다. 공간을 절약하기 위해 덤프 파일을 압축하고, 압축한 파일을 테이프나 CD와 같은 매체에 저장할 수도 있다. 스크립트를 설정했으면 잘 동작하는지 테스트하기 바란다. 스크립트가 잘 동작한다면 crontab이나 서버에서 사용하는 스케줄링 유틸리티를 사용해서 스크립트를 추가하면 된다.

결론

복제는 MySQL에서 유용한 관리 기능이다. 복제는 데이터베이스의 주기적인 백업을 보장하는 훌륭한 방법이다. 복제에 대해 여기서 설명한 것보다 더 많은 옵션과 SQL 문장이 있으며, 이에 대해서는 내가 쓴 MySQL in a Nutshell에서 다루었다. 운영중인 대규모 시스템에서는 보다 강력한 데이터 보호를 위해 슬레이브 서버를 한 대 이상 설정할 수도 있다. 다중 슬레이브 서버 구성은 단일 슬레이브 서버 구성과 마찬가지로 설정과 개념은 동일하다. 극단적으로 많은 트랜잭션이 발생하는 데이터베이스에 대해서는 Emic과 같은 소프트웨어를 고려해볼 수 있다. Emic의 소프트웨어는 비싸지만, 백업과 로드 밸런싱을 위한 슬레이브 서버 관리를 위한 작업을 훌륭하게 수행한다.

xtrabackup 이란?

xtrabackup은 percona 에서 무료로 제공하는 DB 핫 백업 툴입니다.

백업 시 암호화, 압축, 증분 백업 등 많은 기능이 포함되어있어

다양한 백업 정책을 만들 수 있으며, 핫 백업으로 mysqldump보다 빠른 백업 및 복구가 가능합니다.

지원되는 DB는 mysql (5.1, 5.5, 5.6, 5.7), xtraDB 가 있습니다.

xtrabackup 설치 방법

CentOS and RHEL

wget http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm 

rpm -ivH percona-release-0.1-4.noarch.rpm

yum install percona-xtrabackup-24

Debian and Ubuntu

wget https://repo.percona.com/apt/percona-release_0.1-4.$(lsb_release -sc)_all.deb

sudo dpkg -i percona-release_0.1-4.$(lsb_release -sc)_all.deb

sudo apt-get update

sudo apt-get install percona-xtrabackup-24 

xtrabackup 사용법

(테스트 환경이 innodb로 xtrabackup의 innobackupex를 이용하였습니다.)

참고 사항) xtrabackup 기본 설정으로 아래와 같이 설정되어있으니 

mysql 설정 파일 경로와 user가 다를경우 해당 옵션을 추가해야 정상적으로 백업이 됩니다.

--defaults-file=/etc/my.cnf 

--defaults-group=mysql 

전체 백업시 

innobackupex --user={DB유저} --password={패스워드} {백업경로}

ex) innobackupex --user=root --password=testpassword9* /home/backup/

경로를 지정하여 사용하고 싶으시다면 --no-timestamp 옵션을 추가하시기 바랍니다.

주의!

--no-timestamp 옵션 사용시 백업하는 대상 경로가 이미 생성되어있을 경우 백업이 진행되지 않으니

경로가 중복되지 않도록 설정해 주시기 바랍니다.

복원 방법

1. 복원 준비

innobackupex --apply-log {full백업 경로}

2. 복원

mysqld 정지 후 mysql datadir 하위에 있는 데이터 삭제 (폴더 지우면 복원이 안됩니다.)

innobackupex 명령어로 백업본 복사

복사 완료 후 mysql 유저 권한 부여

mysqld 시작하여 데이터 확인

# service mysqld stop

# rm -rf {mysql datadir}/*

# innobackupex --copy-back {full백업 경로}

# copy 작업 완료 후 폴더 권한 변경

# chown -R mysql:mysql {mysql datadir}

# service mysqld start

증분백업 방법

전체 백업 진행 후 해당 경로 하위에 있는 xtrabackup_checkpoints 파일의 last_lsn 정보를 불러와 해당 시점부터 증분된 정보를 백업( MyISAM 형식의 테이블은 항상 전체 백업이 진행됩니다.)

사용옵션

--incremental 

--incremental-basedir=(증분 대상 백업 폴더)

--incremental-lsn=(lsat_lsn 값)

사용예제

1. 전체 백업 진행

innobackupex --user={DB유저} --password={패스워드} {백업경로}

2. 증분 백업

 innobackupex --user={DB유저} --password={패스워드} --incremental --incremental-basedir={전체 백업 경로} {백업 경로}

innobackupex --user={DB유저} --password={패스워드} --incremental --incremental-basedir={이전 증분 백업 경로} {백업 경로}

증분백업 복원 방법

1. 복원 준비

아래와 같이 증분 백업 파일을 전체 백업 파일에 추가하는 작업이 진행되어야합니다.

증분 백업을 합칠때 여러개의 증분 백업이 있다면 순차적으로 추가 작업을 진행하시기 바랍니다.

innobackupex --apply-log --redo-only {전체 백업 경로}

innobackupex --apply-log --redo-only {전체 백업 경로} {증분 백업 경로}

innobackupex --apply-log {전체 백업 경로}

2. 복원

전체 백업 복원하는방법과 동일합니다.

# service mysqld stop

# rm -rf {mysql datadir}/*

# innobackupex --copy-back {full백업 경로}

# copy 작업 완료 후 폴더 권한 변경

# chown -R mysql:mysql {mysql datadir}

# service mysqld start

[출처] xtrabackup 사용법|작성자 엔클라우드24

선행 작업

Master에서 Slave로 동기화하기를 원하는 DB(및 Table)은 미리 Dump를 떠서 최초 1번은 Slave에 생성해 놓아야 한다.

Master 서버 설정

우선 server-id가 1로 설정되어 있는지 확인한다.

Master는 보통 1로 설정한다. 그래야 Slave에서 부가적인 설정을 할 필요가 없다.

이번엔 mysql에 접속해서 상태를 확인한다.

File, Position 값을 각각 메모해 둔다(mysql-bin.189, 91120973).

마지막으로 본 서버에 접속해서 동기화 받아갈 Slave 서버들에 권한을 주자.

*.*은 DB.Table 이고 %는 ip 모두 허용... 인데 GRANT는 익숙한 구문이므로 자세한 설명은 생략한다.

Slave 서버 설정

Master와 같이 server-id 값을 확인한다.

는 Master와 다른 값을 가져야 하므로 2로 수정하는게 좋겠다.

Slave의 mysql에 접속해서 동기화 받을 DB가 존재하는 Master 서버의 정보를 입력할 차례다.

Master에서 메모한 2개의 값을 MASTER_LOG_FILE 부분과 MASTER_LOG_POS 부분에 대입한다.

Slave가 Master에게서 제대로 동기화 받아오는지 확인해 보자.

Waiting for master to send event 문구가 표시되면 정상이다.

여기서 일단 끝인데... 조금 더 세부적으로...

모든 DB를 동기화하는 것이 아니라, 특정 DB 특정 Table만 동기화 하고 싶다면 아래와 같이 my.cnf 파일에 설정한다.

• Slave에 설정할 수도 있고 Master에 설정할 수도 있다.
• 한 라인에 여러 값을 기입할 수는 없었다. 여러 라인에 각각 지정해야 한다.
• replication-ignore-table은 동기화 받지 않을 테이블만 기록하는 설정이다.
  이 외에도 여러 설정이 존재한다(더 자세한건 구글링을).

MYSQL5.1 버전을 설치했다.

에러없이 정상적으로 설치한거 같은데 root 비밀번호가 틀리다고 나온다.

몇번을 다시 삭제하고 재설치했는데도 불구하고 기존에 설치시 입력한 비밀번호를 입력하라는 메세지가 나온다.

삭제가능한 모든 mysql 관련 정보를 regedit 에서 삭제했는데도 불구하고 동일한 문제가 발생했다.

차마 safemode 까지 들어가서 regedit 를 수정하기는 쪼매 귀찮고...

하여튼 찾아보던 중 mysqld 를 이용한 간단한 root 비밀번호 변경 방법이 있었다.

1. 내컴퓨터 > 속성 > 서비스 및 응용 프로그램 > 서비스 까지 찾아 들어가서 MYSQL 프로세스를 중지시킨다.

2. command 창을 열어 아래 명령어 구문으로 mysql 을 구동한다.

c:>mysqld --skip-grant

3. 와와같이 --default-character-set 과 관련된 오류 메세지가 출력되고 콘솔창이 멈춘다. (=mysql 이 실행된 상태이며 오류메세지는 전혀 별개의 문제인듯 하니 그냥 pass..)

4. 그 상태에서 새로 command 창을 열고 비밀번호 없이 root 로 로그인한다.

5. 로그인되었음을 확인할 수 있다. 여기서 root 비밀번호를 변경한다.

mysql> use mysql

Database changed

mysql> update user set password=password('1234') where user='root';

Query OK, 1 row affected (0.2 sec)

Rows matched: 1 Changed: 1 Warnings:0

mysql> flush privileges; 

6. 완료

LVM은 Linux 시스템에서 디스크 Volume을 논리적으로 관리할 수 있도록 해준다.

대략적인 구조는 아래와 같다.

LVM의 기능중에 Logical Volume 스냅샷 생성 기능을 활용하면,

InnoDB 스토리지 엔진의 경우 온라인 백업(Hot Backup)을 수행할 수 있고,

MyISAM의 경우에는 몇 초 정도의 TABLE LOCK으로 온라인 백업을 수행할 수 있다. (Warm Backup)

Logical Volume의 스냅샷을 생성하면, 즉시 Logical Volume 간 물리적인 복사가 이루어 지는 것은 아니고,

스냅샷 Volume 상에 Exception Table이라는 것이 생성되어 변경된 디스크 블럭의 정보를 보관하여,

그 정보를 바탕으로 스냅샷 생성 시점의 데이터를 읽을 수 있도록 해준다.

LVM을 이용한 MySQL 스냅샷 백업을 위해서는 아래와 같은 환경이 구성되어 있어야 한다.

- Linux 시스템에 LVM이 설치되어 있어야 한다. (LVM 1, 2 모두 가능)

- MySQL의 data 디렉토리는 LVM의 Logical Volume 상에 존재해야 한다.

data 디렉토리로 사용할 Logical Volume의 크기는,

DB의 사이즈 뿐만 아니라, 스냅샷을 생성을 위한 Volume의 크기까지 고려해서 결정해야 한다.

스냅샷 Volume의 크기는 원본 Volume의 50% 정도면 충분하다.

<snapshot 백업 순서>

1. MyISAM 스토리지 엔진 사용시 테이블 락을 설정한다.

mysql> FLUSH TABLES WITH READ LOCK;

Query OK, 0 rows affected (0.01 sec)

2. 스냅샷 Volume을 생성한다.

# lvcreate --snapshot  -L 10G -n backup /dev/vg/mysqldata

lvcreate -- WARNING: the snapshot will be automatically disabled once it gets full

lvcreate -- INFO: using default snapshot chunk size of 64 KB for "/dev/vg/backup"

lvcreate -- doing automatic backup of "vg"

lvcreate -- logical volume "/dev/vg/backup" successfully created

현재 MySQL Data 디렉토리가 있는 Logical Volume(mysqldata)의 스냅샷을 생성하였다.

스냅샷 Volume의 이름은 backup으로 지정하였고, /dev/vg/backup 생성하였다.

(스냅샷 생성 시간은 1~2초 정도 걸렸다.)

스냅샷 생성 결과는 lvscan 명령으로 확인해 보면 된다.

#  lvscan

lvscan -- ACTIVE   Original "/dev/vg/mysqldata" [20 GB]

lvscan -- ACTIVE   Snapshot "/dev/vg/backup" [9.96 GB] of /dev/vg/mysqldata

lvscan -- 2 logical volumes with 29.96 GB total in 1 volume group

lvscan -- 2 active logical volumes

3. 1번 과정에서 테이블 락을 설정하였다면, 락을 해제한다.

mysql> UNLOCK TABLES;

Query OK, 0 rows affected (0.00 sec)

4. Snapshot Volume을 백업을 위한 새로운 MySQL 데몬의 data 디렉토리로 Mount 하고,

   mysqldump 툴을 사용하여 백업을 받는다.

# mount -t ext3 /dev/vg/backup /usr/local/mysql_backup/data/ 

# /usr/local/mysql_backup/safe_mysqld &

# /usr/local/mysql_backup/bin/mysqldump --all-databases > backup.sql

MySQL DB의 스냅샷 백업이 진행되는 동안에도, 기존 MySQL 서버는 정상적으로 서비스 되므로

백업에 영향을 받지 않고, 정상적으로 서비스를 유지할 수 있다.

하지만 스냅샷 생성을 하면 해당 시점부터 원본 Volume과 스냅샷 Volume에 대해 중복으로 I/O가 발생하며,

변경 작업이 과도하게 많이 일어나거나, 외부 스토리지가 아닌 일반적인 SCSI, SATA 디스크를 쓰는 경우,

스냅샷 유지를 위해 증가한 I/O로 인하여 퍼포먼스 저하를 일으킬 수 있으니 유의하자.

6. 백업을 위한 임시 MySQL 데몬을 종료하고, 스냅샷 Volume을 삭제한다.

# /usr/local/mysql_backup/bin/mysqladmin shutdown

# umount /dev/vg/backup

# lvremove -f /var/vg/backup

lvremove -- doing automatic backup of volume group "vg"

lvremove -- logical volume "/dev/vg/backup" successfully removed

백업이 완료된 후에는 스냅샷 Volume을 반드시 삭제해야 한다.

<장점>

- 테이블 락으로 인한 서비스 중단없이 시점 백업을 받을 수 있다. (온라인 백업)

- 리플리케이션 Slave 구성을 간편하게 할 수 있다.

<단점>

- 스냅샷 생성 후 유지하는 동안 I/O가 늘어난다.

- LVM 자체에 대한 안정성 검증(LVM 버그 등)이 필요하다. (Volume이 날라가 버린다면 낭패..)

[출처] LVM을 이용한 MySQL 스냅샷 백업|작성자 돌고래사육사

원본 위치 <http://blog.naver.com/PostView.nhn?blogId=seuis398&logNo=70020889375&beginTime=0&jumpingVid=&from=search&redirect=Log&widgetTypeCall=true&topReferer=http%3A%2F%2Fsearch.naver.com%2Fsearch.naver%3Fsm%3Dtab_hty.top%26where%3Dnexearch%26ie%3Dutf8%26query%3DLVM%2Bsnapshot