맨위로가기

래프트 (컴퓨터 과학)

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

래프트(Raft)는 선출된 리더를 통해 합의를 달성하는 분산 시스템을 위한 합의 알고리즘이다. 래프트 클러스터는 리더, 팔로워, 후보자 역할을 수행하는 서버로 구성되며, 리더 선출, 로그 복제를 통해 일관성을 유지한다. 래프트는 리더 선출, 로그 복제, 안전성 규칙을 통해 시스템 안정성을 보장하며, 선출 안정성, 리더 유일 확장, 로그 매칭, 리더 완전성, 상태 기계 안전성 등의 안전성 규칙을 따른다. 래프트는 CockroachDB, etcd, MongoDB, Neo4j 등 다양한 데이터베이스 및 분산 시스템에서 활용되고 있다.

더 읽어볼만한 페이지

  • 분산 알고리즘 - 병렬 알고리즘
    병렬 알고리즘은 여러 프로세서가 동시에 문제를 해결하도록 설계되었으며, 병렬화 가능성에 따라 분류되고 통신 오버헤드와 부하 분산이 중요하며, 다양한 하드웨어에서 구현될 수 있다.
  • 분산 알고리즘 - 콘텐츠 전송 네트워크
    콘텐츠 전송 네트워크(CDN)는 지리적으로 분산된 서버 네트워크를 이용하여 사용자에게 콘텐츠를 효율적으로 전송하는 시스템으로, 엣지 서버 캐싱, 데이터 전송 시간 단축, 대역폭 비용 절감, 가용성 향상 등의 이점을 제공하지만 보안 및 개인 정보 보호, 특정 업체 의존성 등의 과제도 존재한다.
  • 장애 허용 컴퓨터 시스템 - 컴퓨터 클러스터
    컴퓨터 클러스터는 여러 대의 상용 컴퓨터를 고속 네트워크로 연결하여 고성능 컴퓨팅 시스템을 구축하는 방식으로, 슈퍼컴퓨터를 포함한 다양한 분야에서 높은 가용성과 확장성을 제공하며, 클러스터 미들웨어를 통해 시스템 관리, 부하 분산, 통신 방식, 데이터 공유 등을 지원하고 노드 장애 관리를 위한 펜싱 기술을 활용한다.
  • 장애 허용 컴퓨터 시스템 - 트랜잭션 처리
    트랜잭션 처리는 데이터베이스 시스템에서 데이터의 일관성과 무결성을 보장하기 위한 기술이며, ACID 속성을 통해 데이터 정확성을 유지하고 롤백, 데드락 처리 등의 기술을 활용한다.
  • 분산 컴퓨팅 - 클라우드 컴퓨팅
    클라우드 컴퓨팅은 인터넷을 통해 컴퓨팅 자원을 서비스 형태로 제공하는 모델로, 다양한 서비스 및 배치 모델을 가지며 비용 효율성과 확장성을 제공하지만 보안 및 의존성 문제도 존재하며 지속적으로 발전하고 있다.
  • 분산 컴퓨팅 - 그리드 컴퓨팅
    그리드 컴퓨팅은 지리적으로 분산된 컴퓨터 자원을 연결하여 가상 슈퍼컴퓨터를 구축하는 기술이며, 유휴 자원을 활용하고 과학 연구 등 다양한 분야에 활용된다.
래프트 (컴퓨터 과학)
Raft 알고리즘 정보
Raft 컨센서스 알고리즘 마스코트
Raft 컨센서스 알고리즘 마스코트
종류コンセンサスアルゴリズム
개발 연도2013년
개발자디에고 옹가로(Diego Ongaro), 존 아우스터하우트(John Ousterhout)
참고 문헌In Search of an Understandable Consensus Algorithm
웹사이트Raft Consensus Algorithm
이름 유래Why the "Raft" name?

2. 기초

래프트는 선출된 리더를 통해 합의를 달성한다. 래프트 클러스터의 서버는 리더, 추종자, 또는 리더 선출 과정에서의 후보자 중 하나의 상태를 가진다. 리더는 로그 복제를 담당하며, 클라이언트 요청을 처리한다. 추종자는 리더의 지시에 따라 로그를 복제하는 수동적인 역할을 수행한다.

리더는 주기적으로 하트비트 메시지를 보내 추종자들에게 자신의 존재를 알린다. 각 추종자는 리더로부터 하트비트를 기다리는 특정 시간(선출 타임아웃, 일반적으로 150ms ~ 300ms)을 설정해 둔다. 이 타임아웃은 하트비트를 수신하면 초기화된다. 만약 정해진 타임아웃 시간 안에 리더로부터 하트비트를 받지 못하면, 추종자는 리더에게 문제가 발생했다고 판단하고 후보자 상태로 전환하여 새로운 리더 선출 과정을 시작한다. 리더 선출과 로그 복제의 구체적인 과정은 하위 섹션에서 자세히 설명된다.

2. 1. 합의 문제에 대한 래프트의 접근법

래프트는 선출된 리더(Leader)를 통해 합의를 달성한다. 래프트 클러스터에 속한 서버는 항상 리더, 추종자(Follower), 또는 리더 선출 과정에서의 후보자(Candidate) 중 하나의 상태를 가진다. 리더는 클러스터 내 다른 모든 서버(추종자)에게 로그 복제를 관리하는 전적인 책임을 진다. 즉, 리더는 다른 서버와 상의 없이 새로운 로그 항목의 배치나 데이터 흐름을 결정할 수 있다. 리더는 일반적으로 주기적인 하트비트 메시지를 추종자들에게 보내 자신의 존재를 알린다. 각 추종자는 리더로부터 하트비트를 기다리는 특정 타임아웃 시간(보통 150ms ~ 300ms)을 가지고 있으며, 하트비트를 받으면 이 타임아웃 시간이 초기화된다. 만약 추종자가 정해진 시간 안에 리더로부터 하트비트를 받지 못하면, 리더에게 문제가 발생했다고 판단하고 스스로 후보자 상태로 전환하여 새로운 리더 선출 과정을 시작한다.

이처럼 래프트는 복잡한 합의 문제를 리더 선출(Leader Election)과 로그 복제(Log Replication)라는 두 개의 비교적 독립적인 하위 문제로 나누어 접근한다. 리더가 실패하거나 네트워크 연결이 끊어지면, 남아있는 서버들이 새로운 리더를 선출하고(리더 선출), 선출된 리더는 클라이언트 요청을 받아 로그를 관리하며 이를 다른 서버들에게 복제한다(로그 복제).

추종자 서버에 문제가 발생하여 응답하지 못하는 경우, 다른 서버에서 보내는 로그 추가 요청(AppendEntries)이나 투표 요청(Vote)은 실패하게 된다. 이 경우, 요청을 보낸 서버는 해당 추종자가 다시 응답할 때까지 요청을 계속 시도한다. 추종자가 재시작되면 보류 중이던 요청들이 완료되며, 만약 실패 전에 이미 처리된 요청이라면 재시작된 추종자는 이를 무시한다.

래프트 알고리즘은 다음과 같은 다양한 분산 시스템에서 활용되고 있다.

시스템설명
CockroachDB복제 계층에서 래프트를 사용한다.[19]
etcd고가용성 복제 로그를 관리하기 위해 래프트를 사용한다.[20]
MongoDB복제 세트 내에서 래프트의 변형된 버전을 사용한다.
Splunk엔터프라이즈 버전의 Search Head Cluster(SHC)에서 래프트를 사용한다.[21]
TiDB스토리지 엔진인 TiKV에서 래프트를 사용한다.[22]
YugabyteDBDocDB 복제 과정에서 래프트를 사용한다.[23]


2. 1. 1. 리더 선출

래프트는 선출된 ''리더''를 통해 합의를 달성한다. 래프트 클러스터의 서버는 ''리더(Leader)'', ''추종자(Follower)'' 중 하나의 상태를 가지며, 리더 선출 중에는 ''후보자(Candidate)'' 상태가 될 수 있다. 리더는 추종자들에게 로그를 복제하는 역할을 담당하며, 주기적으로 하트비트 메시지를 보내 자신의 존재를 알린다. 각 추종자는 리더로부터 하트비트를 기다리는 타임아웃(일반적으로 150ms에서 300ms 사이)을 설정해 둔다. 이 타임아웃은 하트비트를 수신할 때마다 초기화된다. 만약 설정된 타임아웃 시간 안에 하트비트를 받지 못하면, 해당 추종자는 리더가 응답하지 않는다고 판단하고 자신의 상태를 ''후보자''로 변경한 뒤 새로운 리더 선출 절차를 시작한다.

기존 리더에게 문제가 발생하거나 알고리즘이 처음 시작될 때 새로운 리더를 선출해야 한다. 이 경우, 클러스터 내에서 새로운 '''term'''이 시작된다. term은 새로운 리더 선출이 필요한 가변적인 기간을 의미하며, 각 term은 리더 선출과 함께 시작된다. 만약 선출이 성공적으로 완료되어 단일 리더가 결정되면, 해당 term은 새로운 리더의 주도 하에 정상적인 작업을 수행하며 계속된다. 하지만 선출이 실패하면 새로운 term이 시작되고 다시 리더 선출 절차를 밟는다.

리더 선출은 ''후보자'' 상태가 된 서버에 의해 시작된다. 후보자는 먼저 term 번호를 증가시키고 새로운 선출 term을 시작하며, 자신에게 먼저 투표한다. 그리고 다른 모든 서버에게 자신에게 투표해달라는 요청 메시지를 보낸다. 각 서버는 하나의 term 동안 단 한 번만 투표할 수 있으며, 먼저 요청한 후보자에게 투표하는 선입선출 방식을 따른다. 만약 후보자가 과반수의 투표를 얻으면 새로운 리더로 선출된다. 투표 과정 중, 만약 후보자가 다른 서버로부터 자신보다 높은 term 번호를 가진 메시지를 받게 되면, 자신의 선출 시도가 무효화되었음을 인지하고 다시 ''추종자'' 상태로 돌아가 더 높은 term의 리더 또는 후보자를 인정한다. 만약 과반수 득표에 실패하거나 분할 투표가 발생하는 등 리더가 선출되지 못하면, 현재 term은 끝나고 새로운 term과 함께 다시 선출 과정이 시작된다.

래프트는 여러 후보자가 동시에 나와 표가 분산되는 분할 투표 문제를 효과적으로 해결하기 위해 무작위 선출 타임아웃 메커니즘을 사용한다. 각 서버의 타임아웃 시간을 무작위로 설정함으로써, 서버들이 동시에 ''후보자'' 상태로 전환될 확률을 낮춘다. 이를 통해 특정 서버 하나가 다른 서버들보다 먼저 타임아웃되어 선출 과정을 시작하고, 과반수 투표를 얻어 리더가 될 가능성을 높인다. 이렇게 선출된 리더는 다른 서버들이 타임아웃되어 ''후보자''가 되기 전에 빠르게 하트비트 메시지를 전송하여 클러스터의 정상 운영을 빠르게 재개한다.

2. 1. 2. 로그 복제

리더는 로그 복제를 담당한다. 리더는 클라이언트의 요청을 수락하는데, 각 요청은 클러스터 내의 복제된 상태 머신에 의해 실행될 명령어로 구성된다. 각 요청은 리더의 로그에 새로운 엔트리(entry)로 추가된 후, AppendEntries 메시지를 통해 각 추종자(follower)에게 전달된다. 만약 특정 추종자를 이용할 수 없는 경우, 리더는 해당 로그 엔트리가 모든 추종자에게 최종적으로 저장될 때까지 AppendEntries 메시지 전달을 무한정 재시도한다.

리더가 과반수의 추종자로부터 엔트리가 성공적으로 복제되었음을 확인하면, 리더는 해당 엔트리를 자신의 로컬 상태 머신에 적용(apply)하고, 이 요청은 커밋(committed)된 것으로 간주된다. 이 과정에서 리더 로그 안의 해당 엔트리 이전 모든 엔트리들도 함께 커밋된다. 추종자는 로그 엔트리가 커밋되었음을 알게 되면, 해당 엔트리를 자신의 로컬 상태 머신에 적용한다. 이를 통해 클러스터 내 모든 서버 간 로그의 일관성이 보장되며, 로그 일치(Log Matching) 안전성 규칙이 준수된다.

리더가 충돌하는 경우, 이전 리더의 일부 로그가 클러스터 전체에 완전히 복제되지 않아 로그가 일관되지 않은 상태가 될 수 있다. 새로운 리더는 추종자들이 자신의 로그를 복제하도록 강제하여 이러한 불일치를 처리한다. 이를 위해 새 리더는 각 추종자의 로그와 자신의 로그를 비교하여, 두 로그가 일치하는 마지막 엔트리를 찾는다. 그 다음, 해당 지점 이후의 모든 엔트리를 추종자의 로그에서 삭제하고 자신의 로그에 있는 엔트리로 대체한다. 이러한 메커니즘은 장애가 발생한 클러스터에서 로그 일관성을 복원하는 역할을 한다.

2. 2. 안전성

래프트는 분산 시스템 환경에서 데이터의 일관성과 시스템의 안정성을 보장하기 위해 여러 메커니즘을 사용한다.

리더는 클라이언트의 요청을 받아 자신의 로그에 새로운 항목(entry)으로 추가한다. 이후 이 항목을 각 추종자에게 ''AppendEntries''(로그 추가) 메시지를 통해 전달한다. 만약 특정 추종자에게 전달되지 않으면, 리더는 해당 항목이 모든 추종자에게 성공적으로 저장될 때까지 메시지 전송을 계속 시도한다.

리더는 과반수의 추종자에게 해당 로그 항목이 복제된 것을 확인하면, 그 항목을 자신의 로컬 상태 기계에 적용하고 해당 요청을 '커밋(committed)'된 것으로 간주한다. 이 시점에 해당 항목 이전의 모든 로그 항목들도 함께 커밋된다. 추종자들은 리더로부터 커밋된 로그 항목 정보를 받으면, 자신의 로컬 상태 기계에 해당 항목을 적용한다. 이 과정을 통해 클러스터 내 모든 서버 간의 로그 일관성이 유지되며, 이는 래프트의 중요한 안전성 속성 중 하나인 로그 일치(Log Matching)를 보장하는 기반이 된다.

만약 리더에게 장애가 발생하면, 이전 리더의 로그가 클러스터 전체에 완전히 복제되지 않아 로그가 일시적으로 불일치 상태가 될 수 있다. 새로운 리더가 선출되면, 이 새 리더는 로그 불일치 문제를 해결하는 역할을 한다. 새 리더는 자신의 로그와 각 추종자의 로그를 비교하여 마지막으로 합의된 지점을 찾는다. 이후, 추종자의 로그에서 해당 지점 이후의 모든 항목을 삭제하고 자신의 로그 항목으로 교체하도록 지시한다. 이 메커니즘을 통해 장애 상황에서도 클러스터 전체의 로그 일관성을 복원할 수 있다.

2. 2. 1. 안전성 규칙

래프트는 다음과 같은 안전 속성을 보장한다.

  • '''선거 안전성(Election Safety):''' 주어진 임기(term) 동안 최대 한 명의 리더만 선출될 수 있다.
  • '''리더 추가 전용(Leader Append-Only):''' 리더는 로그에 새로운 항목만 추가할 수 있으며, 기존 항목을 덮어쓰거나 삭제할 수 없다.
  • '''로그 일치(Log Matching):''' 두 개의 로그가 동일한 색인(index)과 임기(term)를 가진 항목을 포함하는 경우, 해당 색인까지의 모든 항목에서 두 로그는 동일하다.
  • '''리더 완전성(Leader Completeness):''' 어떤 로그 항목이 특정 임기 동안 커밋되었다면, 그 항목은 해당 임기 이후의 모든 리더 로그에 존재해야 한다.
  • '''상태 기계 안전성(State Machine Safety):''' 특정 서버가 로그 항목을 자신의 상태 기계에 적용했다면, 다른 어떤 서버도 동일한 색인에 다른 항목을 적용할 수 없다.


앞의 네 가지 규칙은 래프트 알고리즘의 기본적인 메커니즘을 통해 보장된다. 상태 기계 안전성은 선거 과정에 대한 제한, 즉 후보자의 로그가 커밋된 모든 항목을 포함하고 있지 않으면 선출될 수 없다는 규칙을 통해 보장된다. 선출되기 위해 후보자는 클러스터의 과반수와 연락해야 하며, 이는 커밋된 모든 항목이 후보자가 연락한 서버 중 적어도 하나에는 존재해야 함을 의미한다.

래프트는 로그 내의 마지막 항목의 색인 번호와 임기(term)를 비교하여 두 로그 중 어떤 것이 더 최신인지 판단한다. 만약 로그의 마지막 항목이 다른 임기를 가지고 있다면, 더 나중의 임기를 가진 로그를 최신으로 판단한다. 만약 로그가 같은 임기로 끝난다면, 더 긴 로그가 최신으로 판단된다.

리더 선출 과정에서 유권자(voter)에게 보내는 후보자의 요청에는 후보자 로그에 대한 정보가 포함된다. 만약 유권자가 가진 로그가 후보자의 로그보다 최신이라면, 유권자는 그 후보자에 대한 투표를 거부한다. 이러한 검증 과정은 상태 기계 안전성 규칙을 보장하는 데 기여한다.

2. 2. 2. 상태 머신 안전성 보장

래프트(Raft)는 상태 머신의 안전성을 보장하기 위해 리더 선출 과정에서 다음과 같은 규칙을 적용한다.
후보자 선출 제한: 후보자는 자신의 로그에 커밋된 모든 항목(entry)을 포함하고 있어야만 선출될 수 있다. 이는 후보자가 선출되기 위해 클러스터 내 과반수의 서버와 통신해야 하며, 커밋된 모든 항목은 후보자가 통신한 서버 중 적어도 하나에는 반드시 존재하기 때문에 가능한 규칙이다.
로그 최신성 판단: 래프트는 두 서버의 로그 중 어떤 것이 더 최신인지 판단하기 위해 로그의 마지막 항목을 비교한다.

  • 만약 마지막 항목의 term 번호가 서로 다르면, 더 높은 term 번호를 가진 로그가 최신 로그로 간주된다.
  • 만약 마지막 항목의 term 번호가 같다면, 더 긴 로그가 최신 로그로 간주된다.

투표 규칙: 리더 후보자는 다른 서버(유권자)에게 투표를 요청할 때 자신의 로그 정보를 함께 보낸다. 만약 유권자의 로그가 후보자의 로그보다 더 최신이라고 판단되면, 유권자는 해당 후보자에게 투표하는 것을 거부한다.

이러한 로그 비교 및 투표 제한 규칙을 통해, 항상 최신의 커밋된 로그를 가진 후보자만이 리더로 선출될 수 있도록 보장하며, 이는 결과적으로 상태 머신의 안전성을 유지하는 핵심적인 메커니즘으로 작동한다.

2. 2. 3. 추종자 충돌

추종자가 충돌하면 다른 서버에서 보낸 ''AppendEntries''(로그 추가) 및 ''vote''(투표) 요청은 실패한다. 이러한 실패는 서버들이 다운된 추종자에게 무한정 재시도하는 것으로 해결된다. 추종자가 다시 시작되면, 보류 중이던 요청은 완료된다. 만약 요청이 실패 전에 이미 수신되었다면, 재시작된 추종자는 이를 무시한다.

2. 2. 4. 시점과 가용성

래프트에서 시점(Timing)은 일정 시간 동안 안정적인 리더를 선출하고 유지하는 데 매우 중요하다. 이를 통해 클러스터의 완벽한 가용성을 확보할 수 있다. 알고리즘의 안전성은 다음과 같은 타이밍 요구 사항을 준수함으로써 보장된다.

'''브로드캐스트 시간 << 선출 타임아웃 << 평균 고장 간격(MTBF)'''

  • '''브로드캐스트 시간''' (Broadcast Time): 한 서버가 클러스터 내 모든 서버에 요청을 보내고 응답을 받기까지 걸리는 평균 시간이다. 이는 사용된 인프라에 따라 달라진다.
  • '''선출 타임아웃''' (Election Timeout): 리더 선출 과정에서 사용되는 시간 제한이다. 추종자(Follower)가 리더로부터 일정 시간(타임아웃) 동안 하트비트를 받지 못하면 후보자(Candidate) 상태로 변경하고 새로운 리더 선출을 시작하는데, 이 타임아웃 시간이 선출 타임아웃에 해당한다. 이 값은 프로그래머가 설정해야 한다.
  • '''평균 고장 간격''' (MTBF, Mean Time Between Failures): 서버가 고장 나기까지 걸리는 평균 시간이다. 이 역시 인프라 환경에 따라 달라진다.


일반적으로 브로드캐스트 시간은 0.5ms에서 20ms 사이이며, 선출 타임아웃은 10ms에서 500ms 사이의 값으로 설정한다. 단일 서버의 평균 고장 간격은 보통 몇 주 또는 몇 달 단위로 길기 때문에, 위 조건을 만족하면 클러스터는 안정적으로 운영될 수 있다.

3. 래프트의 프로덕션 활용


  • CockroachDB는 복제 계층에서 Raft를 사용한다.[2][19]
  • Etcd는 Raft를 사용하여 높은 가용성을 보장하는 복제된 로그를 관리한다.[3][20]
  • Hazelcast는 Raft를 사용하여 분산 데이터 구조를 위한 강력한 일관성 계층인 CP 서브시스템을 제공한다.[4]
  • MongoDB는 복제 집합(Replica Set)에서 Raft의 변형을 사용한다.
  • Neo4j는 일관성과 안전성을 보장하기 위해 Raft를 사용한다.[5]
  • RabbitMQ는 Raft를 사용하여 지속적이고 복제된 FIFO 큐를 구현한다.[6]
  • ScyllaDB는 메타데이터(스키마 및 토폴로지 변경)에 Raft를 사용한다.[7]
  • Splunk Enterprise는 검색 헤드 클러스터(SHC)에서 Raft를 사용한다.[8][21]
  • TiDB는 스토리지 엔진 TiKV와 함께 Raft를 사용한다.[9][22]
  • YugabyteDB는 DocDB 복제에서 Raft를 사용한다.[10][23]
  • ClickHouse는 자체 ZooKeeper와 유사한 서비스를 구현하기 위해 Raft를 사용한다.[11]
  • Redpanda는 데이터 복제를 위해 Raft 합의 알고리즘을 사용한다.[12]
  • Apache Kafka Raft (KRaft)는 메타데이터 관리에 Raft를 사용한다.[13]
  • NATS Messaging은 Jetstream 클러스터 관리 및 데이터 복제를 위해 Raft 합의 알고리즘을 사용한다.[14]
  • Camunda는 데이터 복제를 위해 Raft 합의 알고리즘을 사용한다.[15]

참조

[1] 웹사이트 Why the "Raft" name? https://groups.googl[...]
[2] 웹사이트 Replication Layer {{!}} CockroachDB Docs https://www.cockroac[...] 2022-06-21
[3] 웹사이트 Raft README https://github.com/e[...] 2022-08-25
[4] 웹사이트 CP Subsystem https://docs.hazelca[...] 2022-12-24
[5] 웹사이트 Leadership, routing and load balancing - Operations Manual https://neo4j.com/do[...] 2022-11-30
[6] 웹사이트 Quorum Queues https://www.rabbitmq[...] 2022-12-14
[7] 웹사이트 ScyllaDB’s Path to Strong Consistency: A New Milestone https://www.scylladb[...]
[8] 웹사이트 Handle Raft issues https://docs.splunk.[...] 2022-08-24
[9] 웹사이트 Raft and High Availability https://en.pingcap.c[...] 2021-09-01
[10] 웹사이트 Replication {{!}} YugabyteDB Docs https://docs.yugabyt[...] 2022-08-19
[11] 웹사이트 ClickHouse Keeper https://clickhouse.c[...] 2023-04-26
[12] 웹사이트 Raft consensus algorithm https://docs.redpand[...]
[13] 웹사이트 KRaft Overview {{!}} Confluent Documentation https://docs.conflue[...] 2024-04-13
[14] 웹사이트 JetStream Clustering https://docs.nats.io[...]
[15] 웹사이트 Raft consensus and replication protocol https://docs.camunda[...]
[16] 웹사이트 In Search of an Understandable Consensus Algorithm https://raft.github.[...] 2022-10-13
[17] 웹사이트 Raft Consensus Algorithm https://raft.github.[...] 2022-10-13
[18] 웹사이트 Why the "Raft" name? https://groups.googl[...] 2022-10-13
[19] 웹사이트 Replication Layer {{!}} CockroachDB Docs https://www.cockroac[...] 2022-06-21
[20] 웹사이트 Raft README https://github.com/e[...] 2022-08-25
[21] 웹사이트 Handle Raft issues https://docs.splunk.[...] 2022-08-24
[22] 웹사이트 Raft and High Availability https://en.pingcap.c[...] 2021-09-01
[23] 웹사이트 Replication {{!}} YugabyteDB Docs https://docs.yugabyt[...] 2022-08-19


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com