hello world » L4/L7 스위치의 대안, 오픈 소스 로드 밸런서 HAProxy
1. MySQL 데이터베이스 최적화, MySQL 성능을 200%로 MySQL 모니터링과 서버 튜닝 MySQL이 오픈소스이기 때문일까? 오라클이나 MS-SQL의 경우 적절한 하드웨어에 온갖 튜닝이 다 된 상태로 사용하는 반면 MySQL은 그저 설치만 한 상태로 사용하는 경우가 많다. MySQL에 문제가 있다고 해서 기술지원을 나가보면 기본적인 설정에도 문제가 있는 경우도 허다하다. 우선 현재 시스템에 대한 모니터링을 통해 MySQL이 적절히 작동하고 있는지와 문제가 무엇인지부터 파악하자. MySQL 데이터베이스 모니터링 튜닝의 시작은 현재 시스템의 상태와 문제점을 파악하는 것이 가장 우선일 것이다. 이를 위해 여러 가지 방법을 통해 시스템을 모니터링하는 것이다. 현재 MySQL을 모니터링하는 방법은 3가지가 있다. 첫째로 커맨드라인 명령어들을 이용해 모니터링하는 것이며 두 번째는 GUI 기반의 관리 툴인 MySQL Administrator를 통한 모니터링하는 것이다. 마지막으로 MySQL이 남긴 각종 로그를 통한 모니터링이 있다. 먼저 가장 기본적인 모니터링 방법인 커맨드라인 명령어들을 통한 모니터링에 대해 알아보자. 커맨드라인 명령어들을 통한 모니터링 커맨드라인 명령어들을 통한 모니터링의 가장 큰 장점은 어떤 환경에서도 수행이 가능하며 가장 빠르고 정확하게 자신이 원하는 바를 알아낼 수 있다는 것이다. MySQL의 커맨드라인 프로그램과 각종 SHOW 명령어들에 대해 자세히 살펴보자. mysqladmin SHOW ENGINES mysql >SHOW ENGINES SHOW VARIABLES SHOW STATUS SHOW PROCESSLIST SHOW TABLE/TABLE STATUS/INDEX/INNODB STATUS GUI 기반의 모니터링 MySQL Administrator MySQL Administrator의 모니터링 기능의 백미는 바로 Health 메뉴이다. Health 메뉴에서는 기본적으로 Connection Health, Memory Health, Status Variables, System Variables 등 네 가지 항목을 가지고 있으며 이전 커맨드라인 모니터링에서 하던 대부분의 모니터링 작업을 여기서 수행할 수 있다. 그리고 가장 큰 특징이라면 기본적으로 보여주는 주요 사항에 대한 모니터링 외에도 SHOW STATUS를 통해 볼 수 있는 모든 항목에 대한 모니터링 그래프를 추가할 수 있다는 것이다. 이를 통해 직관적인 화면상의 변화를 보며 사용자 수의 변화나 시간대별 변화에 대한 쉽고 편한 모니터링을 할 수 있게 되었다. MySQL Query Browser 로그를 통한 모니터링 적절한 수준의 로그를 남기는 것은 빠르고 건강한 MySQL을 유지하는 비결이다. 일반적으로 운영되는 서버라면 에러 로그와 슬로우 쿼리 로그를 남기는 정도로 충분하지만 서비스를 위한 시험 기간이거나 문제를 찾는 시점이라면 일반 쿼리 로그(General Query Log)를 남겨 어떤 쿼리가 가장 많이 사용되는지 파악하고 그 쿼리를 더 빠르게 할 수 있는 방법이 없는지를 찾는 것은 데이터베이스 최적화하는 좋은 방법 중 하나이다. 일반적으로 MySQL을 사용하는 사용자들의 경우 기본적으로 지원하는 에러 로그만을 남기고 슬로우 쿼리 로그를 남기지 않는 경우가 많은데 슬로우 쿼리는 MySQL의 성능을 떨어뜨리는 주범이다. 반드시 슬로우 쿼리 로그를 남기고 확인해 개선점을 찾도록 하자. MySQL 서버 튜닝 MySQL의 튜닝은 MySQL의 데이터베이스 시스템 관련 파라미터들에 대한 튜닝과 각각의 스토리지 엔진 관련 튜닝으로 나눠진다. 이번 호에서는 MySQL의 데이터베이스 시스템 즉 MySQL 전체 성능에 영향을 미치는 튜닝에 대해 알아보고 각각의 스토리지 엔진에 대한 튜닝과 최적화는 다음 호에 알아보자. MySQL의 시스템 관련 튜닝은 MySQL의 설정 파일인 my.cnf(윈도우의 경우는 my.ini) 파일을 수정하게 되며 MySQL 커넥션에 관한 부분과 메모리에 관한 부분으로 나눌 수 있다. 먼저 커넥션에 관한 부분부터 살펴보자. MySQL 커넥션 튜닝 실제적으로 MySQL이 가장 많이 사용되는 분야를 꼽는다면 역시 인터넷 분야라고 할 수 있다. 포탈 사이트나 게임 사이트 등 부하가 매우 많이 발생하는 사이트에서 가장 문제되는 것은 MySQL의 커넥션에 관련된 문제이다. 커넥션에 관련된 모니터링은 SHOW STATUS LIKE ‘%CONNECT%’로 알아 볼 수 있다. mysql> SHOW STATUS LIKE ‘%CONNECT%’; connect_timeout/interactive_timeout/wait_timeout connect_timeout은 MySQL이 클라이언트로부터 접속 요청을 받는 경우 몇 초까지 기다릴지를 설정하는 변수이다. 기본 값은 5초이며 일반적으로 수정할 필요는 없다. Interactive_timeout은 ‘mysql>’과 같은 콘솔이나 터미널 상에서의 클라이언트 접속을 말한다. 기본 값으로 8시간이 잡혀 있으나 1시간 정도로 낮추는 것이 좋다. 이런 접속은 그다지 빈번하지 않으며 작업을 위해 접속하는 경우가 많기에 따로 설정하지 않아도 큰 영향은 없다. 가장 중요한 것은 wait_ timeout으로 wait_timeout은 접속한 후 쿼리가 들어올 때까지 기다리는 시간이다. 접속이 많은 데이터베이스 시스템에서는 이 값을 낮춰 sleep 상태로 커넥션만 유지하고 있는 클라이언트들의 접속을 빠르게 끊어줘 동시 접속을 낮추는 것으로 전체 성능을 크게 향상시킬 수 있다. 하지만 주의할 점은 너무 낮추게 되면 실제로 서비스를 하기도 전에 끊어진다든지 지나치게 잦은 커넥션이 발생한다는 것이다. 일반적으로 15~20 사이의 값이 적당하며 SHOW STATUS를 통해 aborted_client가 가장 적게 발생하도록 값을 맞춰야 한다. Aborted client는 2% 아래인 것이 바람직하며 물론 없는 것이 가장 좋은 상태이다. net_buffer_length/max_allowed_packet max_connections/back_log skip-name-resolve MySQL 메모리 튜닝 사실 데이터베이스 시스템 튜닝은 메모리 관련 파라미터를 조정하는 것이 90% 정도를 차지한다고 할 수 있을 정도로 데이터베이스 시스템의 성능은 메모리 관련 설정들에 큰 영향을 받는다. MySQL의 메모리 부분 튜닝은 사실 대부분 스토리지 엔진에 특화된 부분이다. 하지만 시스템 전체에 영향을 미치는 메모리 설정이 있는데 쓰레드 관련 메모리 설정과 쿼리 캐시관련 메모리 설정이 그러하다. 먼저 쓰레드 관련된 메모리 설정부터 살펴보자 쓰레드 관련 메모리 튜닝 MySQL은 커넥션마다 하나의 쓰레드를 생성시켜 요청을 처리하게 된다. 그래서 쓰레드가 생성되는 시점에 쓰레드에 메모리가 할당되며 많은 쓰레드가 생성되고 사라지면서 과부하가 발생한다. 일반적인 시스템에서는 쓰레드 관련 파라미터들의 조정할 필요는 없지만 부하가 심한 서버에서는 모니터링 결과에 따라 이 설정을 변경해 성능 향상을 이룰 수 있다. 먼저 현재 쓰레드와 관련된 상태를 알아보자. mysql> SHOW STATUS LIKE ‘%THREAD%’; 앞에서 볼 수 있는 항목 중 Threads_connected가 Threads_ cached에 비해 매우 높다면 thread_cache_size를 높여줄 필요가 있다. Thread_cache_size는 지나치게 높여둘 필요는 없으며 일반적으로 threads_connected의 피크 치보다 약간 낮은 수치 정도를 설정하는 것이 좋다. 이를 통해 쓰레드가 생성되고 소멸되면서 겪게 되는 메모리, 각종 자원, 시간 등의 낭비를 줄일 수 있다. 쓰레드와 관련해 또 하나 설정할 수 있는 옵션은 thread_concurrency인데 이 옵션은 솔라리스 외의 시스템에서는 신경 쓸 필요가 없으며 솔라리스에서는 CPU 수에 2를 곱한 값을 넣어주면 된다. 캐싱 관련 메모리 튜닝 쿼리 캐시란? 쿼리 캐시란 빈번하게 수행되는 Select 관련 쿼리와 쿼리의 결과를 임시 저장하는 캐시 메모리이다. 데이터베이스 시스템에서 가장 시간이 많이 걸리는 것은 바로 디스크를 액세스하는 작업이다. 그러므로 디스크를 액세스하는 작업을 줄이는 것이 가장 크게 성능을 올리는 것이다. 쿼리 캐시는 Select 쿼리에만 해당되며 쿼리 캐시를 사용하지 않게 되거나 쿼리 캐시에 저장된 내용을 초기화하게 되는 경우는 다음과 같다. ◆ 데이터나 테이블 구조가 변경되었을 때 현실적으로 어려운 이야기지만 이 같은 경우는 줄이면 줄일수록 쿼리 캐시의 사용률과 효율을 높여 더 빠른 성능을 기대할 수 있다. 쿼리 캐시의 사용 먼저 현재 사용하고 있는 MySQL이 쿼리 캐시를 지원하는 버전인지 아닌지 확인하자. mysql> SHOW VARIABLES LIKE ‘HAVE_QUERY_CACHE’; 만약 쿼리 캐시가 없는 MySQL 버전을 사용하고 있다면 가능하면 업그레이드를 하도록 한다. 가장 쉽고 확실한 성능 향상법은 최신 버전의 소프트웨어를 사용하는 것이라는 것을 잊지 말자. MySQL의 경우 특히 4.1 버전 이후로 많은 부분에 있어 성능과 기능이 향상되었다. 아직도 3.x 버전을 사용하고 있다면 이번 기회에 업그레이드를 고려해 보는 것이 좋다. 쿼리 캐시를 지원하는 버전일 경우 ‘query_cache_size=64M’와 같은 방식으로 정확한 쿼리 캐시 크기를 정해 주는 것만으로 쿼리 캐시를 사용하게 된다. 그리고 쿼리 캐시의 동작 방식을 정해주는 옵션으로 query_cache_type이라는 옵션이 있는데 0은 쿼리 캐시를 비활성화시키게 되고 1은 사용 가능한 모든 쿼리가 쿼리 캐시를 이용하게 되며, 2는 쿼리 캐시를 이용하라고 정해주는 쿼리만 쿼리 캐시를 이용하게 된다. 2의 경우는 쿼리문 뒤에 SQL_CACHE라고 덧붙여주면 된다. 쿼리 캐시 최적화 데이터베이스 관련 모든 메모리 설정은 높다고 다 좋은 것이 아니다. 중요한 것은 균형 값을 찾아내는 것이다. 왜냐하면 쿼리 캐시와 MyISAM의 키 캐시, InnoDB의 버퍼 풀은 소중한 메모리 공간을 놓고 서로 경쟁하는 관계이기 때문이다. 먼저 쿼리 캐시 크기를 결정해야 한다. 일반적으로 시스템 전체 메모리의 5%에서 10% 사이를 사용하는 것이 보통이다. 일단 이 사이의 값으로 설정한 후 모니터링을 통해 쿼리 캐시 사용률이 100%에 가깝도록 하는 것이 좋다. 이를 모니터링하는 가장 좋은 방법은 MySQL Administrator를 사용하는 것으로 MySQL Administ rator의 Health 부분에서 쿼리 캐시의 효율을 지속적으로 모니터링할 수 있기 때문이다. 다음으로 쿼리 캐시에서 받아들일 쿼리의 최대 크기를 설정하는 것이 필요하다. Query_cache_limit 옵션으로써 기본 값은 1MB이나 이는 너무 큰 값일 경우가 많다. 빈번하게 사용되는 쿼리의 용량이 어느 정도인지 살펴본 후 이보다 10% 정도 높은 값을 설정하자. DB 튜닝은 과학이 아니라 예술 데이터베이스의 튜닝은 무조건 높고 가장 좋은 것을 찾는 과학이라기보다는 균형의 미를 찾는 예술이라고 할 수 있다. 하나를 높이면 그만큼 다른 부분에서 손해를 보는 만큼 그 사이의 최적의 값을 찾는 것이 중요하며 이는 지속적인 모니터링으로 얻어질 수 있는 부분이다. 이번 호에서는 MySQL의 모니터링과 서버 전반에 대한 튜닝에 대해 알아봤다. 다음 호에는 MySQL의 성능과 바로 직결되는 부분인 MyISAM과 InnoDB 두 스토리지 엔진의 튜닝에 대해 알아보기로 하며 이번 연재를 통해 많은 분들이 MySQL의 진정한 성능을 느껴 볼 수 있길 바란다. 저자 : 김병준│아이티브릿지 MySQL AB의 국내 골드 파트너인 아이티브릿지(www.itbridge.co.kr)의 MySQL 기술지원 팀장으로 MySQL을 비롯한 오픈소스에 대한 컨설팅과 튜닝 업무를 맡고 있다. 오픈소스 애플리케이션들을 기업 환경에 적절히 적용하는 것에 관심이 많다.
◘ 네트워크 관련 명령어 ▪ ping 명령어 : 네트워크 환경 장비들 간의 통신이 잘 되고 있는지 확인하는 명령어. ICMP 프로토콜을 이용하여 로컬 호스트와 외부와의 통신이 이루어지고 있는지 테스트하기 위한 네트워크 명령어로 결과값 중 TTL 값으로 사용되는 운영체제도 알 수 있음. – # ping [option] 호스트 -c : ping 테스트 시 지정한 수만큼의 패킷을 보냄. 기본 무한 -s : ping 테스트 시 보내는 패킷의 바이트 수를 지정. 기본 56Byte -i : ping 테스트 시 몇 초 간격으로 패킷을 보낼지 설정. 기본 1초 -w : ping 테스트 시 패킷을 보내고 몇 초 후에 실행을 멈출것인지 설정 : 라우팅과 관련된 정보를 얻기 위한 명령어. 라우팅 테이블을 화면에 표시. – # netstat -a | grep LISTEN : 열려 있는 포트를 출력 (= # netstat -atp) ▪ traceroute 명령어 : 네트워크 통신 경로를 확인하는 명령어로 패킷이 목적지까지 전달되는 경로를 확인하는 명령어. ICMP를 이용하여 TTL값을 포함하고 있는 패킷을 전송하여 반환값을 출력. – # traceroute -i eth1 168.126.63.1 : 특정 인터페이스를 통해 목적지의 호스트까지 경로 확인 ▪ My traceroute 명령어 : 콘솔 상에서의 traceroute와 동일한 GUI 환경에서의 네트워크 통신 경로 확인 명령어 ▪ rpcinfo 명령어 : 한 프로그램이 네트워크 상의 다른 호스트의 프로그램에 서비스를 요청하는 데 사용되는 프로토콜인 RPC의 정보를 확인하는 명령어 – # rpcinfo [ -n <포트번호> ] -t 호스트 프로그램 번호 [ 버전번호 ] – # rpcinfo -p [ <호스트> ] – # rpcinfo -b 프로그램번호 버전번호 – # rpcinfo -d 프로그램번호 버전번호 ▪ arp 명령어 : IP 주소를 하드웨어 주소인 MAC 주소로 변경해 주는 명령어. ARP cache는 IP 주소와 MAC 주소의 목록을 유지하는데 사용되는 메커니즘으로, 서로 간에 맵핑된 정보는 cache에 잠시 동안 보관되는데 최근에 맵핑된 정보를 보기 위해 사용하는 명령어가 바로 arp임. – # arp [option] 호스트 -a : 지정한 호스트에 대한 정보를 출력하며, 호스트를 지정하지 않을 경우에는 현재 캐시에 들어있는 모든 정보를 출력 -s : 캐시에 저장된 특정 IP 주소에 대한 MAC Address 변경 -d : 캐시에 저장된 특정 MAC Address 삭제 -i : 지정한 네트워크 인터페이스의 ARP를 출력 iptables 명령은 리눅스 IPv4 방화벽을 설정하는 명령어이다. 1.1 시리즈 부터 리눅스 커널은 패킷 필터링을 포함하기 시작했다. <리눅스매거진 편집부> # iptables –version iptables 1.2.4 커널은 3가지의 방화벽 체인(chain)을 기본적으로 가지고 패킷 필터링을 시작한다. 파이어월 체인 혹은 체인이라 부르는 이 3가지는 입력(Input), 출력(Output), 전달(Forward)이다. 입력체인은 들어오는 패킷을 조사하고 전달체인은 외부의 다른 시스템으로 전달될 패킷을 조사한다. 마지막으로 출력체인은 외부로 나가는 패킷을 조사한다. ■ 패킷검사방법 사용법 Commands chain Options 사용예 # ping -c 1 127.0.0.1 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.2/0.2 ms # iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP # ping -c 1 127.0.0.1 1 packets transmitted, 0 packets received, 100% packet loss ■ 설정된 iptables 규칙의 삭제 #iptables -D INPUT 1 ■ 체인 규칙 나열하기 # iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP Chain INPUT (policy ACCEPT 709 packets, 35362 bytes) pkts bytes target prot opt in out source destination 0 0 DROP icmp — any any localhost.localdomain anywhere Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 423 packets, 39549 bytes) pkts bytes target prot opt in out source destination ■ 체인 비우기 #iptables -F INPUT ■ 출처와 목적지 지정 세번째와 네번째 방법은 IP 주소의 그룹을 지정하는 것으로 ‘199.95.207.0/24’ 또는 ‘199.95.207.0/255.255.255.0’ 같은 형태이다. 이 둘은 모두 199.95.207.0 부터 199.95.207.255 사이의 모든 IP 주소를 지정한다. ‘/’ 다음의 숫자는 IP 주소의 어떤 부분이 의미 있는가를 나타낸다. ‘/32’ 나 ‘/255.255.255.255’ 가 기본 값이다.(IP 주소의 모든 부분이 일치해야 한다.) 모든 IP 주소를 지정하는데 ‘/0’ 가 사용된다. # iptables -A INPUT -s 0/0 -j DROP ■ 프로토콜 지정 ■ TCP 확장 –tcp-flags # iptables -A INPUT –protocol tcp –tcp-flags ALL SYN,ACK -j DROP –syn –source-port, –sport –destination-port, –dport –tcp-option ■ iptables를 통한 포트관리 iptables -A INPUT -p tcp –dport 25 -j ACCEPT 이렇게 하면 먼저 25번 포트로 들어오는 것을 허용하고 난 후에 다른 것을 막아내기 때문에 제대로 된 설정이 된다. iptables -A INPUT -p tcp –dport 22 -j ACCEPT ■ 전체적인 설정 # ssh 열기 # httpd 열기 # pop3 열기 # pop2 열기 # imap 열기 # mysqld 열기 # ftpd 열기 # ftp-data 열기 # ircd 열어주기 # 전부 거절하기 /usr/local/bin/iptables -A INPUT -p icmp –icmp-type echo-request -j DROP 이처럼 허용하는 서비스가 한정적이다. 우선 ssh, http, pop3, pop2, imap, mysql, ftp, ircd를 위해서 서비스를 요청하는 패킷은 허용하고 나머지는 전부 거부하는 설정이다. 이 설정을 자세히 보면 tcp와 icmp를 대상으로 했다. 거절하는 줄인 /usr/local/bin/iptables -A INPUT -p tcp –dport 1:30000 -j DROP 이 라인에서 –dport 다음에 1:30000으로 지정돼 있다. 이 부분은 서버를 경유해서 다른 곳으로 가고자하는 경우에 클라이언트 프로그램이 사용할 포트를 남겨주기 위함이다. 1번포트에서 30000번 포트까지는 완전히 tcp에 대해서 막는 것이다. [외부망으로 나가는 경우의 설정] 1. IPTABLE의 설정(Linux Kernel 2.4) 참고) ip_conntrack_ftp와 ip_nat_ftp 는 ftp서비스 open을 위해서 설정한 것이다. 만일 기존 Linux에 ipchain이 드라이버가 이미 Loading되어 있다면 기존 ipchain 드라이버를 제거하고 iptables driver를 Loading한다. Linux:/> rmmod ipchains Linux:/> insmod ip_tables 2. IPCHAIN의 설정 방법(Linux Kernel 2.2) echo 1 > /proc/sys/net/ipv4/ip_forward 2) 2nd IPCHAIN의 설정 방법 3. 자동으로 실행되기 Linux에서 /etc/rc.local에 위에 있는 내용을 넣어둔다. 그러면 자동으로 등록이 된다. 4. 설정값 확인하기 Linux:/> iptables -t nat -L tcp 프로토콜을 사용하여 들어오는 패킷들중에 Buy Now 라는 문구가 포함된 패킷은 거부하고, 리셋한다. 출처 : http://cafe.naver.com/okjsp/279 http://wiki.kldp.org/Translations//html/Packet_Filtering-KLDP/Packet_Filtering-KLDP-7.html ※ Advanced Firewall host기반의 방화벽은 랜카드가 1개가 필요한다. network기반의 방화벽은 랜카드가 여러개가 필요하다. ※ mail server, web server, DNS server 같은것들은 내부망으로 되어 있는데 보안상 위험하기 때문에 외부망으로 연결되게끔 분리해놓는다. ※ TCP(Layer 4(Transport)) MATCHES : 연결지향적이다. ※ UDP(Layer 4(Transport)) MATCHES : 연결없이 데이터를 전송받는다. 무조건 보내기만 한다. ※ ICMP(Internet Control Messaging Protocol) MATCHES -p icmp, –protocol icmp 실습!!!! serv 컴에서… 문제… iptables -A OUTPUT -p icmp -icmp-type echo-request -j DROP work 컴에서… ********************************************************************************************************************************************* ※ Match multiple port with fewer rules 이렇게 여러줄을 한줄로 표현할수가 있다. 예전에 저장했던것을 불러오고 싶으면 … -> iptables-restore < default.rules ※ MAC address filtering ※ iptables -F INPUT ping -c 2 serv -> 접속이 잘 됨. 이것이 문제가 된다… ip만 바꾸면 쉽게 접근을 할수가 있다. iptables -R INPUT 1 -m mac –mac-source 00:0C:29:4E:93:E5 -j DROP ※ Rule Targets vi /etc/syslog.conf log를 언제든지 볼수 있도록 화일로 저장하는것이 좋다. service syslog restart 문제…. iptables -A INPUT -m multiport -p tcp !–dport 21, 22, 23 -j LOG ********************************************************************************************************************************************* ※ Firewall LOG Log-prefix serv 컴에서… ※ Portsentry 특징 download 위치 설치후 파일 iptables -A INPUT -m state –state ESTABLISHED, RELATED -j ACCEPT work 컴에서… serv 컴에서… work 컴에서… serv 컴에서… ※ Portsentry 실행모드 MySQL을 DB로 사용하면서 서버의 부하 분산을 위한 방법 중 하나로 Replication 을 사용한다. Replication 은 Master 하나에 n개의 Slave로 지정이 가능하다. Slave는 다시 Master 역할을 할수 있으며 역시 또 다른 n개의 Slave를 지정할 수 있다. 부하 분산의 효과는 inser,update 등 변경과 관련된 모든 작업은 Master에서 실행을 하고, select 등 읽기과 관련된 작업은 Slave를 통하여 작업을 함으로서 읽기와 쓰기에 대한 부하분산이 가능하다. MySQL의 Replication 은 비동기 방식으로 처리 되며, Master 에서 변경된 내용이 Slave에 적용이 된다. MySQL 에서 Replication 이 적용되는 방식은 아래 그림을 요약할 수 있다. 1. Master 에서 데이터의 변경작업이 발생하면 Master DB의 변경 실행 2. 변경된 이력을 Binary Log 에 기록 3. Slave 의 IO Thread 가 Master 의 변경 Event 를 감지하고 Master 의 Binary Log 를 자신(Slave)의 Relay Log 에 기록한다. 4. Slave 의 SQL Thread 는 Relay Log 를 읽고 자신(Slave)의 DB에 기록한다. 위 그림에서처럼 Master 에서 Slave 방향으로 단방향으로만 처리가 이루어 지므로 변경작업(Write)는 Master에만 하여야 한다. Slave에서 변경작업을 할 경우 Master에는 당연히 반영이 안되며, Slave에서 변경작업한 Object 에 대하여 Master 서 변경작업을 다시 시도할 경우 변경은 되지만 다시 slave에 는 적용되지 않는다. MySQL Replication 설정 1. 기본적으로 Master와 Slave로 사용할 Mysql 서버가 각각 설치되어 있어야 한다. 가능하면 물리적으로 다른 서버가 필요하지만 port 를 달리 설치한 물리적 동일 서버내에서 테스트하는것도 가능할것 같다. Replication 기능은 3.23.15부터 지원되기 시작하였으나, 3.23.32부터 안정화 되었기에 가능하면 최신버전의 MySQL 을 권한다.(현재 5.6 버전이 release 되었는데……) 설정 요약 -. Master 1개에 Slave 1개를 지정 -. Master IP: 192.168.0.1 server-id = 1 replication 대상 db명 : classmate 계정 : root(‘rootpassword’) replication 권한 계정 : rep(‘reppassword’) -. Slave IP : 192.168.0.2 server-id = 2 1. Master 계정생성 -. Slave 에서 Master 로 접근 할수 있는 계정이 필요하다. 이 계정은 ‘REPLICATION SALVE’ 권한이 기본적으로 필요하다 Master 서버에서 아래와 같이 권한을 지정한다. 2. Master Data 를 Slave로 복사 -. HOT 백업 -. mysqldump 이용 백업 slave Shell > mysql -u root -p ‘rootpassword’ classmate < dump_classmate.sql db 명 : classmate 3. Master 환경설정 -. master의 my.cnf 파일을 수정한다. -. master 의 server-id 를 1로 지정한다.(다른숫자 값으로 하여도 상관없다. slave 와 중복되지 않으면 된다(1~(2^32)-1내의 숫자) -. [mysqld]섹션에 위와 같이 log-bin 이 존재하는지 확인한다 4. Master 의 Replication 정보 조회 master mysql> SHOW MASTER STATUS; +——————+———-+————–+——————+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +——————+———-+————–+——————+ | mysql-bin.000001 | 98 | | | +——————+———-+————–+——————+ -. File : 로그 파일 -. Position : 로그 파일내 읽을 위치 -. Binlog_Do_DB : binary log 파일(변경된 이벤트 정보가 쌓이는 파일) -. Binlog_Ignore_DB : 복제 제외 정보 n Binlog_Do_DB와 Binlog_Ignore_DB는 Slave 시작하기 전까지는 나타나지 않는다. -. File 과 Position 정보가 ‘7’의 과정에서 필요하다. 5. Slave 환경 설정 -. slave 의 my.cnf 파일을 수정한다. slave shell> vi /etc/my.cnf [mysqld] master-port = 3306 6. Slave 서버 Start -. 2의 과정에서 HOT 백업을 하였다면 Slave 서버의 mysql data 디렉토리에 master 서버의 데이터를 복사하고, mysqldump 를 이용하여 백업하였다면, mysql 서버를 start 후 dump 파일을 load 한다. slave shell > /etc/init.d/mysqld start 2에서 mysldump 로 dump 한 dump_classmate.sql 파일을 slave 로 복사 후 slave Shell > mysql -u root -p ‘rootpassword’ classmate < dump_classmate.sql (db 명 : classmate) master에서 classamte db를 dump 한 dump_classmate.sql 파일을 이용하여 slave의 clsssmate db로 load(slave에는 classmate 라는 db가 존재하여야 함) 7. Slave 정보 설정 -. Slave 에서 Master로 연결하기 위한 정보를 설정한다. slave mysql > CHANGE MASTER TO MASTER_HOST=’192.168.0.1′, MASTER_USER=’rep’, MASTER_PASSWORD=’reppassword’, MASTER_LOG_FILE=’mysql-bin.000001′, MASTER_LOG_POS=98; -. 4에서 조회한 master 의 logfile과 position 정보를 지정한다. 8. Slave Start 이제 Master 변경이 되면 자동으로 Slave에서도 변경된 것을 확인 할 수 있다. 몇가지 Test 내용 -. 기본적인 master에서 데이터입력과 slave에서의 확인 1. master의 classmate DB의 tb_textbook 정보 조회 master mysql> select * from tb_textbook; +————-+————+—————+—————+——–+———–+————–+———+———–+ | textbook_id | subject_id | textbook_type | textbook_name | author | publisher | publish_year | main_yn | refer_url | +————-+————+—————+—————+——–+———–+————–+———+———–+ | 7 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | | 6 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 2 | +————-+————+—————+—————+——–+———–+————–+———+———–+ 2 rows in set (0.00 sec) 2. master 에서 tb_textbook에 1개의 row 등록 master mysql> INSERT INTO `classmatetest`.`tb_textbook` (`textbook_id`, `subject_id`, `textbook_type`, `textbook_name`, `author`, `publisher`, `publish_year`, `main_yn`, `refer_url`) VALUES (’10’, ‘2’, ‘2’, ‘교양 컴퓨터’, ‘교수님’, ‘출판사’, ‘2013’, ‘n’, ‘http://hibrain.net’); mysql> select * from tb_textbook; +————-+————+—————+——————+———–+———–+————–+———+——————–+ | textbook_id | subject_id | textbook_type | textbook_name | author | publisher | publish_year | main_yn | refer_url | +————-+————+—————+——————+———–+———–+————–+———+——————–+ | 7 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | | 6 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 2 | | 10 | 2 | 2 | 교양 컴퓨터 | 교수님 | 출판사 | 2013 | n | http://hibrain.net | +————-+————+—————+——————+———–+———–+————–+———+——————–+ 3 rows in set (0.00 sec) mysql> select * from tb_textbook; +————-+————+—————+——————+———–+———–+————–+———+——————–+ | textbook_id | subject_id | textbook_type | textbook_name | author | publisher | publish_year | main_yn | refer_url | +————-+————+—————+——————+———–+———–+————–+———+——————–+ | 7 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | | 6 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 2 | | 10 | 2 | 2 | 교양 컴퓨터 | 교수님 | 출판사 | 2013 | n | http://hibrain.net | +————-+————+—————+——————+———–+———–+————–+———+——————–+ 3 rows in set (0.00 sec) -. Master 에서의 Table 컬럼정보 변경 1. Master tb_textbook 정보 mysql> desc tb_textbook; +—————+————–+——+—–+———+——-+ | Field | Type | Null | Key | Default | Extra | +—————+————–+——+—–+———+——-+ | textbook_id | int(11) | NO | | NULL | | | subject_id | int(11) | NO | | NULL | | | textbook_type | int(11) | NO | | NULL | | | textbook_name | varchar(100) | NO | | NULL | | | author | varchar(100) | YES | | NULL | | | publisher | varchar(100) | YES | | NULL | | | publish_year | int(11) | YES | | NULL | | | main_yn | char(1) | YES | | NULL | | | refer_url | varchar(200) | YES | | NULL | | +—————+————–+——+—–+———+——-+ 9 rows in set (0.00 sec) -. 컬럼 추가, 삭제의 과정도 마찬가지로 위의 과정과 동일하게 확인이 가능하다 -. Index 생성 master mysql> show index from tb_textbook; +————-+————+————————-+————–+————-+———–+————-+———-+——–+——+————+———+—————+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | +————-+————+————————-+————–+————-+———–+————-+———-+——–+——+————+———+—————+ | tb_textbook | 0 | PRIMARY | 1 | textbook_id | A | 3 | NULL | NULL | | BTREE | | | +————-+————+————————-+————–+————-+———–+————-+———-+——–+——+————+———+—————+ 1 rows in set (0.00 sec) master mysql > ALTER TABLE `classmatetest`.`tb_textbook` ADD INDEX `textbook_subject_id_idx` ( `subject_id` ); mysql> show index from tb_textbook; +————-+————+————————-+————–+————-+———–+————-+———-+——–+——+————+———+—————+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | +————-+————+————————-+————–+————-+———–+————-+———-+——–+——+————+———+—————+ | tb_textbook | 0 | PRIMARY | 1 | textbook_id | A | 3 | NULL | NULL | | BTREE | | | | tb_textbook | 1 | textbook_subject_id_idx | 1 | subject_id | A | 3 | NULL | NULL | | BTREE | | | +————-+————+————————-+————–+————-+———–+————-+———-+——–+——+————+———+—————+ 2 rows in set (0.00 sec) slave에서 확인 mysql> show index from tb_textbook; +————-+————+————————-+————–+————-+———–+————-+———-+——–+——+————+———+—————+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | +————-+————+————————-+————–+————-+———–+————-+———-+——–+——+————+———+—————+ | tb_textbook | 0 | PRIMARY | 1 | textbook_id | A | 3 | NULL | NULL | | BTREE | | | | tb_textbook | 1 | textbook_subject_id_idx | 1 | subject_id | A | 3 | NULL | NULL | | BTREE | | | +————-+————+————————-+————–+————-+———–+————-+———-+——–+——+————+———+—————+ 2 rows in set (0.00 sec) -. now() 와 sysdate() 의 사용에 대한 테스트 now()와 sysdate()의 차이는 MySQL에서의 현재시각조회를 위한 sysdate와 now 의 차이 에서 설명이 되었다. 그중 replication 에서 실제로 어떤 차이가 있는지 확인해 보도록 한다. 먼저 아래와 같은 구조를 가진 임시 table을 생성한다. master mysql> desc tb_timetable; +———+————-+——+—–+———+——-+ | Field | Type | Null | Key | Default | Extra | +———+————-+——+—–+———+——-+ | nowdate | varchar(50) | NO | | NULL | | | sysdate | varchar(50) | NO | | NULL | | +———+————-+——+—–+———+——-+ 2 rows in set (0.00 sec) 그리고 다음의 쿼리로 now()와 sysdate()를 각각 입력하도록 한다. INSERT INTO `classmatetest`.`tb_timetable` (`nowdate` ,`sysdate`)VALUES (NOW( ) , SYSDATE( )); master mysql> select * from tb_timetable; +———————+———————+ | nowdate | sysdate | +———————+———————+ | 2013-02-07 14:50:37 | 2013-02-07 14:50:37 | +———————+———————+ 1 row in set (0.00 sec) slave mysql> select * from tb_timetable; +———————+———————+ | nowdate | sysdate | +———————+———————+ | 2013-02-07 14:50:37 | 2013-02-07 14:41:31 | +———————+———————+ 1 row in set (0.00 sec) 기본적으로 now와 sysdate는 현재시각을 반환하는 함수로 동일한 기능이다. 하지만 replication에서 now를 사용하게 되면 master와 slave에 동일한 값으로 관리가 되지만, sysdate를 사용하게 되면 호출한 시간 반화하는 관계로 master와 slave에 입력된 값이 다르게 되는 문제점이 있다. 이러한 점을 고려하여 어플리케이션에서 sysdate보다는 now 를 사용하는것이 낫고, 그렇지 못한 상황이라면 mysql 의 –sysdate-is-now 옵션을 설정하여 sysdate()와 now()의 함수를 동일하게 적용하도록 한다. 참조 http://hanaduri.egloos.com/2389708 http://linuxism.tistory.com/846 출처 NFS Server/Client 요약 – /etc/dfs/dfstab : NFS로 공유할 Directory 및 mount 될 option설정 (/etc/init.d/nfs.server 스크립트가 읽어서 이 내용대로 NFS 공유.) -/etc/init.d/nfs.server : /etc/dfs/dfstab을 참조 /usr/lib/nfs/nfsd를 구동하는 start script -/etc/dfs/sharetab : 현재 공유설정 해 놓은 file/directory 목록 -/etc/vfstab : 원격으로 mount할 host:dir_path, mount point, fs type, option을 명시한다. -/etc/init.d/nfs.client : /etc/vfstab을 참조하여 mountall (NFS resource mount)실행. 이 스크립트가 실행되면 /usr/lib/nfs/statd, /usr/lib/nfs/lockd 가 실행된다. -/etc/mnttab : 현재 mount된 파일시스템정보를 담고있는 파일(local, remote) -/etc/dfs/fstypes : mount할 파일시스템의 type을 명시해 놓은 파일(default: nfs) -/usr/sbin/mount : local 혹은 remote 파일시스템을 mount(/etc/vfstab을 참조.) 2) 구성daemon 및 파일 -/etc/dfs/sharetab : 현재 공유설정 해 놓은 file/directory 목록 -/etc/rmtab : 현재 원격으로 mount되어 있는 file/directory 및 client목록 -/etc/dfs/fstypes : mount할 파일시스템의 type을 명시해 놓은 파일(default: nfs) -/usr/lib/nfs/statd : 원격으로 mount할 파일시스템의 상태를 감지하는 daemon으로 원격NFS서버에 공유자원에 문제가 생기면 네트워크 연결을 재 시도함. -/usr/lib/nfs/lockd : NFS서버가 client들에게 공유자원의 사용여부를 통보하는데 이 daemon은 서버가 주는 정보에 의거하여 원격공유자원에 읽기/쓰기를 관리한다. Ex) # vi /etc/dfs/dfstab (1)서버의 공유자원을 확인.
Ajax & CORS Overview | WIT – We are UIT
Ajax의
20001030 : AJAX, JSON and XML
MySQL 데이터베이스 최적화
mysqladmin은 MySQL 데이터베이스의 커맨드라인 기반인 관리자 프로그램이다. Mysqladmin을 통해 시스템의 현재 설정 상황과 동작 상황을 모니터링할 수 있다. <표 1>은 mysqladmin을 통해 수행할 수 있는 성능관련 명령어들이다.
명령어
내용
extended-status
MySQL 데이터베이스의 현재 상황을 보여준다.
flust-hosts
MySQL에 캐시된 모든 포스트를 초기화한다.
flust-logs
MySQL의 로그 파일을 새로 작성하며 초기화한다.
flust-status
MySQL의 상태정보를 초기화한다.
flust-tables
MySQL에 캐싱된테이블 정보를 초기화한다.
flust-thread
쓰레드 캐시에 저장된 쓰레드를 초기화한다.
flust-privileges
권한정보 테이블을 다시 읽는다.
kill id
특정 MySQL 프로세스를 죽인다.
Processlist
현재 MySQL 프로세스 목록은 본다.
Refresh
현재 캐시되어 있는 모든 테이블을 초기화하고 log 파일은 새로 만든다.
Variables
설정 가능한 모든 변수를 보여줍니다.
<화면 1> SHOW VARIABLES로 통해 본 설정
<화면 2> SHOW STATUS롤 통해 본 서버의 사용 통계
MySQL의 가장 큰 특징 중 하나는 여러 가지 스토리지 엔진을 가지고 있다는 것이다. 이 명령은 현재 MySQL의 시스템이 어떤 스토리지 엔진을 사용할 수 있는지 보여준다.
+—————-+———+———————————————————–+| Engine | Support | Comment |
+—————-+———+———————————————————–+
| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance |
| HEAP | YES | Alias for MEMORY |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables |
| MERGE | YES | Collection of identical MyISAM tables |
| MRG_MYISAM | YES | Alias for MERGE |
| ISAM | NO | Obsolete storage engine, now replaced by MyISAM |
| MRG_ISAM | NO | Obsolete storage engine, now replaced by MERGE |
| InnoDB | YES | Supports transactions, row-level locking, and foreign keys |
| INNOBASE | YES | Alias for INNODB |
| BDB | NO | Supports transactions and page-level locking |
| BERKELEYDB | NO | Alias for BDB |
| NDBCLUSTER | NO | Clustered, fault-tolerant, memory-based tables |
| NDB | NO | Alias for NDBCLUSTER |
| EXAMPLE | NO | Example storage engine |
| ARCHIVE | YES | Archive storage engine |
| CSV | NO | CSV storage engine |
| BLACKHOLE | NO | Storage engine designed to act as null storage |
+—————-+———+———————————————————–+
MySQL은 설정 가능한 값들을 엄청나게 많이 가지고 있으며 SHOW VARIABLE 명령을 통해 현재 설정되어 있는 모든 값을 볼 수 있다. <화면 1>은 SHOW VARIABLES로 통해 살펴본 설정이다.
SHOW VARIABLES로 볼 경우 총 207개 정도의 변수가 표시된다. 오히려 너무 많아서 원하는 값을 찾기가 힘들 정도이다. 그래서 SHOW VARIABLES 명령 뒤에 LIKE ‘%키워드%’를 사용하면 원하는 값만을 볼 수 있다.
MySQL은 내부적으로 동작 상황에 대한 실시간 통계 정보를 가지고 있다. SHOW STATUS는 이러한 통계 정보를 보기 위한 명령이다. 모니터링할 때 가장 기본이 되는 것이 바로 앞에서 설명한 SHOW VARIABLES의 정보와 SHOW STATUS의 정보이다. 웹 기반의 모니터링 툴을 비롯한 각종 모니터링 툴들이 바로 이 두 명령어를 통해 나온 정보를 조합해 사용하는 것이다. SHOW STATUS도 SHOW VARIABLES와 마찬가지로 LIKE ‘%키워드%’ 사용해 원하는 값만을 볼 수 있다.
현재 동작하고 있는 MySQL 데이터베이스 서버의 동작중인 모든 쓰레드와 유저 커넥션 정보를 보기 위한 명령어이다. 이를 통해 얻어진 정보로 시스템 자원을 지나치게 많이 사용하거나 잘못된 수행을 하고 있는 프로세스를 죽일 수 있다.
SHOW TABLE 명령은 현재 데이터베이스에 존재하는 테이블에 대한 기본적인 정보를 보여주며 SHOW TABLE STATUS는 각 테이블의 생성 일자, 테이블 크기, 인덱스 크기 등 구체적인 정보를 보여준다. 하지만 이 때 주의할 점이 하나 있는데 바로 SHOW TABLE STATUS의 경우 테이블의 스토리지 엔진이 MyISAM인 경우에만 정확한 정보를 표시하며 InnoDB의 경우에는 부정확한 정보를 보여준다는 것이다. InnoDB 스토리지 엔진으로 되어 있는 테이블은 SHOW INNODB STATUS로 구체적인 정보를 확인할 수 있으며 SHOW INDEX를 통해 테이블의 인덱스에 대한 각종 정보를 볼 수 있다.
<화면 3> Server Connetion에서 쓰레드별 정보를 보는 화면
<화면 4> MySQL Administrator를 통해 커넥션 관련 정보를 실시간 모니터링한다.
그동안 MySQL의 경우에는 GUI 기반의 관리 툴에 대한 지원이 매우 미약했던 것이 사실이다. 하지만 올해 초 4.1 버전 발표 이후 연속적으로 GUI 기반의 관리 툴을 발표되었으며 그 완성도 또한 이전의 여러 GUI 프로그램들에 비해 비약적인 향상을 가져왔다. 빠르고 정확한 정보의 확인을 위해 커맨드라인 관리 툴들이 유용하지만 사실 일반적인 모니터링에는 GUI 기반의 모니터링 툴의 사용이 훨씬 편하다. MySQL이 새롭게 내놓은 GUI 기반 툴 중 모니터링을 위해 이용할 수 있는 툴은 MySQL Administrator와 MySQL Query Browser이다.
MySQL의 GUI 기반 관리 툴인 MySQL Administrator는 기존의 GUI 관리 툴과는 달리 매우 다양한 관리 업무와 모니터링 작업을 편리하게 지원한다. 이 중 가장 돋보이는 기능은 모니터링 기능인데 이 툴로 인해 MySQL 튜닝 작업이 두 배는 편리해졌다고 말할 수 있을 정도이다. MySQL Administrator의 모니터링 관련 메뉴는 Server Connections, Health, Server Logs 등 이렇게 세 가지가 있다. <화면 3>과 같이 Server Connection은 커맨드라인 명령 중 SHOW PROCESSLIST와 같은 역할과 함께 각 유저 별 접속 현황을 알 수 있다.
MySQL Query Browser는 기존의 MySQL 관리자나 프로그래머들이 많이 이용하던 SQLGate와 비슷한 역할을 수행하는 프로그램이다. GUI 상에서 MySQL 쿼리들을 수행할 수 있으며 여러 탭을 이용해 빠른 작업을 할 수 있게 되었다. 또한 도움말과 명령어들에 대한 하일라이팅을 지원함으로써 편리하고 정확한 작업을 할 수 있다. 앞의 커맨드라인 명령어들을 여기에서 모두 실행해 볼 수 있다. 초기 버전에서는 한글을 입력하면 다운되는 등의 치명적인 버그가 있었으나 지금은 수정되어 우리나라의 사용자들도 자유롭게 사용할 여건이 되었다.
<화면 5> MySQL Auery Browser
+——————————-+—————+
| Variable_name | Value |
+——————————-+—————+
| Aborted_connects | 12 |
| Connections | 212 |
| Max_used_connections | 112176 |
| Threads_connected | 168 |
+——————————-+—————+
4 rows in set (0.00 sec)
mysql> SHOW STATUS LIKE ‘%CLIENT%’;
+——————————-+—————+
| Variable_name | Value |
+——————————-+—————+
| Aborted_clients | 2 |
+——————————-+—————+
1 row in set (0.00 sec)
MySQL의 커넥션은 쓰레드 단위로 일어나는데 각 쓰레드가 생성되면서 메시지 전송을 위한 버퍼를 생성하게 된다. 일반적으로 max_allowed_packet만을 정해 놓는 경우가 많은데 net_buffer_ length를 설정해 두면 그 용량을 넘는 메시지를 전달해야 할 경우 자동으로 이 값을 늘리게 된다. 그러므로 가장 효율을 높이기 위해서는 net_buffer_length를 일반적인 쿼리에서 전송되는 바이트 값의 평균 정도를 생각하여 충분히 낮은 값을 설정해두고 max_allowed_ packet은 최대로 전송될 수 있는 높은 값을 설정하는 것이 좋다. max_allowed_packet은 1GB까지 설정할 수 있다.
max_connections는 서버가 허용하는 최대한의 커넥션 수이다. MySQL 데이터베이스를 운영하고 있는 서버의 사양에 따라 달라질 수 있으며 일반적으로 120~250개 정도로 설정하는 것이 보통이다. 하지만 접속이 많고 고용량 서버의 경우 1000개 정도의 높은 값을 설정하는 것도 가능하다. Too many connection 에러가 발생하지 않도록 적절한 값을 설정하는 것이 중요하다. Back_log의 경우 max_connection 이상의 접속이 발생할 때 얼마만큼의 커넥션을 큐에 보관할지에 대한 설정 값이다. 기본 값은 50이며 접속이 많은 서버의 경우 이 값을 늘릴 필요가 있다.
외부로부터 접속 요청을 받을 경우 인증을 위해 IP를 호스트네임으로 바꾸는 과정이 수행된다. 말하자면 hostname lookup 과정이 수행되는데 접속이 많은 서버에서는 이 과정에서 상당히 많은 과부하가 발생한다. 그러므로 인증 부분을 호스트 기반이 아닌 IP 기반으로 변경하고 이 같은 옵션을 통해 hostname lookup 과정을 생략하면 눈에 띄는 성능 향상을 경험할 수 있을 것이다.
+——————————-+—————+
| Variable_name | Value |
+——————————-+—————+
| Delayed_insert_threads | 0 |
| Slow_launch_threads | 0 |
| Threads_cached | 0 |
| Threads_connected | 1 |
| Threads_created | 2 |
| Threads_running | 1 |
+——————————-+—————+
6 rows in set (0.00 sec)
MySQL 데이터베이스 시스템에서 메모리 관련 주요 설정들은 대부분 캐싱과 관련된 파라미터들이다. 버퍼 풀(buffer pool) 크기, 키 캐시(key cache) 크기, 쿼리 캐시 크기 등이 있는데, 이 중 앞의 두 개는 InnoDB와 MyISAM의 핵심 파라미터이기에 다음 호에 설명하게 되며 여기서 살펴볼 항목은 바로 쿼리 캐시에 관한 부분이다.
◆ 쿼리 캐시에 저장된 것과 다른 쿼리가 접수되었을 때
◆ 하나의 트랜잭션이 commit과 함께 마무리되었을 때
◆ 쿼리가 내부적으로 임시 테이블을 생성해야 할 때
+——————————-+—————+
| Variable_name | Value |
+——————————-+—————+
| have_query_cache | YES |
+——————————-+—————+
1 row in set (0.00 sec)
Mysql 날짜 함수
리눅스 네트워크 관련 명령어
– # ping -c 4 -i 2 192.168.1.32 ->192.168.1.32 호스트를 4개의 패킷, 2초 간격으로 패킷 전송
▪ netstat 명령어
– # netstat -nr : 커널 라우팅 테이블을 10진수의 수치정보로 출력
– # rpcinfo [ -n <포트번호> ] -u <호스트> <프로그램번호> [ <버전번호> ]
리눅스 방화벽 Iptables 설정
제 1세대는 BSD의 ipfw를 기본으로 했고 1994년 후반기에 알란 콕스(Alan Cox) 에 의해서 포트 됐다.
이것은 리눅스 2.0에서 Jos Vos와 다른이들에 의해서 개선됐고 커널의 필터링 규칙을 제어하는 사용자 툴로는 ‘ipfwadm’이 사용됐다.
1998년 중반에 리눅스 2.2를 위해 사용자 툴로 ‘ipchains’를 내놓았다. 마지막으로, 제 4세대 툴이 ‘iptables’이고 리눅스 2.4를 위해 1999년 중반에 커널을 재작성했다.
패킷 필터란 네트워크를 통하는 모든 것은 패킷의 형태를 가지며, 패킷의 앞부분에는 패킷이 어디서 왔는지 어디로 향하는지, 어떤 프로토콜을 이용하는지 등과 같은 정보를 가지고 있다. 패킷 필터는 이렇게 지나가는 패킷의 헤더를 보고 패킷을 ‘DROP'(마치 전혀 전달되지 않는 것처럼 패킷을 거부) 하거나 ’ACCEPT‘(패킷이 지나가도록 내버려 둠)하는 등의 작업을 하는 프로그램을 말한다. iptables은 이런 패킷 필터링 기능을 설정하는데 사용할 수 있는 프로그램이다. 자신의 시스템에 설치돼 있는 iptables의 버전을 확인하는 방법은 아래명령을 통해 가능하다.
1. 패킷이 커널에 도착하면 그 패킷의 목적지를 확인한다. 이것을 ‘라우팅’ 이라고 한다.
2. 패킷의 목적지가 이곳이면, 패킷은 전달돼 입력체인에 도달한다. 패킷이 입력체 인을 통과하면 패킷을 기다리고 있던 프로세서가 받게 된다.
3. 그렇지 않고 커널이 포워딩 불능이나, 패킷을 어떻게 포워딩해야 하는가를 알지 못하면, 그 패킷은 ‘DROP‘ 된다. 포워딩이 가능하게 돼있고 다른 곳이 목적지이면 패킷은 그림의 오른쪽 방향으로 전달돼 포워딩 체인으로 간다. 이 체인이 ’ ACCEPT‘ 하게 되면 이것은 포워딩 할 네트워크로 보내진다.
4. 마지막으로, 로컬에서 수행하던 프로그램은 네트워크 패킷을 전송할 수 있다. 이 패킷은 즉시 출력 체인에 보내지며 이 체인이 ‘ACCEPT’되면 이 패킷은 그 목적지가 어디든지 보내진다.
iptables -[ADC] chain rule-specification [options]
iptables -[RI] chain rulenum rule-specification [options]
iptables -D chain rulenum [options]
iptables -[LFZ] [chain] [options]
iptables -[NX] chain
iptables -P chain target [options]
iptables -h (print help information)
-A : 새로운 규칙을 추가한다.(–append)
-D : 규칙을 삭제한다.(–delete)
-C : 패킷을 테스트한다.(–check)
-R : 새로운 규칙으로 교체한다.(–replace)
-I : 새로운 규칙을 삽입한다.(–insert)
-L : chain에 설정된 규칙을 출력한다.(–list)
-F : chain으로부터 규칙을 모두 방출(삭제)한다.(–flush)
-Z : 모든 chain의 패킷과 바이트 카운터 값을 0으로 만든다.(–zero)
-N : 새로운 chain을 만든다.(–new)
-X : chain을 삭제한다.(–delete-chain)
-P : 기본정책을 변경한다.(–policy)
INPUT : 입력에 대한 사용
OUTPUT : 출력에 대한 사용
FORWARD : 전달(forwarding)에 대한 사용
-s : 패킷의 발신지를 명시한다.(–source)
-p : 패킷의 프로토콜을 명시한다.(–protocol)
-d : 패킷의 도착지를 명시한다.(–destination)
-i : 규칙을 적용할 인터페이스 이름을 명시한다.(–interface)
-j : 규칙에 맛는 패킷을 어떻게 처리할 것인가를 명시한다.(-jump)
-y : 접속 요청 패킷인 SYN패킷을 허용하지 않는다.(–syn)
-f : 두 번째 이후의 조각에 대해서 규칙을 명시한다.(–fragment)
127.0.0.1 IP 주소로부터 오는 모든 ICMP 패킷을 무시하는 경우 사용되는 프로토콜은 ICMP이고 발신 주소는 127.0.0.1 이어야 한다. 그리고 패킷 필터의 목표는 드롭(DROP)이다. 테스트하는 프로그램은 ping이며 ping은 단순히 ICMP type 8로 반응요구를 보내며 이에 협조하는 대상 호스트는 ICMP 타입 0(echo reply)를 보내어 응답하도록 돼 있다. 이제 iptables의 패킷필터를 통해 로컬호스트가 ping 명령에 반응하지 않도록 하겠다.
PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms
— 127.0.0.1 ping statistics —
; `INPUT’ 체인에 127.0.0.1로부터 오고(`-s 127.0.0.1′) ICMP(`-p ICMP’) 패킷에 대해 DROP로 점프하라는 (`-j DROP’) 규칙을 추가(-A).
PING 127.0.0.1 (127.0.0.1): 56 data bytes
— 127.0.0.1 ping statistics —
지금 현재 입력돼 있는 chain이 하나밖에 없으므로 숫자를 지정하는 명령으로 삭제가 가능하며, 앞의 명령과 똑같이 하되 -A를 -D로 바꾸어 지우는 방법이 있다.
#iptables -D INPUT -s 127.0.0.1 -p icmp -j DROP
설정돼 있는 체인의 규칙을 모두 볼 수 있다. 명령으로 -L을 사용해 가능하며 -v 옵션과 같이 사용해 각 체인에 대한 패킷과 바이트 카운터 등의 자세한 정보를 함께 볼 수 있다.
# iptables -L -v
하나의 체인 안의 모든 규칙을 비우는 것은 ‘-F’ 명령을 사용해 간단하게 할 수 있다. 체인을 지정하지 않으면 모든 체인의 규칙을 지울 수 있다.
출처(‘-s’, ‘–source’, ‘–src’)와 목적지(‘-d’, ‘–destination’, ‘–dst’) IP 주소를 지정하는데 4가지 방법이 있다. 가장 보편적인 방법
은 ‘www.linuzine.com’, ‘localhost’처럼 도메인 네임을 이용하는 것이다. 두번째 방법은 ‘127.0.0.1’과 같은 IP 주소를 이용하는 것이다.
많은 지시자들(‘-s’나 ‘-d’ 같은)은 일치하지 않는 주소를 나타내기 위해 ‘!'(‘not’을 의미한다)로 시작하는 설정을 할 수 있다. 예로, ‘-s !localhost’ 는 localhost로부터 오는 패킷이 아닌 경우를 나타낸다.
프로토콜은 ‘-p’ 지시자로 지정할 수 있다. 프로토콜을 숫자가 될 수 있고(IP의 프로토콜 번호를 알고 있다면) ‘TCP’, ‘UDP’, ‘ICMP’ 같은 이름이 될 수도 있다. 그리고 ‘tcp’는 ‘TCP’와 같은 역할을 한다. 프로토콜 이름 지정에도 ‘!’을 이용 할 수 있다. ‘-p ! TCP’
TCP 확장은 ‘–protocol tcp’ 가 지정되고 다른 적용이 지정되지 않으면 자동으로 적재된다. 이것은 다음과 같은 옵션을 제공한다.
뒤에 두개의 단어를 사용한다. 첫번째 것은 검사하고자 하는 지시자 리스트의 마스크이다. 두번째 단어는 지시자에게 어떤 것이 설정 될 것인지를 말해준다.
이것은 모든것이 검사돼야 함을 말한다. 그러나 SYN과 ACK만 설정된다.
‘!’ 옵션이 선행될 수 있다. 이것은 ‘–tcp-flags SYN,RST,ACK,SYN’의 약어이 다.
‘!’ 옵션이 선행될 수 있다. 이후에 하나의 TCP 포트나 포트의 범위를 지정한다.
/etc/services 에 기록된 것과 같은 포트 이름이 사용될 수 도 있고 숫자로 나타낼 수도 있다. 범위는 두 개의 포트 이름을 ‘-‘으로 연결해서 사용하거나 하나의 포트 뒤에 ‘-‘를 사용하거나 하나의 포트 앞에 ‘-‘ 를 덧붙일 수 있다.
위의 내용과 같으나 목적지를 지정한다.
‘!’ 나 숫자가 옵션에 선행될 수 있는데 숫자가 앞에 올 경우 그 숫자 와 TCP 옵션이 같은 경우의 패킷을 검사한다. TCP 옵션을 검사하려 할 때 완전한 TCP 헤더를 갖지 않는 것은 자동으로 드롭 된다.
iptables는 테이블 형식으로 관리를 한다. 그리고 먼저 등록된 것이 효력을 발생하기 때문에 등록을 하는 순서가 중요하다. 모든 것을 거부하는 설정이 먼저 오게 되면 그 이후에 포트를 열어주는 설정이 와도 효과가 없다. 그러므로 허용하는 정책이 먼저 오고 나서 거부하는 정책이 와야 한다.
iptables -A INPUT -p tcp –dport 22:30 -j DROP
등록된 라인은 ssh를 사용하는 것을 허용하는 것이다. 출처(source)와 목적지(destination)는 명시하지 않았기 때문에 전체포트와 IP가 대상이 된다. -dport 는 패킷이 대상으로 삼는 포트를 명시한 것이다 여기에서 22라고 표기한 것은 ssh서비스 포트이다. 그리고 마지막에 -j ACCEPT는 허용하도록 정책을 정하는 것이다. 따라서 여기로의 ssh서비스를 요청하는 패킷은 허용되도록 설정을 한 것이다.
#!/bin/sh
# iptables 모듈 등록하기
modprobe iptable_filter
/usr/local/bin/iptables -A INPUT -p tcp –dport 22 -j ACCEPT
/usr/local/bin/iptables -A INPUT -p tcp –dport 80 -j ACCEPT
/usr/local/bin/iptables -A INPUT -p tcp –dport 109 -j ACCEPT
/usr/local/bin/iptables -A INPUT -p tcp –dport 110 -j ACCEPT
/usr/local/bin/iptables -A INPUT -p tcp –dport 143 -j ACCEPT
/usr/local/bin/iptables -A INPUT -p tcp –dport 3306 -j ACCEPT
/usr/local/bin/iptables -A INPUT -p tcp –dport 21 -j ACCEPT
/usr/local/bin/iptables -A INPUT -p tcp –dport 20 -j ACCEPT
/usr/local/bin/iptables -A INPUT -p tcp –dport 6667 -j ACCEPT
/usr/local/bin/iptables -A INPUT -p udp –dport 6667 -j ACCEPT
/usr/local/bin/iptables -A INPUT -p tcp –dport 1:30000 -j DROP
만약에 서버에서 나갈 이유가 없으면 전부 막으면 된다. 1:65535로 설정하면 전체 포트가 막힌다. iptables 설정은 조금만 공부를 하면 쉽게 습득이 가능하다. 그러므로 문서를 보는 것이 중요하다. 이 설정은 기본이므로 좀더 많은 것은 관련 문서를 이용하기를 바란다.
/sbin/iptables -F
echo “1” > /proc/sys/net/ipv4/ip_forward
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_nat_ftp
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
1) 1st IPCHAIN의 설정 방법
/sbin/ipchains -F
/sbin/ipchains -P forward REJECT
/sbin/ipchains -A forward -s 192.168.0.0/24 -j MASQ
/sbin/ipchains -F
/sbin/ipchains -P forward DENY
echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/ipchains -A forward -j MASQ -s 192.168.0.0/24 -d 0/0
iptables -A INPUT -p tcp -m string –string “Buy Now” -j REJECT –reject-with tcp-reset
만약 로그를 남기고 거부하고 싶다면.
iptables -A INPUT -p tcp -m string –string “Buy Now” -j LOG
iptables -A INPUT -p tcp -m string –string “Buy Now” -j REJECT –reject-with tcp-reset
: Rule Matching
-> source IP address(-s)
Destiation IP address(-d)
Incoming interface(-i) 예) eth0, eth1, eth2 등등 = -s 10.1.1.0/24 와 같은뜻인데… 좀 더 간단하게 쓰고 싶으면..-i 옵션을 사용한다.
Outgoing interface(-o) : 어디를 통해서 나가겠느냐…
Layer 4 protocol(-p) : -p [tcp/udp]
negation -block all traffic not sourced from 192.168.1.20
=> /sbin/iptables -A INPUT -s! 192.168.1.20 -j DROP : 여기서 !는 not의 의미이다.(부정)
-> 192.168.1.20을 제외한 모든것을 DROP시키겠다라는 뜻이다.
이렇게 외부망으로 분리해놓은 것들을 DMZ라고 한다.
: -p tcp, –protocol tcp
–sport, –source-port -> 1024 ~ 65535 사이의 값 이용
–dport 23/telnet(/etc/services), –destination-port : 숫자 대신에 문자를 쓰고 싶을때 해당위치에 있는곳의 절대경로를 적어줘야 한다.
–tcp-flags SYN, FIN, ACK SYN, ACK : 이것보다는 상태추적을 많이 사용하게 된다.
: UDP Application
-> TFTP -UDP:69
Syslog -UDP:514
NTP(Network Time Protocol) -UDP:123
DHCP -UDP:67 UDP:68
-p udp, –protocol udp
–sport, –source-port, -same source port as destination port : source port가 destination port가 똑같다. => UDP일경우에…
–dport 123/ntp(/etc/services), –destination-port : destination port를 쓸때는 숫자를 많이 이용하게 된다.
: ICMP Types (echo-request -PING, echo-reply -pong)
–icmp-type name/number
Deny ICMP echo-replies from all hosts
-> /sbin/iptables -A INPUT -p icmp-type echo-reply -j DROP
=> work 컴이 serv 컴한테 echo-request를 보내게 되면 serv 컴은 work 컴한테 echo-reply를 보내게 된다.
만약 예전에 설정했던 정책을 저장하고 싶으면 iptables-save > default.rules
iptables -F
iptables -nL
iptables -P INPUT ACCEPT
iptables -nL
serv 컴퓨터에서 외부의 ping에 응답하지 않도록 하며, 또한 자신도 외부로 ping 요청을 하지 못하도록 설정하세요!~!!~~
iptables -nL
iptables -A INPUT -p icmp –icmp-type echo-request -j DROP
iptables -nL
ping -c 3 serv -> ping이 안나가게 된다.
: 일반적 정책(rule) 설정
-> iptables -A INPUT -p tcp –dport 21 -j ACCEPT
iptables -A INPUT -p tcp –dport 22 -j ACCEPT
iptables -A INPUT -p tcp –dport 23 -j ACCEPT
Multiple port 를 이용
-> -m multiport –dport port_num1, port_num2, port_num3…
iptables -I INPUT 1 -p tcp -m multiport –dport 21, 22, 23 -j ACCEPT
: IP 주소는 쉽게 위조가능
MAC의 위조는 어렵다…
-m mac, –mac-source 00:00:00:00:00:00(mac address) 처음 24비트는 제조사 일련번호 다음 24비트는 제품 일련번호이다.
iptables -nL
iptables -P INPUT ACCEPT
clear && iptables -nL
iptables -A INPUT -s 192.168.234.20 -j DROP
clear && iptables -nL
work 컴에서…
ping -c 2 serv -> 접속이 안됨.
ftp serv -> 접속이 안됨.
telnet serv -> 접속이 안됨.
vi /etc/sysconfig/network-scripts/ifcfg-eth0 -> ipaddress를 30으로 수정…
service network restart
ftp serv -> 접속이 잘 됨.
telnet serv -> 접속이 잘 됨.
그렇기 때문에 MAC address를 알아서 그것을 막아버려야 한다. 이것을 알기 위해서는 log를 봐야한다.
=> 이렇게 mac address를 filtering하게 되면 유용하게 사용할수가 있다.
: ACCEPT : 접근을 허용하겠다.
DROP : 메시지를 전혀 보내주지 않는다.
REJECT : 메시지를 보내주긴 하는데 전혀 다른 응답을 하게된다.
REDIRECT : 이것은 proxy 서버에서 사용하게 될것이다. 내가 갈려고 하는 곳의 경로가 바뀌게 되는것을 REDIRECT라고 한다.
NAT table 의 PREROUTING chain을 적용하게 된다. 오직 local ports에서만 적용이 된다.
proxy server를 사용하게 되면 filtering이 가능하게 된다.
normal proxy를 사용하게 되면 귀찮기 때문에 투명 proxy를 사용하는것이 편리하다. -> REDIRECT를 사용…
LOG : SysLog를 사용해서 log를 저장할수가 있다.
아무것도 설정을 안해주면 기본적으로 /var/log/message에 저장이 된다.
서비스명 : 레벨 : 저장되는 위치 -> *.info;mail.none;authpriv.none;cron.none /var/log/messages
우선 기존의 것을 복사한뒤…
#kern.* /dev/console 을 복사해서… kern.* /var/log/firewall.log을 더 추가해준다. ### modified by jun 2006-06-21 ###
echo $?
ls -l /var/log/firewall.log
cat /var/log/firewall.log
clear && iptables -nL
iptables -D INPUT 1
clear && iptables -nL
iptables -P INPUT DROP
clear && iptables -nL
iptables -A INPUT -p tcp –dport 23 -j LOG -> 23번의 port로 들어오는것의 log 기록을 남기겠다.
clear && iptables -nL
iptables -A INPUT -s 192.168.234.20 -p tcp –dport 23 -j ACCEPT
clear && iptables -nL
tail -5 /var/log/firewall.log
watch tail -5 /var/log/firewall.log
21, 22, 23, 80번의 port 이외의 서비스들은 모두다 log에 기록이 남게 끔 하시오~!!!!
21, 22, 23 서비스 이외의 접속기록을 log로 남기세요… 힌트 : multiport, ! , log Target
: /etc/syslog.conf를 이용한 log위치 재지정
-> 기본값으로 /var/log/message에 저장
kern.* /var/log/firewall 로 수정
service syslog restart
-> Log 기록에 코멘트 첨부
–log-prefix “unknown port attemped…”
iptables -R INPUT 1 -m multiport -p tcp ! –dport 21,22,23 -j LOG –log-prefix “unknown port attemped…”
: Portsentry는 host기반 침입탐지 시스템으로 열려있는 모든 포트를 모니터링 할 수 있는 특징을 가지고 있으면 TCP/UDP 포트스캔을
탐지할 수 있고 포트스캔 공격을 받았을 경우 방화벽과 연동하여 보안 정책을 새롭게 재구성 할 수 있다.
1) 호스트로 들어오는 모든 패킷을 ROUTE명령으로 DROP 시킬수 있음
2) Xinetd 기반의 서비스에 접근하지 못하도록 /etc/
: http://rpm.pbone.net/ -> portsentry 검색 -> fedora 4 download -> 밑으로… Portsentry-1.2.1.te.i386.rpm -> download
=> serv 컴에서…
rpm -Uvh Portsentry-1.2-1.te.i386.rpm
rpm -ql Portsentry -> /etc/Portsentry/Portsentry.conf를 확인…
cd /etc/Portsentry/
pwd
ls -l
vi Portsentry.conf -> : set nu
-> 96번째 행에서… RESOLVE_HOST = “1”을 RESOLVE_HOST = “0”으로 수정… : 이름풀이가 가능하게 할것인지 말것인지를 결정…
132번째 행과 133번째 행이 중요하다. => BLOCK_UDP=”1″ , BLOCK_TCP=”1″ -> 그냥 그대로…
206번째 행에서 보면 #KILL_ROUTE=”/sbin/iptables -I input -s $TARGET$ -j DROP
282번째 행에서…SCAN_TRIGGER=”2″을 SCAN_TRIGGER=”0″으로 수정… : 2초후에 반응하라…을 즉각처리로…
1) portsentry -portsentry 실행파일
2) Portsentry.conf – 환경설정 파일
3) Portsentry.history – 현재까지 거부된 모든 host 정보 저장
4) Portsentry.ignore – 감시예외 파일
감시하고 있는 특정 포트에 접근해도 무시하길 바라는 host ip주소를 추가
iptables -A INPUT -p tcp –dport 22 -j ACCEPT -> 외부에서 ssh 접속만 허용이 되게한다.
clear && iptables -nL
which portsentry -> /usr/sbin/portsentry
portsentry -stcp
echo $?
ps -ef | grep -i port -> 자동적으로 UDP까지 같이 실행되고 있는것을 볼수가 있다.
ssh serv -> 잘되는것을 볼수가 있다.
exit
nmap -v -sS -O(운영체제 확인) serv
nmap -v -sS -O(운영체제 확인) 192.168.234.10
—> 이것이 작동이 안할것이다. 왜냐하면 x window 때문이다.
그렇기때문에 text모드로 시작을 해야한다.
ps -ef | grep -i port
kill 9 1358
kill 9 2698 등등
shutdown -r now(재시작) – text모드로…
portsentry -stcp
ps -ef | grep -i port
service iptables start
iptables -nL
nmap -v sS -O 192.168.234.10
cat portsentry.blocked.stcp가 들어와 있어야 한다.
: Portsentry는 스캔 공격자가 스캔을 하기 위해 사용하는
MySQL Replication 설정과 몇 가지 테스트
MySQL Replication 설정 및 테스트
master shell > tar -cvf /tmp/mysql-snapshot.tar .
slave shell > tar -xvf /tmp/mysql-snapshot.tar
master mysql > UNLOCK TABLES;
log-bin=mysql-bin
server-id = 1
server-id = 2
master-host = 192.168.0.1
master-user = rep (위에서 설정한 replication을 위한 계정 정보)
master-password = reppassword하이브레인넷 부설연구소
리눅스 NFS 설정하기
1. NFS Server 구성요소.
1) 설정파일 및 필요한 파일
– /etc/rmtab : 현재 원격으로 mount되어 있는 file/directory 및 client목록 -/etc/dfs/fstypes : mount할 파일시스템의 type을 명시해 놓은 파일(default: nfs) -/etc/nfs/nfslog.conf : NFS log daemon 설정 파일 구성daemon 및 파일 -/usr/lib/nfs/nfsd : 실제 NFS 서버 데몬. Client의 mount요청을 주시하다가 요청이 발생하면 /etc/dfs/dfstab의 내용에 따라 파일시스템을 공유하도록 mount시켜줌.
– /usr/lib/nfs/mountd : NFS client의 공유(mount)요청에 대해 공유자원의 file handle을 넘겨주는 역할을 하는 데몬.( client에게 공유목록의 i-node 등을 전달.) -/etc/default/nfslogd : NFS log 데몬.
* /usr/lib/nfs/statd : /etc/init.d/nfs.client script에 의해 구동되며 * /usr/lib/nfs/lockd : 서버와 클라이언트 양쪽모두 구동됨2. NFS Client 구성요소
1) 설정파일 및 필요한 파일
3. NFS 사용 설명
1) Server side /etc/dfs/dfstab 파일에 NFS 공유자원을 설정한다.
# share [-F fstype] [ -o options] [-d] [pathname] [resource]
# .e.g,
# share -F nfs -o rw=engineering -d “home dirs”‘ /export/home2
share -F nfs /work3/gundal
share -F nfs /work2
share -F nfs /work1
/work3/gundal, /work2, /work1 디렉토리를 원격에서 mount하도록 허용.
option을 지정할 수 있다. ( -o )
root=client : client로 지정된 시스템의 root user는 이 디렉토리에 대해 superuser권한을 갖는다.
rw=acces_list : read/write 옵션으로 access_list에 명시된 client들이 mount가능.
ro=access_list : read only 옵션으로 access_list에 명시된 client들이 mount가능.
access_list 구성 : client들을 구분자 ‘:’를 이용하여 명시한다.
Ex) share -F nfs -o rw=client1:client2:clinet3:… directory
IP주소로 client를 명시할 경우 ‘@’를 앞에 붙인다.
Ex) share -F nfs -o ro=@211.176.132.18:@211.176.132.20:…. directory
도메인으로 명시할 경우 앞에 ‘.’을 붙인다.
Ex) share -F nfs -o ro=.gfs.com:.boxcorea.com:…. Directory
/usr/sbin/share command로 확인해 본다.
# /usr/sbin/share -F nfs [ ?o option_list ] directory
에러 메시지가 없으면 설정에 문제가 없다.
공유가 되어 있는지 확인.
# /usr/sbin/share
– 공유되어 있는 항목을 보여준다.
공유를 제거한 후 /etc/init.d/nfs.server start 실행
# /usr/sbin/unshare directory
# /etc/init.d/nfs.server start
공유 및 서버데몬 확인
# ps ?e | grep nfs
/usr/lib/nfs/statd
/usr/lib/nfs/lockd
/usr/lib/nfs/mountd
/usr/lib/nfs/nfsd ?a 16
위 4개의 daemon이 실행 중이면 서버측 설정 및 작동은 정상임.2) Client side
# /usr/lib/nfs/dfshare [host-name]
-공유되어있는 directory 또는 자원들을 list한다.
(2)/usr/sbin/mount 명령으로 mount 해본다.
# /usr/sbin/mount ?F nfs [ -o option_list ] [host-name:/공유directory ]
– mount 되거나 mount를 기다리고 있으면 일단 정상적인 nfs공유 가능.
(3)booting시 자동으로 NFS mount하도록 하기 위해 /etc/vfstab을 수정 # vi /etc/vfstab
host-name:/directory – mount-point nfs – yes [bg,soft][fg,hard]
※ option 중 [bg|fg],[soft|hard],[intr|nointr]
booting시 첫번째 mount 실패시…
bg :background로 mount 계속 시도
fg : foreground로 mount 계속 시도.(default)
Soft : 에러 메시지를 출력하고 booting process 진행
Hard : timeo(timeout) 에 명시한 시간이 경과할 때까지 계속시도.(default)
intr : keyboard로 mount process를 중단 가능.(default)
nointr : keyboard로 mount process 중단 불가.
timeo=n : 1?10초 단위로 timeout 값을 지정.(default UDP:11, TCP:600)
retry=n : 재시도 횟수지정 (default:10,000)
(4) 수동으로 mount시 # /usr/sbin/mountall -r
-r : vfstab의 설정 중 remote resour만 mount
좋아요
공유하기
친구들이 무엇을 좋아하는지 알아보려면 가입하기