1. MySQL Fabric은
무엇입니까?
A :
MySQL Fabric은 서비스를 제공하는 MySQL 서버 군이 관리되는 프레임 워크입니다. 확장 할 수 있도록 설계되어 있기 때문에 시간이 지남에 따라
다른 서비스를 추가 할 수 있습니다. 현재 고 가용성 (MySQL 복제에 근거한)과 확장 (데이터 샤드)를 제공합니다.
MySQL Fabric은 MySQL
Fabric 노드 / 프로세스 (관리 기능을 수행)와 Fabric 대응 커넥터에서 실행됩니다. Fabric 대응 커넥터는 최적의 MySQL 서버에 쿼리와
트랜잭션을 직접 라우팅합니다. MySQL Fabric 노드 상태 스토어 (MySQL 데이터베이스)에는 각 노드의 상태 및 라우팅 정보가
포함되어 있습니다.
2. MySQL Fabric을
이용하면 특정 스토리지 엔진이 필요합니까?
A :
아니요. MySQL Fabric에서
관리되는 MySQL 서버는 계속 InnoDB를 사용할 수 있습니다. (미래에 NDB / MySQL Cluster도 지원 예정입니다)
3. MySQL Fabric의 고
가용성은 어떻게 실현됩니까?
A :
MySQL Fabric은 하나 이상의 HA 그룹 (각 HA 그룹은 하나 이상의 MySQL 서버 포함)를 관리합니다. 고 가용성을 실현하기 위해서는 HA 그룹에는 하나의 기본
MySQL 서버, 하나 이상의 보조 MySQL 서버를 포함합니다. 그룹 중의 기본은 MySQL 복제의 주인이고 기본에서 각 보조에 데이터를 복제합니다 (보조 복제 슬레이브
서버입니다).
기본적으로 MySQL Fabric 대응
커넥터는 기본에 쓰기를 라우팅하고 사용할 수있는 보조에서 읽기는로드 밸런싱으로합니다.
기본 장애 발생시 MySQL Fabric 보조
중에서 하나를 골라 주에 올립니다. (자동으로 MySQL 서버를 복제 마스터로 승격 MySQL Fabric 해당 커넥터는 라우팅 정보를
업데이트합니다).
4. MySQL 서버의 장애를
어떻게 감지 할 수 있습니까?
A :
MySQL Fabric 노드에 마스터의 상태를 체크하는 모니터 기능이 포함되어 있습니다. 또한 기본에 장애가 발생한 경우 Fabric 대응 커넥터는
MySQL Fabric에보고합니다. 관리자는 페일 오버 시작 전에 통지되어야 할 문제 수 (및 경과 시간)을 설정할 수
있습니다.
5. 기본 MySQL 서버
(마스터)가 실패하면 어떤 일이 일어 납니까?
A :
MySQL Fabric 노드는 보조에서 새로운 주를 선택합니다. 이 때 다음 두 작업을 수행합니다 :
- 보조를 복제 마스터로 승격시킵니다 (다른
실행중인 보조은 새로운 마스터 서버의 노예가됩니다)
- 라우팅 정보를 업데이트합니다.
결과로 Fabric 대응 커넥터는 장애가 발생한
주에 쿼리 나 트랜잭션의 전송을 중지하고 대신 새로운 주에 보냅니다.
6. 장애 조치 발생시 응용
프로그램 측의 대응이 필요하세요?
A : 그럴
필요 없습니다. 페일 오버 응용
프로그램에 투명합니다. Fabric
대응 커넥터는 새로운 서버 토폴로지를 기반으로 트랜잭션과 쿼리의 라우팅을 자동으로 시작합니다. 응용 프로그램은 기본 장애 발생시 새 차를 교체 이전에 오류가
발생한 트랜잭션 (페일 오버 중에 실행 오류가 발생한 트랜잭션)을 처리해야하지만, 이것은 일반적으로 MySQL의 오류 처리와 유사합니다
.
7. MySQL Fabric 준
동기 복제와 함께 작동 할 수 있습니까?
A : 현재의
버전에서는 MySQL Fabric은 비동기 복제를 이용하여 HA 그룹을 만듭니다. 준 동기 복제를 사용하려는 경우 MySQL Fabric 의해
복제 관계가 생성 된 후 사용자가 수동으로 설정할 수 있습니다.
8. 즉시 일관된 읽기가 필요한
경우 (최신 데이터를 취득 할 필요가있는 경우) 어떻게하면 좋습니까?
A : 기본
(마스터)에서 보조 (슬레이브)에 복제는 비동기위한 보조에서 읽을 최신 데이터를 얻을 수 보장 할 수 없습니다. 기본에서 읽기를 강제하기 위해 응용 프로그램은 읽기가 아니라
읽기 / 쓰기를 연결 모드 속성에서 설정 할 수 있습니다.
9. MySQL Fabric에서
어떻게 스케일링을 얻을 수 있습니까?
A : 수평
스케일링은 여러 MySQL 서버 또는 HA 그룹간에 테이블에서 데이터를 파티셔닝 (샤드)에 의해 제공됩니다. 이 경우 각 서버 또한 그룹은 특정 테이블 행의 서브 세트를
포함합니다.
사용자는 테이블의 컬럼을 샤드 키로 지정하고
샤드 분할 방법 (HASH 또는 RANGE)도 지정합니다. RANGE 기반 샤드를 사용하는 경우, 사용자는 RANGE와 샤드의 매핑을 지정해야합니다.
현재 샤드 키는
숫자이어야합니다.
데이터베이스에 액세스 할 때 응용 프로그램은
샤드 키를 지정합니다. Fabric
대응 커넥터는 지정된 샤드 키를 샤드 ID에 매핑 (MySQL Fabric 서버에서 검색되고 검색된 매핑 데이터는 커넥터에 캐시됩니다) 쿼리
또는 트랜잭션을 올바른 MySQL 서버로 라우팅합니다 .
HA 그룹 내에서 Fabric 대응 커넥터는
기본에 직접 쓸 수 있습니다. 또한
모든 사용 가능한 보조로 읽기 쿼리를 실행할 수 있습니다. (주에서 읽기 쿼리를 실행할 수도 있습니다)
10. 스케일링은 읽기와 쓰기
모두에 적용되어 있습니까?
A :
예. 더 HA 그룹이 추가 됨으로써
읽기 및 쓰기를 선형 적으로 확장 할 수 있습니다. 또한 HA 그룹에 보조 서버를 추가하여 읽지 독립 조정할 수 있습니다.
11. 모든 샤드에 필요한
테이블 데이터를 가지고있는 경우는 어떻게됩니까?
A : Global
Group이라는 특별한 그룹이 생성됩니다. 그 안에 글로벌 테이블을 유지합니다. 모든 HA 그룹에서 참조되는 데이터를 가진 테이블은 글로벌 테이블로 취급해야합니다. 글로벌 테이블은 모든 기록이 글로벌 그룹에 전송되는 모든 HA
그룹에 복제됩니다. 예를 들면,
employee 데이터베이스 (※)의 department 테이블 등입니다. department 테이블의 내용은 적기 때문에 모든 서버에 저장할 수 있습니다. 그 데이터는 샤드 된 employee 테이블의 모든 레코드에서
참조됩니다. ※ employee
데이터베이스에 대해서는 여기
를 참조하십시오
마찬가지로 스키마 변경은 글로벌 그룹에 전송
된 모든 HA 그룹에 복제됩니다.
12. MySQL Fabric는
경쟁과 교착 상태의 원인 있습니까?
A :
아니요. 하나의 트랜잭션은 하나의 샤드
(+ 글로벌 테이블)의 데이터에만 액세스 할 수 있습니다. 모든 쓰기 작업은 그 샤드 HA 그룹의 주 서버로 전송됩니다. 즉, 특정 행에 대한 모든 기록은 동일한 MySQL 서버에
의해 처리되기 때문에 InnoDB의 행 기반 잠금은 정상적으로 작동합니다.
13. 데이터 세트 또는
사용량이 증가 샤드가 크게 자란 경우 어떻게해야하나요?
A :
MySQL Fabric은 다음과 같은 기능을 제공합니다 :
- 샤드 이동 : 고성능 서버를 포함하는 새로운
HA 그룹에 샤드를 이동할 수 있습니다.
- 샤드 분할 : 기존 샤드를 두 나누고,
새로운 샤드를 새로운 HA 그룹에 저장할 수 있습니다. 장래 적으로는 샤드 분할은 다른 수준의 입도를 지원할 예정입니다.
14. MySQL Fabric을
사용하는 경우 추가의 대기 시간이 발생합니까?
A : 아니,
발생하지 않습니다. 라우팅 커넥터에서
처리되기 때문에, 프록시를 개입 같은 추가 "홉"을 필요로하지 않습니다. 이것은 MySQL Fabric가 프록시 프로세스를 사용하지 않는 주된 이유입니다. 두 번째 이유는 프록시가 병목 현상과 단일 장애 지점이 될
가능성이 있기 때문입니다.
15. 샤드를 다른 MySQL
서버로 이동시킨 경우 또는 여러 샤드에 분할시킨 경우 응용 프로그램의 변경이 필요하세요?
A : 그럴
필요 없습니다. 응용 프로그램은 샤드
키를 취급하지만, 샤드 이동 및 분할하여 샤드 키는 변하지 않기 때문입니다.
샤드 키는 단순히 하나 이상의 테이블에서
컬럼의 값입니다. 행 데이터는 하나의
샤드에서 다른 샤드이나 서버로 이동해도 샤드 키는 바뀌지 않습니다. 샤드 키는 샤드 ID에 매핑됩니다. (HASH 또는 RANGE 기반의 매핑을 이용) 샤드 ID는 샤드 자체를 나타냅니다.
예를 들어 기존 샤드가 둘로 된 경우 해당
행의 일부가 하나 샤드 샤드 ID에 매핑되고, 나머지는 다른 샤드 ID에 매핑됩니다. 이 분할에서 행 샤드 키는 변경되지
않습니다.
매우 중요한 것은 샤드 ID 대신 샤드 키가
응용 프로그램에 알려진 것입니다. 따라서, 서버 군 토폴로지의 변경은 응용 프로그램에 대해 완전히 투명합니다.
16. MySQL Fabric
노드 자체 결함 허용입니까? MySQL
Fabric 노드를 사용할 수없는 경우 어떻게됩니까?
A : 현재
MySQL Fabric 노드는 단일 인스턴스뿐입니다. 프로세스 장애 발생시 해당 시스템 또는 다른 시스템에서 다시 시작할 수 있습니다. 상태 및 라우팅 정보는 기존의 스테이트 스토어 (MySQL
데이터베이스) 또는 복제 된 상태 저장소 복사본에서 읽을 수 있습니다.
MySQL Fabric 노드를 사용하지 않는
경우에도 Fabric 대응 커넥터는 캐시 된 라우팅 데이터의 복사를 기반으로 쿼리 및 트랜잭션을 올바른 서버로 라우팅 할 수
있습니다. 단, MySQL Fabric
노드가 회복하기 전에 기본에 장애가 발생한 경우 자동으로 페일 오버 할 수 없습니다. 따라서 MySQL Fabric 프로세스를 신속하게 복구하는
것이 중요합니다.
17. 어떤 커넥터가 MySQL
Fabric에 대응하고 있습니까?
A : 현재
PHP, Python, Java는 MySQL Fabric에 대응하고 있습니다. 또한 O / R 매퍼 Hibernate와 Doctrine에도
대응하고 있습니다. 앞으로도 새로운
커넥터를 추가 할 예정입니다.
18. ACID 준수
트랜잭션입니까?
A :
예. 각 트랜잭션은 하나의 MySQL
서버에서 처리되기 때문에 InnoDB 스토리지 엔진의 모든 ACID 동작에 대응하고 있습니다.
19. 크로스 샤드 통합
(UNION)과 결합 (JOIN) 수 있습니까?
A : 아니,
지금은 할 수 없습니다. 모든 쿼리가
액세스 할 수있는 데이터는 싱글 샤드의 데이터 + 글로벌 테이블의 데이터에 한정되어 있습니다. 멀티 샤드에서 데이터를 읽는 경우 응용 프로그램에서 데이터를
검색하고 통합해야합니다.
20. 응용 프로그램에 대한
쿼리 및 트랜잭션 라우팅은 투명합니까?
A : 거의
투명합니다.
HA의 경우 응용 프로그램은 작업이 읽기
전용인지 또는 쓰기도 포함하는지 (또는 항상 최신 데이터를 가져올 것인가)를 지정해야합니다.
샤드의 경우 응용 프로그램은 샤드 키 (하나
이상의 테이블 열)을 지정해야합니다. 그러나, 이것은 MySQL 서버 토폴로지에 의존하지 않습니다. 또한 데이터가 서버간에 이동 된 경우에도 영향을받지
않습니다.
21. MySQL Fabric을
사용하는 경우 서버는 몇 개 필요합니까?
A : 개발하는
경우 MySQL Fabric 노드 및 관리되는 모든 MySQL 서버가 하나의 시스템으로 구축 할 수 있습니다.
배치 할 경우, 최소의 HA 구성은 3 대
이상의 컴퓨터가 필요합니다.
- 2 개는 MySQL 서버
- 하나는 MySQL Fabric 프로세스
(응용 프로그램 서버로도 사용 가능)
22. 각 MySQL 서버에서
에이전트를 실행해야합니까?
A : 그럴
필요 없습니다. MySQL Fabric
노드 만 추가 프로세스이며, 관리되는 MySQL 서버 중 하나와 동일한 위치에 배치 할 필요가 없습니다.
23. MySQL Fabric과
MySQL Cluster의 차이점은 무엇입니까?
A : MySQL
Cluster 는 성숙한 입증 된 솔루션입니다. 매우 높은 수준의 가용성과 확장 (읽기와 쓰기 모두)를 제공합니다. MySQL Fabric보다 낫다 주요 기능 중 일부는 다음과
같습니다 :
- 동기화 복제
- 빠른 (자동화 된) 페일 오버 (고 가용성을
제공)
- 투명 샤드
- 크로스 샤드 결합 및 외부 키
- 인 메모리 실시간 성능
한편, MySQL Fabric은 많은
애플리케이션에 적합하다 InnoDB 스토리지 엔진을 계속 사용할 수 있습니다.
24. MySQL Fabric을
이용할 때의 라이센스는?
A :
MySQL Fabric은 GPL v2 오픈 소스 라이센스에 따라 사용할 수 있습니다. 또한 MySQL Enterprise Edition 또는
MySQL Cluster Carrier Grade Edition의 일부로 상용 라이센스의 이용도 할 수 있습니다.
