'분류 전체보기'에 해당되는 글 100건
- [Mac] MacPorts coreutils 설치 후 VirtualBox가 설치 안되는 문제 2013.11.11
- [Mac] Mac 설치 후 할일 2013.11.11
- [Java] SynchronizedCollections vs ConcurrentCollections 2013.08.17
- [Java] 병렬 프로그래밍에서 잊지말아야 할 조언들 2013.08.17
- [GWT] eclipse에 GWT project import 하기 2013.08.17
- How to install gnuplot in Mac OS X lion 2013.08.09
- VirtualBox clipboard sharing not working sometimes(클립보드 공유가 가끔씩 안될 때) 2013.05.24
- DHT(Distributed Hash Table 분산 해시 테이블) 2013.04.10
- [번역] Virtual Nodes Strategies 2013.04.10
- [번역] Redis Sentinel Documentation 2013.04.09
[Mac] MacPorts coreutils 설치 후 VirtualBox가 설치 안되는 문제[Mac] MacPorts coreutils 설치 후 VirtualBox가 설치 안되는 문제
Posted at 2013. 11. 11. 01:07 | Posted in OS/Mac좀 더 편한 터미널 환경을 만들기 위해 MacPorts로 coreutils 설치 후 ln을 다음과 같이 변경시켰다.
(coreutils는 /opt/local/bin 에 설치되며 명령어에 'g' prefix가 붙는다.)
그후 ,VirtualBox 새버전을 내려 받아 설치했다.
그런데, 설치가 되지 않고 이런 에러만 내뱉는다. 지웠다 재설치도 해보고, 리부팅도 해보고 그래도 안된다.
(스크린샷을 안떠놔서 웹에서 영문버전 스크린샷을..)
웹 서핑을 해도 별다른 해결책이 안보인다.
혹시나 시스템 로그를 뒤져보면 뭔가 답이 나올것 같아 몇개의 파일을 살펴보던 중
/var/log/install.log 에서 VirtualBox 관련 메시지를 찾았다.
Nov 10 14:51:23 deepblues-MacBook-Air.local installd[342]: ./postflight: ln: invalid option -- 'h' Nov 10 14:51:23 deepblues-MacBook-Air.local installd[342]: ./postflight: Try 'ln --help' for more information. |
아.. 이게 뭔가.. >.<
coreutils 설치 후 ln을 /opt/local/bin/ln으로 바꿔놓은게 원인이었다. ㅜㅜ
coreutils 설치 명령은 다음과 같다.
$ sudo port install coreutils +with_default_names |
여기서 +with_default_names 옵션은 mac의 명령들을 대체하도록 하는 옵션인데, 검색해보니 수많은 문제를 일으켜 옵션이 안먹도록 제거되었다고 한다.
여러 프로그램들이 mac용 명령어의 옵션을 사용하므로, 옵션이 다른 coreutils들을 호출했다가는 에러가 나기 때문일 것으로 추측된다.
(해결)
따라서, 다음과 같이 설정을 바꾸고, 원래 mac 명령어들을 원복시켜줬다.
/bin/ln, /bin/ls는 원복해서 VirtualBox install에는 문제없게 하고, 터미널 환경은 개선하기 위해
PATH에 /opt/local/bin이 젤 앞에 오도록 하고, 자주 사용하는 ln과 ls만 rename했다.
그리고, VirtualBox 재설치..
짜잔~ 성공!
[Mac] Mac 설치 후 할일[Mac] Mac 설치 후 할일
Posted at 2013. 11. 11. 00:58 | Posted in OS/Mac맥북프로에서 맥북에어로 갈아타면서, 다음엔 시행착오 없이 잘 셋팅할 수 있게 한번 정리해본다.
다음 순서로 설치하니 우왕좌왕 않고 잘 되었다.
text wrangler - 한영키 변환시 필요 키보드 설정 - 한영키(shift+space), Home/End, Control, Command키 변경 등 마우스 설정 - 마우스 스크롤 반전 iterm2 - 마찬가지
dropbox - bash설정 등을 여기에 백업해놓음 xcode - brew를 사용하기 위해 설치 해야 함. 각종 xcode의 tool들도 설치해준다. brew (bash, coreutils, gnutils, subversion) .bashrc - dropbox에 백업해둔 파일을 복사하면 OK chrome - 좀 더 쾌적한 구글링을 위해 크롬을 먼저 설치해도 좋다. evernote source tree eclipse/intellij istat PhotoScape X ... |
(1) 키보드 / 마우스 설정
<한영 변환 shift+space키로 변경>
http://macnews.tistory.com/297
http://macnews.tistory.com/178
딜레이 없이 빠르게 OS X에서 한글-영어 입력기 전환하기.pdf
<USB 키보드 사용시 home/end 키 등 다시 설정해주기>
~/Library/KeyBindings/DefaultKeyBinding.Dict 에 위치시켜준다.
상세는 파일 내용 참조.
Karabiner-Elements 필요 없음!
<USB 키보드 Control, Option, Command 키 변경>
시스템 환경설정 > 키보드 > 키보드 > 보조키... > 키보드 선택 후 원하는 키로 변경
<휠 마우스 스크롤 방향 변경>
맥에서 일반 usb 마우스 휠 스크롤을 해보면 뭔가 좀 이상함을 느끼는데, 트랙패드 방향으로 맞춰져 있어서 Windows PC와 반대 방향으로 움직인다.
ScrollReverser를 설치하고 '수직 반전', '마우스 반전'만 켜준다. 트랙패드는 원래대로 두는 것이 자연스럽다.
- https://pilotmoon.com/scrollreverser/
(2) Xcode 설치
- 개발환경을 만들기 위해서는 기본으로 설치해야 한다.
- 아래의 MacPorts를 설치하기 위해서도 필요하다.
- Xcode가 설치되면, Preference > Downloads 탭에서 "Command Line Tools"를 설치한다.
(3) MapPorts 설치 --> 아예 설치하지 말고 homebrew를 사용하자.
- 좀 더 나은 작업환경을 위해서 2% 부족한 터미널 명령들을 업그레이드 하기 위해서 필수이다.
- MacPorts는 기타 무료 / 오픈 소스 소프트웨어 의 도입을 단순화하기위한 자유 / 오픈 소스 소프트웨어 프로젝트이다. (위키피디아)
- http://www.macports.org/install.php 에서 자신의 Mac OS버전에 맞는 링크를 눌러 다운로드 받아 설치한다.
(4) 좀 더 나은 터미널 환경 (macport는 사용말자. homebrew (4)-1 참고)
- 맥의 기본 명령어들, 대표적으로 'ls'는 기능이 미약하고, 좀 후지다. brew를 이용하여 개선해보자.
- Xcode의 'Command Line Tools'가 설치되어 있지 않다면 설치해야 한다. make가 필요하기 때문.
- homebrew 설치 (이제 모든 설치물들은 /usr/local 아래에 설치된다.)
http://brew.sh/
- bash, coreutils, binutils, gnu-utils, subversion 등을 설치
https://www.topbug.net/blog/2013/04/14/install-and-use-gnu-command-line-tools-in-mac-os-x/
(5) 디스크 파티션 분할하기
(※ 기기 변경을 몇 번 거치면서 느낀건.. 안하는게 낫더라. (1) Xcode 업데이트나 Mac OS 업데이트 시 master 파티션 공간 부족으로 이리저리 앱을 옮기거나 정리한 적이 잦았다 (2) 데이터만 남기고 mac을 재설치하거나 하는 경우는 없었다. 해서.. 굳이 이걸 할필요는 없는 듯..)
- 이 작업은 제일 먼저해도 되고, 좀 더 수월한 작업환경을 갖춰놓고 해도 좋다.
- 250GB 디스크를 70GB primary, 180GB data 파티션으로 분할했다. 혹시나 OS재설치를 대비해 home 디렉토리와 모든 데이터는 data 파티션으로 가도록 설정할 것이다. (DataHD가 data 파티션이다. 백업해뒀던 파일을 몽땅 복사했더니 용량이 얼마 안남았네 ;;;)
(6) home 디렉토리 변경 (파티션 분할 한 경우)
방법은 대강 3가지 정도가 있다.
(방법1) /Users 디렉토리를 data 파티션의 적절한 디렉토리로 마운트 하는 방법. /etc/fstab 등을 건드려야하고 할게 많다.
(방법2) 사용자 설정 > 고급 설정 에서 사용자 home 디렉토리를 data 파티션의 디렉토리로 지정하는 방법.
(방법3) /Users 디렉토리의 사용자 계정을 data 파티션의 디렉토리로 symbolic link를 걸어주는 방법.
다음은 (방법3)에 대한 절차이다. (방법1,2는 구글링으로 찾으면 많은 문서가 있다.)
- 분리한 data 파티션으로 홈 디렉토리를 옮겨준다.
- 계정 이름을 "deepblue"라고 했을 경우, 다음과 같이 symbolic link를 설정한다.
- 기존 home은 deepblue.ori로 변경하고, /Volumes/DataHD/home/deepblue 를 home으로 link를 걸어준다.
- 당연한 얘기지만, /Volumes/DataHD/home/deepblue 는 미리 생성되어 있어야 한다. 홈 디렉토리의 모든 내용을 복사해주자. 숨긴 파일까지 포함해서 옮기는건 당연~
- $ cd /Users
- $ sudo mv deepblue deepblue.ori
- $ sudo ln -s /Volumes/DataHD/home/deepblue deepblue
- symbolic link를 걸어준 후 컴퓨터를 재시작한다. (로그아웃했다가 다시 로그인해도 된다.)
- 설정들을 확인해보고 크게 문제 없으면, deepblue.ori는 삭제한다.
- ※ 맥북프로에서 맥북에어로 갈아타면서 기존 사용하던 홈을 그대로 link시켰더니, 대부분의 설정이 그대로 적용되었다. 하지만, 일부 설정은 다시 맞춰줘야 했다. 별 설정없이 기존 환경 그대로 사용할 수 있어서 편하네. ㅎㅎ
(7) 기타 프로그램들
- istat menus
- Dropbox
- Evernote
- Chrome
- PhotoScape X: 이미지 뷰어.
- VirtualBox
- VisualVm
- Wunderlist
- ...
[Java] SynchronizedCollections vs ConcurrentCollections[Java] SynchronizedCollections vs ConcurrentCollections
Posted at 2013. 8. 17. 19:04 | Posted in 개발이야기SynchronizedCollections(동기화된 컬렉션)과 ConcurrentCollections(병렬 컬렉션)
동기화된 컬렉션 클래스는 컬렉션의 내부 변수에 접근하는 통로를 일련화해서 스레드 안전성을 확보했다. 하지만 이렇게 만들다 보니 여러 스레드가 한꺼번에 동기화된 컬렉션을 사용하려고 하면 동시 사용성은 상당 부분 손해를 볼 수 밖에 없다. 하지만 병렬 컬렉션은 여러 스레드에서 동시에 사용할 수 있도록 설계되었다.
ConcurrentMap에는 put-if-absent, replace, condition-remove 등을 정의하고 있다.
기존에 사용하던 동기화 컬렉션 클래스를 병렬 컬렉션으로 교체하는 것만으로도 별다른 위험 요소 없이 전체적인 성능을 상당히 끌어 올릴 수 있다.
<에이콘 - 자바 병렬 프로그래밍(p.137) 발췌>
동기화되지 않은(unsynchronized) 컬렉션
- List: ArrayList, LinkedList
- Map: HashMap
- Set: HashSet
- SortedMap: TreeMap
- SortedSet: TreeSet
- Since JDK 1.2
- 문제점: Thread Safe하지 않다.
동기화된(synchronized) 컬렉션
- Vector, Hashtable, Collections.synchronizedXXX()로 생성된 컬렉션들
- Since JDK 1.2
- 문제점: Thread Safe하나, 두개 이상의 연산을 묶어서 처리해야 할 때 외부에서 동기화 처리를 해줘야 한다. (Iteration, put-if-absent, replace, condition-remove 등)
병렬(concurrent) 컬렉션
- List: CopyOnWriteArrayList
- Map: ConcurrentMap, ConcurrentHashMap
- Set: CopyOnWriteArraySet
- SortedMap: ConcurrentSkipListMap (Since Java 6)
- SortedSet: ConcurrentSkipListSet (Since Java 6)
- Queue 계열:ConcurrentLinkedQueue
- Since Java 5
- 특이사항: Concurrent(병렬/동시성)이란 단어에서 알 수 있듯이 Synchronized 컬렉션과 달리 여러 스레드가 동시에 컬렉션에 접근할 수 있다. ConcurrentHashMap의 경우, lock striping 이라 부르는 세밀한 동기화 기법을 사용하기 때문에 가능하다. 구현 소스를 보면 16개의 락 객체를 배열로 두고 전체 Hash 범위를 1/16로 나누어 락을 담당한다. 최대 16개의 스레드가 경쟁없이 동시에 맵 데이터를 사용할 수 있게 한다. (p.350)
반대로 단점도 있는데, clear()와 같이 전체 데이터를 독점적으로 사용해야할 경우, 단일 락을 사용할 때보다 동기화 시키기도 어렵고 자원도 많이 소모하게 된다. 또한, size(), isEmpty()같은 연산이 최신값을 반환하지 못할 수도 있다. 하지만 내부 상태를 정확하게 알려주지 못한다는 단점이 그다지 문제되는 경우는 거의 없다.
※ Queue, BlockingQueue 인터페이스는 Java 5에서 추가되었다. (Deque, BlockingDeque는 6에서 추가되었다.)
※ Synchronized 컬렉션은 객체 자체에 락을 걸어 독점하게되고, Concurrent 컬렉션은 객체 자체 독점하기가 쉽지 않은 단점이 있지만, 장점이 훨씬 더 많다. Concurrent 컬렉션은 컬렉션 전체를 독점하기 위해서는 충분히 신경을 기울여야 한다.
※ Hash를 기반으로 하는 컬렉션은 hashCode()의 해시값이 넓고 고르게 분포되지 못하면 한쪽으로 쏠린 해시 테이블을 사용하게 되는데, 최악의 경우는 단순한 Linked List와 거의 동일한 상태가 될 수 있다.
[Java] 병렬 프로그래밍에서 잊지말아야 할 조언들[Java] 병렬 프로그래밍에서 잊지말아야 할 조언들
Posted at 2013. 8. 17. 18:04 | Posted in 개발이야기여러 스레드가 클래스에 접근할 때, 실행 환경이 해당 스레드들의 실행을 어떻게 스케줄하든 어디에 끼워 넣든, 호출하는 쪽에서 추가적인 동기화나 다른 조율 없이도 정확하게 동작하면 해당 클래스는 스레드 안전하다고 말한다.(p.48)
상태 없는(Stateless) 객체는 항상 스레드 안전하다. (p.49)
종종 단순성과 성능이 서로 상충할 때가 있다. 동기화 정책을 구현할 때는 성능을 위해 조급하게 단순성(잠재적으로 안전성을 훼손하면서)을 희생하고픈 유혹을 버려야 한다. (p.65)
일례로, 한 클래스의 멤버 변수를 public으로 노출하여 사용한 경우, 이 변수가 어디서 어떻게 쓰일지 알 수 없으므로, 이 클래스를 Thread safe하게 만들기 위해서는 해당 변수를 사용한 곳을 모두 조사해봐야 한다. 그러나 private으로 숨기고 getter/setter를 사용한 경우 method 레벨에서 동기화를 구현하면 쉽게 Thread Safe한 클래스가 될 수 있다.
따라서, 번거럽더라도 getter/setter를 쓰는 것이 좋다. 너무도 명백하게 내부적으로 잠시 사용하는 inner class 같은 것들까지 getter/setter를 쓰는건 과한 것일 수도 있으니 적절히 판단해서 사용하자.
동기화와 캡슐화에 대한 이야기는 책의 여기저기에서 다른 표현들로 등장한다.
복잡하고 오래 걸리는 계산 작업, 네트웍 작업, 사용자 입출력 작업과 같이 빨리 끝나지 않을 수 있는 작업을 하는 부분에서는 가능한 한 락을 잡지 말아라. (p.65)
(계속)
[GWT] eclipse에 GWT project import 하기[GWT] eclipse에 GWT project import 하기
Posted at 2013. 8. 17. 15:06 | Posted in 개발이야기GWT 프로젝트 디렉토리를 이동하려고 다른 디렉토리에 옮겨놓은 후
다음과 같은 방법으로 다시 불러올 수 있다.
(1) .project 파일이 있는 경우: Import > General > Existing Projects into Workspace
(2) .project 파일이 없는 경우
New > Other... > GWT Designer > Model
Next 후에 project Root 디렉토리를 선택하면 .project 파일이 없어도 깔끔하게 import 된다.
How to install gnuplot in Mac OS X lionHow to install gnuplot in Mac OS X lion
Posted at 2013. 8. 9. 21:38 | Posted in OS/Machttp://bhou.wordpress.com/2011/09/13/how-to-install-gnuplot-in-mac-os-x-lion/
readline 라이브러리를 먼저 설치하고 gnuplot을 설치하면 된다.
$ ./configure --prefix=/usr/local
$ make
$ sudo make install
$ ./configure --prefix=/usr/local --with-readline=/usr/local
$ make
$ sudo make install
VirtualBox clipboard sharing not working sometimes(클립보드 공유가 가끔씩 안될 때)VirtualBox clipboard sharing not working sometimes(클립보드 공유가 가끔씩 안될 때)
Posted at 2013. 5. 24. 16:51 | Posted in Etc클립보드 공유가 가끔씩 안될 때
/usr/bin/VBoxClient --clipboard 를 재시작시키면 된다.
$ ps -ef | grep VBox | grep clipboard
deepblue 9952 1 0 16:44 ? 00:00:00 /usr/bin/VBoxClient --clipboard
$ kill -9 9952
DHT(Distributed Hash Table 분산 해시 테이블)DHT(Distributed Hash Table 분산 해시 테이블)
Posted at 2013. 4. 10. 12:33 | Posted in Server데이터와 서버를 동일한 주소 공간에 배치.
데이터의 키 값과 분산 서버 ID는 동일한 해시 함수로 동일한 주소 공간에 데이터와 노드를 배치.
중앙 서버 없이도 데이터를 관리하는 서버를 찾는 룩업에 성능이 좋다.
클러스터에 참여하는 서버의 추가/제거가 자동으로 이뤄지게 구성할 수 있다.
부하가 집중되지 않고 분산된다는 큰 장점이 있어, 극단적으로 큰 규모의 노드들도 관리할 수 있다.
종래의 순수 P2P에서 채용되었던 방식에서는 수십만 노드 정도가 한계였으나, DHT의 사용으로 수십억개의 노드를 검색범위로 할 수 있게 되었다. 그러나 DHT는 실제 구현이 어렵다.
키 공간 분할(keyspace partition)과 오버레이 네트워크(overlay network)로 구성된다.
- keyspace partition:
* 분산된 서버에 키를 어떻게 배치시킬 것인가를 결정하는 것
* 데이터의 hash(key) 값을 이용해 키 영역을 파티셔닝 시킨다.(range, interval)
- overlay network:
* 물리적인 서버의 연결과 상관없이 논리적인 서버 간의 연결 관리와 키를 담당하는 노드를 찾아가는 메커니즘을 제공.
* 특정 키를 서비스하는 노드를 찾아가는 라우팅 알로리즘을 제공한다.
DHT를 활용한 대표적인 시스템으로 비트토렌트(DHT를 확장하여 사용), eDonkey 등이 있다.
참고: 클라우드 컴퓨팅 구현 기술(에이콘), 위키백과
[번역] Virtual Nodes Strategies[번역] Virtual Nodes Strategies
Posted at 2013. 4. 10. 12:30 | Posted in Articleredis shard를 virtual node를 입혀보려고 연구중.
사례 및 기술연구를 위해 몇몇 문서를 번역해 본다.
※ 오역에 주의하시고, 잘못 번역된 부분은 댓글로 알려주세요.
[번역] Redis Sentinel Documentation[번역] Redis Sentinel Documentation
Posted at 2013. 4. 9. 16:43 | Posted in OpenSourceRedis HA 구성을 위해 Sentinel을 사용해보기로 했다.
제대로 알고 진행하도록 문서를 번역해봤다.
※ 잘못 번역된 부분은 댓글로 알려주세요.
<정리>
- 2013.04.28 현재 Redis stable 버전은 2.6.12임. |
- Monitoring: redis master, slave가 제대로 동작하는지 항상 검사한다.
- Notification: sentinel은 뭔가 잘못된 Redis 인스턴스의 상태를 API를 통해 시스템 운영자나 다른 컴퓨터 프로그램에 알릴 수 있다.
- Automatic failover: 마스터가 예상대로 동작하지 않으면, sentinel은 slave 하나를 master로 승격시키는 failover process를 시작할 수 있다. 다른 남은 slave들은 새로운 master에 붙도록 reconfigured되고, Redis를 사용하는 어플리케이션들은 접속시(Sentinel에게 접속시?) 새로운 주소를 통지 받는다.
redis-sentinel /path/to/sentinel.conf
redis-server /path/to/sentinel.conf --sentinel
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 900000
sentinel can-failover mymaster yes
sentinel parallel-syncs mymaster 1
sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 900000
sentinel can-failover resque yes
sentinel parallel-syncs resque 5
sentinel <option_name> <master_name> <option_value>
- down-after-millisecons 는 sentinel이 master가 다운됐다고 판단하는 millisecond 시간값이다(다운됐다는 것은 PING 명령에 대한 응답이 없거나, 응답에 에러가 있는 경우이다). 이 시간이 지난 후 sentinel은 주관적 다운(subjectivel down(SDOWN))상태로 만들며, 이 상태는 자동 failover를 시작하기에는 불충분한 상태이다. 그러나 sentinel들이 충분히 SDOWN 상태로 인지하면(역주: 첫째줄 설정에서 2 만큼의 Sentinel들이 SDOWN을 인지하면), 해당 master는 객관적 다운(objectively down(ODOWN)) 상태가 된다. 이 sentinel수는 master에 대해 설정된 sentinel 합의 수에 의존한다.
- can-failover 는 이 sentinel이 ODOWN이 감지되었을 때 failover를 할 수 있는지를 말한다. 필요하다면 모든 sentinel들에 대해서 failover를 수행하도록 구성할 수 있다. 또는, 몇 개의 sentinel만 합의할 수 있게 하고 failover 수행에 참여할 sentinel은 좀 더 둘 수도 있다.
- parallel-syncs 은 failover된 후 동시에 새 master를 사용하도록 재설정될(역주: recongiured라고 돼 있으나, resync가 문맥상 맞는 듯) 수 있는 slave수를 지정한다. 이 수치가 낮으면, failover 절차를 완료하는데 더 많은 시간이 걸릴 것이다. 그러나 slave들이 old data를 제공하도록 설정돼 있다면, 모든 slave들이 새 master로부터 동시에 resync 받기를 원치 않을 수도 있다. 복제(replication/resync) 절차가 slave에게 non-blocking이라고 할지라도, master로부터 resync하는 동안 bulk data를 요청하는 것이 redis(master)를 멈추게 하는 순간이 있다. 한번에 한 slave가 not reachable이 되는지 이 옵션을 1로 설정해서 확인할 수 있다.
- +PONG 으로 응답을 받은 경우
- -LOADING 에러로 응답을 받은 경우
- -MASTERDOWN 에러로 응답을 받은 경우
down-after-milliseconds
초 이내에 못받았다면, 그 인스턴스는 SDOWN상태가 된다. 유효한 PING 응답은 +PONG, -LOADING, -MASTERDOWN 이다.(sentinel port=22001) redis 127.0.0.1:22001> info # Server redis_version:2.6.10 redis_git_sha1:00000000 redis_git_dirty:0 redis_mode:sentinel os:Linux 2.6.18-308.11.1.el5xen x86_64 arch_bits:64 multiplexing_api:epoll gcc_version:4.1.2 process_id:21513 run_id:8c1735bdd62a2cfdc9ffc20f742470995a913b2c tcp_port:22001 (master port=21001) redis 127.0.0.1:21001> subscribe __sentinel__:hello Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "__sentinel__:hello" 3) (integer) 1 1) "message" 2) "__sentinel__:hello" 3) "10.101.58.67:22001:b7c8f61ff3d1963c7bd14b018c3dd86364885406:1" 1) "message" 2) "__sentinel__:hello" 3) "10.101.56.87:22001:8c1735bdd62a2cfdc9ffc20f742470995a913b2c:1" sentinel(22001)이 master(21001)을 감시하도록 한 후, master(21001)에 접속하여 'subscribe __sentinel__:hello' 를 치면, sentinel들이 보내오는 메시지를 볼 수 있다. |
- PING: 단순하게 PONG을 반환한다.
- SENTINEL masters: 모니터링하고 있는 master의 리스트와 그것들의 상태를 보여준다.
- SENTINEL slaves
<master name>
: master의 slave들의 리스트와 그것들의 상태를 보여준다. - SENTINEL is-master-down-by-addr
<ip> <port>
: 두개의 multi bulk reply를 반환한다. 첫번째는 0 또는 1이다(ip:port가 master의 주소가 맞고 SDOWN상태이면 0, 그 외는 1). 두번째는 이 master의 주관적 리더(subjective leader)이다. 이것은 조회된 master에 대해 failover를 수행해야 하는 sentinel 인스턴스의 runid이다. ( The second element of the reply is the subjective leader for this master, that is, therunid
of the Redis Sentinel instance that should perform the failover accordingly to the queried instance.) - SENTINEL get-master-addr-by-name
<master name>
: master name에 해당하는 ip와 port를 반환한다. 만약 failover가 진행중이거나 성공적으로 완료됐으면, promote 된 slave의 ip와 port가 반환된다. - SENTINEL reset
<pattern>
: 이 명령은 모든 매칭되는 이름의 master들을 reset한다. 패턴 인자는 glob-style 패턴이다. reset 프로세스는 master의 모든 이전 상태(failover in progress 상태를 포함하여)를 clear시키고, 해당 master와 통신하여 얻은 모든 slave와 sentinel 정보를 삭제한다.( The reset process clears any previous state in a master (including a failover in progress), and removes every slave and sentinel already discovered and associated with the master.) (역주: 어떤 상황이 되는지 테스트 해보자)
<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port>
- +reset-master <instance details> -- master가 reset 됐다.
- +slave <instance details> -- 새로운 slave가 감지됐고, 추가(attached)됐다.
- +failover-state-reconf-slaves <instance details> -- failover 상태가 reconf-slaves 상태로 변경됐다.
- +failover-detected <instance details> -- 다른 Sentinel에 의해 failover 상태가 시작됐거나, 외부의 다른 entity(slave가 master로 변경됨)가 감지되었다.(역주: entity는 관리대상 또는 master/slave shard 한 셋트를 의미)
- +slave-reconf-sent <instance details> -- 리더 Sentinel이 새 slave를 재설정(reconfigure)하기 위해 SLAVEOF 명령을 이 인스턴스에게 보냈다.
- +slave-reconf-inprog <instance details> -- 재설정되고 있는 slave가 새 master의 slave가 되고 있음을 보여준다. 그러나 동기화 작업은 아직 완료되지 않았다.
- +slave-reconf-done <instance details> -- slave가 새 master와 동기화 되었다.
- -dup-sentinel <instance details> -- 파라미터로 받은 master를 감시하는 하나 또는 그 이상의 sentinel이 중복되어 제거되었다.(이 이벤트는 Sentinel 중 하나가 재시작 되었을 때 발생한다.)
- +sentinel <instance details> -- 이 master를 위한 새로운 Sentinel이 감지되었고 추가되었다.
- +sdown <instance details> -- 인스턴스가 SDOWN 상태가 되었다.
- -sdown <instance details> -- 인스턴스는 이제 SDOWN 상태가 아니다.(역주: SDOWN 해제)
- +odown <instance details> -- 인스턴스가 ODOWN 상태가 되었다.
- -odown <instance details> -- 인스턴스는 이제 ODOWN 상태가 아니다.(역주: ODOWN 해제)
- +failover-takedown <instance details> -- 설정된 failover-timeout 시간의 25%가 지났다. 그러나 이 Sentinel은 진행 상태는 볼 수 없고 새 리더가 된다(역주:이 이벤트가 뜨는 Sentinel이 리더란 의미인 듯). 남은 slave들이 새 master로부터 복제되도록 새 리더로써 행동을 시작한다.
- +failover-triggered <instance details> -- 리더 Sentinel로써 failover를 시작하고 있다. (역주: 리더 Sentinel에만 이 이벤트가 발생한다.)
- +failover-state-wait-start <instance details> -- failover 상태가 "wait-start" 이다: failover를 시작하기 전에 { fixed seconds + random seconds } 동안 기다린다.
- +failover-state-select-slave <instance details> -- failover 상태가 "select-slave" 이다: promote할 적절한 slave를 찾고 있다.
- +no-good-slave <instance details> -- promote할 적절한 slave가 없다. 이 상태에서 얼마 후 재시도 하겠지만, 아마도 failover는 정지될 것이다.
- +selected-slave <instance details> -- promote시킬 적절한 slave를 찾았다.
- +failover-state-send-slaveof-noone <instance details> -- master로 promote될 slave를 재설정하고 있고, 변경되기를 기다리고 있다. (역주: master로 만들 slave에 "slaveof nonone" 명령을 보내 role이 master가 되도록 한다.)
- +failover-end-for-timeout <instance details> -- failover가 timeout으로 종료되었다. 만약 리더 Sentinel에서 발생했으면, 아직 재설정되지 않은 나머지 slave들에게 최선의 방법으로 SLAVEOF를 보낸다(보냈다).
- +failover-end <instance details> -- failover가 성공적으로 끝났다. 모든 slave들이 새 master에 붙었으며 복제되도록 설정되었음을 나타낸다. (역주: 복제는 master-slave간에 진행중이며, 별도 프로세스가 fork되어 진행된다.)
- +switch-master <master name> <oldIp> <oldPort> <newIp> <newPort> -- 예전과 같은 이름으로 새 master의 모니터링을 시작한다. old master는 관리 테이블에서 완전히 삭제될 것이다.
- +failover-abort-x-sdown <instance details> -- promote될 slave가 extended SDOWN 상태가 되어 failover는 중지(undoed/aborted)되었다.
- -slave-reconf-undo <instance details> -- failover가 중지(aborted)되었고, 그래서 파라미터로 받은 인스턴스에게 원래 master를 바라보도록 SLAVEOF 명령을 보냈다.
- +tilt -- tilt 모드로 들어갔다.
- -tilt -- tilt 모드에서 나왔다.
- master가 ODOWN 상태가 되는 것을 인지.
- 어떤 Sentinel이 failover를 시작시킬지 알게된다. 이 Sentinel을 리더(Leader)라고 부르며 다른 Sentinel들은 옵저버(Observer)가 된다.
- 리더는 master로 promote시킬 slave를 선택한다.
- promote될 slave는 SLAVEOF NO ONE 명령으로 master가 된다.
- 옵저버들은 한 slave가 master로 바뀌는 것을 보게되고, failover가 시작되는 것을 알게 된다. Note: 이것은 옵저버들에 의해 모니터링 되는 master의 slave 중 하나가 master가 된다는 것을 failover 과정이 시작됨으로써 알게 된다.
- 원래 master에 붙어 있던 다른 모든 slave들은 새로운 master로부터 복제되도록 SLAVEOF 명령으로 재설정된다.
- 모든 slave들이 재설정되면 리더는 failover 과정을 끝낸다. 관리 테이블에서 old master를 제거하고 new master를 추가한다. 이 때 원래 master의 이름을 사용한다. (역주: master name은 변경되지 않고 master 정보(주소)만 바뀜을 의미)
- 모든 slave들이 재설정되면 옵저버들은 failover가 끝났음을 감지한다. 리더가 했던 것과 동일하게 관리 테이블에서 old master를 제거하고 new master를 감시하기 시작한다.
- failover를 할 수 없도록 설정된 Sentinel들은 제외한다.(이 정보는 Hello 채널을 통해서 모든 Sentinel들에게 전파된다.)
- SDOWN 상태인 Sentinel, 또는 SENTINEL_INFO_VALIDITY_TIME 밀리초(5초) 내에 ping 응답을 받지 못한 Sentinel들은 제외한다.
- 남은 Sentinel들 중에서, 사전순서상(lexicographically) runid가 가장 낮은 것을 선택한다.(모든 Redis 인스턴스는 runid를 가지며, 모든 실행의 식별자로 사용된다.)
- 자기가 주관적 리더(Subjective Leader)인지 확인한다.
- 다른 Sentinel들로부터 리더가 맞는지에 대한 동의(acknowledges)를 받는다: 적어도 51%의 Sentinel들이 SENTINEL is-master-down-by-addr 의 응답으로 리더에 동의한다는 정보를 줄 수 있었고, failover를 하려고 하는 master에 설정된 정족수(quorum)에 만족해야 한다. (역주: sentinel.conf에 설정된 각 master(redis shard 또는 cluster)의 odown감지 정족수를 의미하며, SENTINEL is-master-down-by-addr는 sentinel간에 주고 받는 명령이다.)
- promote된 slave가 SDOWN 상태가 아니다.
- 한 slave가 새로운 master로 승격(promoted)되었다.
- 다른 모든 slave가 새 master를 바라보도록 설정 되었다.
- promote된 slave는 SDOWN 상태가 아니다.
- 한 slave가 새로운 master로 승격(promoted)되었다.
- 마지막 과정 이후로 적어도 failover-timeout 밀리초가 지났다.
failover-timeout
configuration option.)- 리더 Sentinel 또는 옵저버의 관점에서 failover가 시작된 이후에 old master는 new master의 slave 목록에 추가된다. 이 때 특수한 DEMOTE 플래그라는 것을 달고 추가된다(이 것은 SENTINEL SLAVES 명령의 결과로 확인할 수 있다).
- old master가 되살아났고 다시 접속할 수 있을 때, 이 old master가 자신이 master라고 알려오면(INFO의 결과로 안다), Sentinel은 재설정 하기 위해 SLAVEOF 명령을 보낸다. 이 인스턴스가 slave라고 다시 알려오면 DEMOTE 플래그는 클리어시킨다.
(역주: Redis instance를 시작시키면 stand-alone master 롤로 뜨는데, 이 경우 Sentinel이 DEMOTE 플래그를 달고 관리 목록에 넣어뒀다가 다시 해당 인스턴스가 접속하면 재설정한다는 이야기인데, DEMOTE 플래그가 꺼진 상황에서 다시 재시작되면 또 다시 stand-alone master로 뜨게 된다. 이 때 Sentinel이 재시작하게 되면 대형 장애로 이어질 수 있다. sentinel.conf 에는 old master가 master로 설정돼 있기 때문이다. 이 경우 sentinel을 여러개 운영해서 sentinel이 재시작할 때 다른 sentinel의 상태를 conf파일로 덤프 받아 시작하는 방법이 안전하다, 또는 sentinel network에 처음 추가된 경우 sentinel.conf가 아니라 network에서 redis 인스턴스 정보를 받아오도록 보완되어야 할 것으로 보인다.)
- TODO: SENTINEL FAILOVER 로 failover 수동 시작.
- TODO: SENTINEL PAUSE, RESUME으로 Sentinel 일시정지, 재시작 시키기.
- TODO: Sentinel은 자동 failback은 수행하지 않는다.
- TODO: failback을 위한 단계를 문서화하기.
- 모든 행동을 멈춘다.
- SENTINEL ismaster-down-by-addr 요청에 대해 부적격(negatively) 응답을 보내 사용할 수 없는 상태임을 알린다.