현재 진행 중인 교육 시리즈에서 매번 여러 가지 질문이 나오는데, 아래에 각 질문에 대한 답변을 나열해 보았습니다!
Couchbase 101 - 아키텍처, 설치 및 구성
루비 기반 로드 생성기는 여기에서 다운로드할 수 있습니다: https://github.com/scalabl3/ruby-couchbase-loadgen
질문: 프로덕션에서 2.0을 사용 중인데 2.2로 업그레이드하는 모범 사례는 무엇인가요?
A: 세 가지 방법으로 클러스터를 업그레이드할 수 있습니다. 첫 번째는 스왑 재조정 온라인 업그레이드이며 업그레이드하면서 클러스터의 가동 시간을 유지할 수 있는 좋은 방법입니다. 스왑 리밸런싱을 수행하려면 현재 클러스터 크기와 동일한 수의 Couchbase 2.2를 실행하는 새 노드를 추가하되, 리밸런싱하기 전에 Couchbase 2.0 노드를 제거합니다. 리밸런싱할 때 동일한 수의 노드를 추가하고 제거하므로 가장 효율적입니다. 여기에서 자세히 알아보세요: http://docs.couchbase.com/couchbase-manual-2.0/#swap-rebalance 이전 클러스터에서 새 클러스터로 cbbackup/cbrestore를 사용하여 오프라인 업그레이드를 수행하거나 cbtransfer를 사용할 수도 있습니다(단, 전송하기 전에 데이터를 생성하는 작업을 중단해야 합니다!).
질문: Couchbase Server는 무료인가요, 아니면 라이선스가 필요한가요?
A: 카우치베이스 커뮤니티는 노드 수에 관계없이 개발 및 프로덕션에 무료로 사용할 수 있습니다. Couchbase Enterprise는 노드 수에 관계없이 개발 및 프로덕션 환경에서 최대 2개까지 무료로 사용할 수 있습니다. 프로덕션에서 2개 이상의 노드를 사용하려면 라이선스가 필요하지만, 라이선스에는 엔터프라이즈 지원도 번들로 포함되어 있습니다!
질문: 애플리케이션 서버는 물리적 기기인가요, 아니면 가상 머신일 수 있나요?
A: 애플리케이션 서버와 Couchbase 서버는 모두 물리적 머신이거나 가상 머신일 수 있습니다.
질문: 카우치베이스를 클리어퀘스트/클리어케이스의 대안으로 사용할 수 있나요, 아니면 이 제품은 문서 관리용으로만 사용되나요?
A: 카우치베이스는 애플리케이션을 구축하는 데이터 저장소이며, 클리어퀘스트/클리어케이스는 다음과 같습니다. 애플리케이션 데이터 저장소를 기반으로 구축되었기 때문에 Couchbase와 비교하는 것은 실제로 "사과 대 사과"가 아닙니다.
Q: Couchbase를 SNMP로 모니터링할 수 있나요? Couchbase 모니터링을 Solarwinds와 통합할 수 있나요?
A: 다른 시스템과 마찬가지로 SNMP를 사용하여 서버 자체를 모니터링할 수 있지만, 현재 Couchbase 자체에는 SNMP 통합 기능이 없습니다. 제가 아는 한 Solarwinds와의 기본 통합 표준은 알지 못하지만, Solarwinds를 확장하여 http/JSON에서 정보를 폴링하고 사용자 지정 트리거를 만들 수 있다면 어렵지 않을 것이라고 생각합니다.
질문: 카우치베이스는 대기 카우치베이스 노드로의 페일오버를 지원하나요? 저장된 데이터는 스탠바이 카우치베이스 클러스터와 어떻게 동기화되나요?
A: 장애 조치에는 복제 파티션을 활성 파티션으로 승격하는 작업이 포함되기 때문에 대기 노드로의 자동 장애 조치는 제공되지 않습니다. 대기 노드를 사용하려면 어떤 노드(및 어떤 파티션)에 액세스할 수 없거나 실패할지 모르기 때문에 클러스터의 모든 데이터 사본이 대기 노드에 있어야 합니다. 대신 복제 파티션이 있고 장애가 발생하면 장애 조치로 인해 복제 파티션이 활성화되므로 이렇게 하는 것이 합리적이지 않습니다. 별도의 클러스터 전체를 대기 상태로 유지 관리하는 경우(그리고 활성 클러스터 데이터를 복제하기 위해 XDCR(교차 데이터 센터 복제)을 사용하는 경우) 클러스터 교체 시기를 결정하기 위한 자체 로직을 스크립트로 작성해야 합니다.
질문: 메타데이터 값(예: 아이디)을 CB 시스템에서 자동화할 수 있나요(예: 아이디 자동 카운트), 아니면 애플리케이션에 그 책임을 넘길 수 있나요?
A: 모든 ID(키)는 애플리케이션의 책임이며, Couchbase에는 ID 생성을 위한 메커니즘이 내장되어 있지 않습니다. 그러나 원자 카운터를 사용하여 RDBMS의 ID 열처럼 작동할 수 있습니다. 몇 가지 패턴에 대한 자세한 내용은 Couchbase 103 웨비나를 참조하세요.
질문: mp3나 오디오 또는 비디오 파일을 Couchbase에 저장할 수 있나요?
A: 물론 간단한 데이터 유형, JSON, 모든 유형의 바이너리 데이터(MP3, JPEG, PNG 등) 등 무엇이든 Couchbase에 저장할 수 있습니다. '문서' 당 20MB의 용량 제한만 있습니다. 하지만 동영상 파일은 용량이 상당히 큰 경우가 많으므로 대용량 파일을 많은 시청자에게 스트리밍하기 위해 설계된 CDN 시스템을 사용하고 파일의 자산 메타데이터(예: 제목, 스트리밍할 URL 등)를 Couchbase에 저장하는 것이 더 좋습니다.
질문: OS를 위해 얼마나 많은 RAM을 남겨두어야 하나요?
A: 상황에 따라 다르지만 뷰를 많이 사용하는 경우에는 파일 시스템 캐시에 더 많은 RAM을 할당하는 것이 현명할 것입니다. 일반적으로 약 40%의 사용 가능한 RAM을 OS에 남겨 두는 것이 좋으며(따라서 60%를 사용하도록 Couchbase를 구성), 이는 전반적으로 좋은 성능을 제공합니다. 보기를 사용하지 않는 경우에는 Couchbase에 더 많은 RAM을 할당할 수 있습니다. 이 블로그 게시물의 크기 조정 가이드라인을 참조하는 것이 좋습니다: https://www.couchbase.com/blog/how-many-nodes-part-1-introduction-sizing-couchbase-server-20-cluster
질문: 16GB 4코어 시스템에서 높은 OPS란 무엇인가요?
A: 또 다른 "상황에 따라 다르지만", 네트워크 속도와 유선을 통해 Couchbase로 바이너리 작업을 전송하는 기능에 따라 크게 영향을 받습니다. Amazon AWS의 16GB 4코어 박스는 10GigE로 로드 생성기에 연결된 물리적 박스와는 다릅니다. 이런 종류의 성능을 볼 수 없습니다, https://www.couchbase.com/blog/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server 에서! 그러나 이는 실제로 Couchbase 자체가 운영을 제한하는 것이 아니라 바이너리 소켓을 통해 Couchbase에 운영을 제공하는 네트워킹 및 기능이라는 것을 보여줍니다.
Q: 몇 개의 복제본을 권장하나요?
답변: 일반적으로 대부분의 사람들은 1개의 복제본에 만족하지만, 2개의 복제본의 안정성을 원하는 고객도 있지만 3개의 복제본을 사용하는 고객은 제가 알지 못합니다. 물론 복제본을 인덱싱하려면 할당된 RAM과 잠재적으로 CPU가 더 많은 복제본을 위해 서버를 강화해야 합니다. 궁극적으로 데이터에 대해 가장 잘 알고 있고 데이터 손실 등에 대비해 데이터를 보호하는 것이 중요하므로 그 결정은 사용자가 내려야 합니다.
질문: SDK 클라이언트 연결의 경우 모든 서버 IP를 수동으로 추가해야 하나요?
답변: 이 문제를 처리하는 방법에는 여러 가지가 있습니다. 예를 들어 DNS를 통해 앱 서버가 항상 CNAME 또는 A 레코드에 연결하고 모든 클러스터 머신을 A 레코드에 나열(또는 자동 등록)하도록 하는 방법이 있습니다. 또는 서버 전체(또는 중앙 위치)에서 업데이트되는 구성 파일에 IP를 넣거나 애플리케이션 시작 코드에 IP를 입력하는 등의 방법을 사용할 수 있습니다.
Q: OS와 관련하여 우분투에서 사용할 수 있습니다. 데비안과 같은 다른 배포판을 사용해도 문제가 없나요?
A: 괜찮다고 생각하지만 직접 사용해 보지는 않았습니다. 다운로드 페이지에 나열된 OS는 많은 테스트를 거친 OS입니다. 저희 엔지니어 중 한 명이 조이엔트 스마트OS에서 카우치베이스를 작동시킨 것으로 알고 있지만 공식 다운로드 등은 아닙니다.
질문: 메타데이터는 지속되지 않나요?
A: 메타데이터도 물론 디스크에 보존되지만, 다음과 같이 항상 RAM에 보관. 버킷에 (클러스터 전체에 걸쳐) 값을 담을 수 있는 충분한 RAM이 있는 경우 문서는 RAM에 저장됩니다. 그렇지 않은 경우 최근 사용되지 않음(NRU)을 사용하여 문서를 꺼냅니다. 값 를 디스크에 저장합니다.
질문: IO 워커의 용도는 무엇인가요? 새 노드를 추가할 때 분할되는 이유는 무엇인가요?
A: IO 워커는 디스크에서 읽기/쓰기에 사용되며, 버킷 구성의 스레드(워커) 수를 용량에 따라 늘릴 수 있습니다(워커를 4개만 처리할 수 있는 경우 8개로 설정해도 성능에는 변화가 없음). 클러스터에 노드를 더 추가하면 IO 워커가 선형적으로 증가하며, 새 노드가 추가될 때마다 동일한 양의 IO 워커(자체 IO용)가 추가됩니다. 노드별로 "분할"되지 않고 노드당 할당됩니다.
질문: "최근 최고 수위가 80%에서 90%로 변경되었습니다"라고 하셨는데요? 저수위는 어떻게 되나요? 여전히 60%인가요, 아니면 변경되었나요?
A: 이는 실제로 구성 가능한 매개변수이며, 기본 설정은 로우 워터마크의 경우 대략 80%, 하이 워터마크의 경우 90%입니다. 로우 워터마크에서는 RAM에서 복제본 파티션 데이터를 내보내기 시작하고, 하이 워터마크에서는 RAM에서 활성 파티션 데이터를 내보내기 시작합니다. 이러한 매개변수는 버킷 수준에서도 구성할 수 있습니다(http://docs.couchbase.com/couchbase-manual-2.2/#changing-thresholds-for-ejection 참조).
질문: 데이터 버킷을 삭제하려면 어떻게 해야 하나요?
A: 관리자 인터페이스에서 상단 탐색 메뉴의 데이터 버킷을 클릭하고 버킷 이름 옆의 삼각형을 클릭하여 확장한 다음 오른쪽의 편집 버튼을 클릭하면 나타나는 모달 대화 상자의 하단에 삭제 버튼이 있습니다. SDK에서 프로그래밍 방식으로 버킷을 삭제할 수도 있습니다.
질문: Couchbase는 Apache CouchDB와 어떤 관련이 있나요?
A: CouchDB의 창립자(Damien Miller와 JChris Anderson)는 Apache CouchDB 프로젝트를 떠나 Northscale/Membase의 Steve Yen, Dustin Sallings와 함께 Couchbase의 창립자로 합류/합병했습니다. 뷰 맵-리듀스 스타일과 쿼리 구문에는 CouchDB 사용자에게 친숙한 유사점이 많지만, 중요한 차이점도 많습니다. Couchbase는 영리를 목적으로 하는 독립적인 오픈 소스 회사로, 어떤 방식으로든 CouchDB에 종속되지 않는 독립적인 코드 기반을 갖추고 있습니다. 그러나 바이너리 CRUD 작업은 CouchDB와 관련된 것이 아니라 memcached/membase와 유사합니다. 그들은 확실히 덜 혼란스러운 이름을 선택할 수 있었을 텐데...
질문: 아키텍처는 균형이 맞지 않는 파티션을 어떻게 처리하나요?
A: 사실 저희의 해싱 및 파티션 전략은 수년에 걸쳐 매우 잘 분산되는 것으로 나타났기 때문에 여전히 이 전략을 사용하고 있습니다.
Q: 노드 장애는 어떻게 처리되나요?
답변: 노드 장애를 처리하는 방법에는 두 가지가 있는데, 첫 번째는 자동 장애 조치를 활성화하는 것입니다. 자동 장애 조치에서 노드에 30초 동안 연결할 수 없는 경우 해당 노드는 자동으로 장애 조치되고 복제본은 활성으로 승격됩니다. 다른 방법은 노드를 수동으로 페일오버(또는 자체 모니터링 솔루션에 따라 자동으로 페일오버하도록 스크립팅)하는 것으로, 노드 페일오버에 대한 모든 매개변수와 타이밍을 유연하게 결정할 수 있습니다.
질문: 페도라17에 카우치베이스 엔터프라이즈2.2.0 서버를 설치하려고 했는데 libcrypto.so 및 libssl.so에 오류가 발생했는데 어떻게 해결해야 하나요?
A: 예, erlang 코어 라이브러리의 erlang 종속성 때문에 openssl098e를 yum 설치해야 합니다.
질문: 산이란 Couchbase에서 무엇을 의미하나요?
A: 카우치베이스는 문서 단위로 ACID "트랜잭션"을 지원합니다. 낙관적인 동시성 시나리오에서는 CAS(확인 및 설정/비교 및 교환)를 사용하거나 비관적인 동시성 시나리오에서는 GetAndLock을 사용하여 문서를 실제로 잠글 수 있습니다. 일반적으로 정규화된 RDBMS 데이터 저장소에서는 트랜잭션이 훨씬 더 많이 필요합니다. 그 이유는 정규화로 인해 데이터 구조가 여러 개의 테이블로 나뉘는 경우가 많기 때문에 트랜잭션이 없으면 데이터 무결성이 빠르게 무너집니다. Couchbase와 같은 NoSQL 시나리오에서는 데이터가 훨씬 덜 정규화되어 있기 때문에 일반적으로 트랜잭션이 RDBMS 환경보다 덜 필요합니다. 동시성 모델을 사용하면 트랜잭션을 생성할 수 있습니다. 또한 데이터가 복제본 및/또는 디스크에 도달했는지 확인할 수 있는 내구성 작업도 있습니다.
질문: 클러스터의 노드 중 하나가 다운되면 클라이언트 앱서버의 맵과 해당 노드의 데이터는 어떻게 업데이트되나요?
A: 장애 조치가 트리거되면(자동 또는 수동으로) 복제 파티션이 활성으로 승격됩니다. 노드가 소유하지 않은 파티션 번호에 대한 CRUD 작업을 받는 경우, 노드는 sdk 클라이언트에 "Not My VBucket" 오류를 반환하며, sdk 클라이언트는 이를 처리하는 방법을 알고 있습니다. 이 오류는 클러스터 맵이 오래되었거나 동기화되지 않았음을 나타내며, 영구 HTTP 연결에서 자동으로 새 클러스터 맵을 요청합니다. 클러스터 맵이 변경되는 경우는 리밸런싱과 장애 조치의 두 가지 시나리오뿐입니다. 즉, 토폴로지가 변경되고 클러스터 맵이 변경되는 경우이며, 클라이언트는 첫 번째 작업에서 "내 VBucket이 아님" 오류를 반환하는 것을 볼 수 있습니다.
질문: 각 서버의 디스크 하드 용량이 20GB로 제한되어 있나요?
A: 저장 용량 제한은 없으며, 잘못 알고 계셨을 수 있는 것은 Couchbase의 문서 값당 20MB 제한이 있다는 것입니다.
질문: 디스크 쓰기만 추가하는 기능은 저널링과 유사하며 어떤 OS 파일 시스템을 사용하나요?
A: 예, 비슷한 전략이지만 저희만의 형식이 있습니다.
질문: 사용 가능한 디스크 크기를 모니터링할 수 있는 방법이 있나요? 임계값(예: 80% 가득 차 있음)에 도달하면 호출기나 이메일 알림이 전송되나요? CPU/MEM 사용량도 마찬가지인가요?
A: 이러한 종류의 알림 시스템이 기본 제공되지는 않지만 이를 위해 자체 시스템을 통합하는 것은 확실히 간단합니다. 이는 Couchbase 전용이라기보다는 VM/컴퓨터 모니터링과 비슷하지만, 사용자 지정 매개변수에 대한 통합을 쉽게 만들 수 있습니다. 관리 콘솔의 그래프에 있는 모든 정보는 http 요청을 통해 JSON으로 제공됩니다.
Q: 버킷이란 무엇인가요?
답변: 버킷은 데이터의 모음인 '데이터베이스'입니다. 또한 데이터의 네임스페이스이기도 하므로 모든 키는 버킷 내에서 고유해야 합니다. 또한 뷰의 네임스페이스 역할도 하며, 디자인 문서와 뷰는 해당 뷰가 정의된 버킷 내의 데이터에만 액세스할 수 있습니다.
Q: 카우치베이스 서버와 애플리케이션 서버가 여러 대 있는 경우 모든 애플리케이션 서버가 동일한 카우치베이스 서버(동일한 IP 주소)에 연결할 수 있나요? 이 경우 로드 밸런싱은 카우치베이스에서 자동으로 수행되나요, 아니면 애플리케이션 서버 간에 연결을 분산하는 것이 더 좋은가요?
A: 좋은 질문입니다. 실제로 애플리케이션 서버와 Couchbase 사이에 로드 밸런서를 두지 않는 것이 중요합니다. 키 해시 파티셔닝으로 인해 데이터는 이미 Couchbase 클러스터 전체에 자동으로 분산되어 있습니다. 앱 서버는 키 해싱을 기반으로 클러스터 전체에서 CRUD 작업을 수행한다는 의미에서 이미 "로드 밸런싱"되어 있으며, 파티셔닝으로 인해 Couchbase 클러스터 노드에 직접 연결하고 상호 작용하게 됩니다. 앱 서버와 SDK 클라이언트는 Couchbase 클러스터의 각 노드에 대한 열린 연결을 유지하며, 일반적으로 각 앱 서버에는 하나의 공유 연결만 있으면 됩니다.
질문: 버킷이 포함된 문서의 리밸런싱이 진행되는 동안 클라이언트 앱에서 문서에 액세스하는 경우 어떻게 되나요?
A: 재조정 중에도 모든 작업은 정상적으로 계속되며, 재조정보다 정상 작업이 우선시됩니다. 즉, 작업을 수행하는 동안 리밸런싱이 계속 진행됩니다. 물론 일반적으로 사용량이 많을 때는 리밸런싱을 시작하지 않는 것이 가장 좋습니다! 그러나 속도 저하를 유발할 수 있는지 여부는 사용량 수준과 구성에 따라 다릅니다. 대부분의 경우 눈에 띄지 않습니다.
질문: Couchbase에서 유사한 BLOB 유형은 무엇인가요?
A: SDK를 사용하여 바이너리 데이터를 직접 값으로 저장할 수 있으며, 정의되거나 강제된 스키마가 없으므로 BLOB임을 지정할 필요가 없습니다. BLOB은 단순히 '문서'의 값입니다.
질문: 설정된 작업을 수행할 때 문서가 먼저 RAM으로 이동한 다음 디스크 쓰기 대기열과 복제 대기열로 보내지는데, 문서가 RAM에 있을 때 노드가 충돌하면 어떻게 되나요?
A: 모든 유형의 시스템(모든 유형의 데이터베이스, 앱 서버, 휴대폰 등)에 장애가 발생하면 항상 데이터 손실의 가능성이 있습니다. 모든 전략은 가능한 한 이를 최소화하기 위한 것이지만, 정확히 이 시나리오에서는 저장과 RAM, 그리고 대기열에 삽입하는 바로 그 순간에 컴퓨터가 충돌하는 경우 데이터가 RAM에는 들어가지만 디스크 쓰기 대기열이나 복제 대기열에는 들어가지 않을 수 있습니다.
질문: 서버를 추가하면 샤딩이 되나요?
A: 예, 모든 데이터에 "해시 샤딩"을 사용합니다. 즉, 모든 키-값 쌍에 대해 문자열 키를 해시하여 해당 키가 있어야 할 파티션 번호(논리적 컨테이너)를 얻습니다. 클러스터 맵에서 파티션 번호를 조회하여 해당 파티션이 Couchbase 클러스터에서 어디에 있는지 확인한 다음, 해당 파티션을 담당하는 Couchbase 노드에서 직접 CRUD를 수행합니다. 새 서버(또는 두 개 이상)를 추가하면 새로운 노드 수에 따라 파티션을 균등하게 재분배하기만 하면 됩니다.
질문: 복제 전용 서버를 추가해야 하나요?
A: 장애 조치 상황에서의 효율성을 위해 복제본은 노드를 "장애 조치"할 수 있도록 서로 다른 노드에 위치해야 합니다. 하나의 복제본에는 최소 두 개의 Couchbase 노드가 있어야 합니다. 복제본이 2개인 경우에는 최소 3개의 Couchbase 노드가 있어야 하고, 복제본이 3개인 경우에는 최소 4개의 Couchbase 노드가 있어야 합니다. 물론 복제본 수를 늘리면 최적의 성능을 위해 더 많은 리소스가 필요합니다.
질문: 해시값이 같은 모든 문서가 같은 파티션에 저장되나요?
A: 예, 해시 함수는 단순히 문자열 키를 [0...1023]의 숫자로 바꾸는 것이며, 숫자 2로 해시되는 모든 키는 파티션 컨테이너 #2 내에 존재합니다. 해당 파티션은 클러스터의 특정 Couchbase 노드에 상주하며, 서버를 더 추가하고 재조정하면 해당 파티션을 다른 서버로 이동할 수 있지만 해당 파티션의 "마스터"인 노드는 항상 한 개만 존재합니다. 물론 해당 파티션의 '복제본'은 별도의 노드에 존재합니다.
질문: 수평 스케일 예제에서 총 파티션은 항상 1024개입니다. 클러스터의 최대 파티션은 1024개인가요?
A: 샤딩 및 배포 방식을 처음 배울 때 많은 개발자가 이 숫자를 조정할 수 있는 노브로 생각하는데, 이는 우리 모두가 땜장이이기 때문입니다. 하지만 파티션의 수는 성능 특성을 바꾸지 않습니다. 1024개는 데이터를 균등하게 분배하는 데 적합한 파티션 수이며, 변경할 필요가 없고 구성 매개변수가 아닙니다. 이 숫자는 10,000개 또는 990개가 될 수도 있으며, 데이터 배포 방식의 아키텍처를 변경하지 않습니다(데이터 파일 수를 늘리거나 줄이는 것일 뿐).
질문: 단일 가상 머신에 몇 개의 버킷을 설치할 수 있나요?
답변: 가상 머신에 할당된 리소스는 매우 다양할 수 있으므로 경험칙을 제시하기 어려운 질문이지만 일반적으로 8코어 이상의 상당한 규모의 머신의 경우 약 10~12개의 버킷이 가능합니다. 각 버킷마다 관리 및 모니터링할 리소스를 할당하므로 많은 수의 버킷을 사용하면 CPU 오버헤드가 증가하므로 일반적으로 권장하지 않습니다.
질문: 노드 리밸런싱이 카우치베이스의 효율성에 어떤 영향을 미치나요?
답변: 저희는 리밸런싱 작업보다 기본 작업을 우선시하지만, 리밸런싱 중에는 Couchbase 노드 간에 CPU 및 네트워크 트래픽이 증가합니다. 물론 다른 시스템과 마찬가지로 백업을 수행할 때도 마찬가지로 사용량이 많지 않은 시간에 리밸런싱을 수행하는 것이 좋습니다. 사용량이 많은 시간에 리밸런싱을 수행하면 사용량이 매우 많은 경우 리밸런싱 시간이 확실히 느려집니다.
질문: 재조정할 때 파티션이 실제로 다른 노드로 이동되나요, 아니면 중복되나요?
A: 리밸런싱 중 장애가 발생할 경우를 대비해 리밸런싱이 완료될 때까지 복사됩니다. 원래 마스터 노드는 리밸런싱이 완전히 완료될 때까지 마스터 노드로 유지됩니다. 리밸런싱이 완료되면 해당 파티션의 새 마스터 노드가 마스터가 되고 이전 마스터 노드는 데이터를 제거하며, 클러스터 맵이 클러스터 전체에 걸쳐 업데이트된 다음 클라이언트 SDK의 클러스터 맵이 업데이트됩니다.
질문: 백업/복원 및 재해 복구에 사용할 수 있는 도구에는 어떤 것이 있나요?
A: 이 용도로만 사용할 수 있는 cbbackup 및 cbrestore 명령줄 도구가 있으며, 여기에서 자세한 내용을 확인할 수 있습니다: http://www.couchbase.com/docs//couchbase-manual-2.0/couchbase-backup-restore-backup-cbbackup.html
