MySQL Fabric은 MySQL 서버 그룹을 관리하기 위한 확장 가능한 프레임워크입니다. 즉, 사용자는 GPL 사양에 따라 이 소프트웨어를 자유롭게 사용하고 수정할 수 있습니다. mysql 패브릭은 모든 관리 요청을 처리하는 프로세스입니다. HA 기능을 사용할 때 이 프로세스가 마스터 서버 모니터링을 담당하도록 하고, 장애 발생 시 슬레이브 서버를 마스터 서버로 업그레이드할 수 있습니다.
이 튜토리얼의 운영 환경: windows7 시스템, mysql8 버전, Dell G3 컴퓨터.
MySQL Fabric 소개
MySQL Fabric은 MySQL 서버 팜 관리를 위한 확장 가능한 프레임워크입니다.
MySQL Fabric은 여러 개의 MySQL 데이터베이스를 "구성"할 수 있습니다. 애플리케이션 시스템은 수 TB 이상의 테이블을 여러 데이터베이스, 즉 Data Shard에 분산시킵니다. 동일한 샤드에는 여러 데이터베이스가 포함될 수 있으며 Fabric은 자동으로 적합한 데이터베이스를 마스터 데이터베이스로 선택하고 나머지 데이터베이스는 마스터-슬레이브 복제를 위해 슬레이브 데이터베이스로 구성됩니다. 마스터 데이터베이스에 장애가 발생하면 슬레이브 데이터베이스 중 하나가 선택되어 마스터 데이터베이스로 승격됩니다. 이후 다른 슬레이브 데이터베이스가 새 기본 데이터베이스로 전송되어 새 데이터를 복사합니다. 참고: 여기에 언급된 "자동"은 사용자가 구성을 수동으로 변경할 필요 없이 MySQL Fabric이 백그라운드에서 완료한다는 의미입니다. 가장 중요한 점은 MySQL Fabric이 GPL 오픈 소스 소프트웨어라는 점입니다. 즉, 이 소프트웨어를 GPL 사양에 따라 자유롭게 사용하고 수정할 수 있다는 의미입니다.
Fabric 프레임워크는 데이터 샤딩을 사용하여 고가용성(고가용성)과 수평 확장(샤딩)이라는 두 가지 기능을 구현합니다. 이 두 기능은 단독으로 또는 조합하여 사용할 수 있습니다.
두 기능 모두 다음 두 가지 수준을 기반으로 구현됩니다.
mysql 패브릭은 모든 관리 요청을 처리하는 프로세스입니다. HA 기능을 사용하는 경우 이 프로세스에서 마스터 서버를 모니터링하고 장애 발생 시 장애 조치를 시작하여 슬레이브 서버를 마스터 서버로 업그레이드하도록 할 수도 있습니다. MySQL Fabric 인식 커넥터는 MySQL Fabric에서 얻은 라우팅 정보를 캐시에 저장한 다음 이 정보를 사용하여 올바른 MySQL 서버에 트랜잭션이나 쿼리를 보냅니다.
고가용성
HA 그룹은 언제든지 두 개 이상의 MySQL 서버로 구성되며, 한 서버는 마스터 서버(MySQL 복제 기능의 마스터 서버) 역할을 하고 다른 서버는 슬레이브 서버(MySQL) 역할을 합니다. 복제 기능) 기능적 슬레이브 서버). HA 그룹의 역할은 그룹에 저장된 데이터에 항상 접근할 수 있도록 하는 것입니다. MySQL의 복제 기능은 복제를 통해 데이터 보안을 보장하며, MySQL Fabric의 고가용성 솔루션은 이를 기반으로 두 가지 필수 추가 요소를 제공합니다.
오류 감지 및 업그레이드 - MySQL Fabric은 HA 그룹의 마스터 서버를 모니터링하고 슬레이브를 선택하여 이를 상위 서버로 승격시킵니다. 마스터 실패 시 마스터 데이터베이스 요청 라우팅 - 쓰기 요청을 마스터로 라우팅하고 슬레이브 간에 읽기 요청의 로드 밸런싱은 장애 조치 중에 토폴로지가 변경되는 경우에도 애플리케이션에 투명합니다. MySQL 서버(또는 HA 그룹)의 용량 또는 쓰기 성능 제한에 도달하면 MySQL Fabric은 여러 MySQL 서버로 확장할 수 있습니다. 데이터는 데이터베이스 서버 확장을 지원하기 위해 서버 "그룹" 내에서 분할됩니다. 그룹은 하나의 MySQL 서버만 포함할 수도 있고 HA 그룹일 수도 있습니다. 관리자는 샤딩 키로 사용할 테이블 열을 지정하고, 추가 샤딩이 필요한 경우 이러한 키를 올바른 샤드에 매핑할지 여부를 지정하여 이러한 서버 간에 데이터를 샤딩하는 방법을 정의합니다. 기존 샤드를 추가로 재할당할 수도 있습니다.
MySQL Fabric이 해결해야 할 문제
증가하는 애플리케이션 복잡성 문제를 해결하기 위해 누군가가 프록시 (프록시)를 추가하거나 애플리케이션과 데이터베이스 서버 간의 스위치가 됩니다. 애플리케이션에서 데이터베이스에 대한 모든 명령은 먼저 프록시로 전송됩니다. , 그런 다음 프록시가 로 전송할 데이터베이스를 결정합니다. 아래 그림은 이 계획의 개략도이다. 이를 통해 애플리케이션의 유지 관리가 어려운 문제를 해결할 수 있지만, 애플리케이션 수가 증가하거나 데이터베이스 조각화가 증가하거나 시스템 압력이 증가하면 이 스위치는 용량 및 성능 병목 현상이 발생하게 됩니다(다운될 경우). , 애플리케이션은 데이터베이스를 찾을 수 없으며 모든 데이터베이스 명령은 두 번(먼저 스위치로, 그 다음 데이터베이스로) 전달되어야 합니다. 각 쿼리 는 추가 로드를 생성합니다.
MySQL Fabric의 아키텍처
MySQL Fabric은 다른 접근 방식을 채택했으며 해당 아키텍처는 아래 그림에 나와 있습니다. 주요 기능은 스위치를 각 애플리케이션 측의 커넥터에 병합하여 단일 스위치의 단일 실패 지점과 성능 병목 현상을 해결하는 것입니다.
MySQL 패브릭은 세 부분으로 구성됩니다.
1. MySQL 패브릭 관리 노드:
은 전체 아키텍처의 핵심인 Python 스크립트입니다.
Fabric이 초기화되면(mysqlfabric Manage setup 명령 실행) MySQL 데이터베이스(일반적으로 fabric이라는 데이터베이스)에서 스키마를 열어 어떤 서버 그룹으로 구성되어 있는지와 같은 Server Farm 구성 관련 정보를 저장합니다. 각 서버 그룹의 마스터 및 슬레이브 서버인 데이터베이스 등
구성을 설정할 때 MySQL Fabric 노드는 서버 팜의 각 데이터베이스에 대해 마스터-슬레이브 복제를 설정하는 명령을 실행합니다(위 그림의 빨간색 선).
정상 작동 중에 각 그룹의 마스터 서버에 정기적으로 ping을 실행하여 마스터 데이터베이스가 정상적으로 실행되지 않는 것으로 확인되면 장애 조치 프로그램을 시작하고 서버 팜의 슬레이브 데이터베이스에서 적합한 승격 서버를 찾습니다. 마스터 서버가 됩니다. 다른 슬레이브 데이터베이스는 새 마스터 데이터베이스로 전환하여 데이터를 계속 복제합니다.
2. 데이터베이스 서버 팜
이것은 전체 아키텍처에서 작동하는 엔진이지만 MySQL Fabric은 대규모 데이터베이스(TB)를 지원하기 위해 여러 데이터베이스를 사용합니다. 수준 이상) 및 고가용성 데이터베이스 요구 사항. 이러한 데이터베이스는 여러 고가용성 그룹(HA 그룹)으로 나뉘며, 각 그룹에는 둘 이상의 데이터베이스 서버가 포함됩니다. 위 그림에서 아래쪽 몇 개의 회색 및 연한 파란색 사각형은 고가용성 그룹을 나타냅니다. 고가용성 그룹에 여러 데이터베이스가 있는 경우 MySQL Fabric은 하나를 마스터 데이터베이스(Master)로 승격하기 위해 선택(mysqlfabric group Promotion 명령 사용)하고 나머지 데이터베이스는 슬레이브 데이터베이스(Slave)가 됩니다. 마스터 데이터베이스의 변경 사항을 복사하고 동일한 고가용성 그룹 내에서 마스터-슬레이브 복제를 설정합니다. 앞으로 Fabric은 이 기본 데이터베이스에 주기적으로 액세스할 것입니다. 기본 데이터가 다운되면 Fabric은 고가용성 그룹에서 하나를 선택하여 기본 데이터베이스로 승격하고 다른 데이터베이스는 이 새로운 기본 데이터베이스를 사용하여 복제를 계속합니다.
응용 시스템이 실행되면 각 SQL 명령이 커넥터를 통해 데이터베이스로 전송됩니다. MySQL Fabric에 장착된 커넥터는 최신 버전의 커넥터가 데이터베이스 서버 팜을 처리할 수 있는 더 많은 기능을 갖춘 패브릭 인식 커넥터라는 점을 제외하면 일반적인 독립형 MySQL 데이터베이스와 동일합니다. 이를 통해 데이터베이스 연결 시 XML-RPC 프로토콜을 사용하여 MySQL Fabric의 관리 노드에서 서버 팜의 구성을 확인할 수 있으며, 이후 Fabric의 지시에 따라 해당 연결에 따른 쿼리를 해당 데이터베이스로 보낼 수 있습니다. .
이런 방식으로 일반적인 데이터베이스 샤드 솔루션에서 성능 병목 현상을 일으킬 수 있는 프록시를 커넥터에 배치하여 이 문제를 해결합니다. 현재 MySQL Fabric에서 지원하는 기술에는 java, python 및 PHP가 포함됩니다. 즉, Connector/J, Connector/Python 및 Connector/PHP는 모두 Fabric을 인식합니다.
Java를 예로 들어 보겠습니다. JDBC 드라이버는 Connector/J 5.1.30 이상이어야 합니다. Fabric의 Java 프로그램은 데이터베이스 연결 개체를 설정할 때를 제외하면 독립 실행형 MySQL을 쿼리하는 일반 Java 프로그램과 유사합니다. 데이터베이스 연결 URL은 데이터베이스를 가리키는 것이 아니라 대신 MySQL Fabric 관리 노드를 가리킵니다(서버의 IP 및 포트는 일반적으로 32274입니다).
조회한 테이블이 전역 테이블(테이블 샤드 없음) 또는 DDL(테이블 생성 또는 테이블 구조 변경 등)인 경우 연결 개체 설정 시 'fabricServerGroup=" 매개변수를 추가해야 하며, 그런 다음 이 연결 개체를 통해 전달된 SQL 명령은 글로벌 그룹의 메인 데이터베이스로 전송된 후 다른 고가용성 그룹(샤드)으로 복사됩니다.
SQL 명령으로 동작할 테이블이 있는 경우 파티션된 테이블(샤드 테이블)인 경우 연결이 설정됩니다. 매개변수에 ''fabricShardTable=" 매개변수를 추가하면 이 연결 개체를 통해 실행된 SQL 명령이 각 파티션의 고가용성 그룹으로 전송됩니다. (샤드) MySQL Fabric에서 설정한 샤드 원칙에 따릅니다.
이런 방식으로 애플리케이션 프로그램이 이러한 샤드 테이블 아래에 SQL 명령어를 발행할 때 SQL로 보낼 데이터베이스를 결정할 필요가 없습니다. MySQL이 찾은 서버를 확인하는 것은 전적으로 커넥터의 몫입니다. 데이터베이스 연결을 설정할 때 Fabric은 팜의 구성 정보(어떤 데이터베이스가 어떤 샤드 그룹에 속하는지, 각 샤드 테이블의 분할 원리 등)에 따라 결정됩니다. 그리고 이 구성은 기본 연결이 설정된 후 커넥터가 있는 애플리케이션 측에 캐시됩니다.
이렇게 하면 SQL 명령이 실행될 때마다 MySQL Fabric 관리 노드에 반복적으로 쿼리할 필요가 없으며 애플리케이션 측에 의존하는 샤딩 구성이 올바른 데이터베이스로 직접 전송됩니다. 테이블 분할로 인해 애플리케이션의 효율성은 어떤 식으로든 감소하지 않습니다.
【관련 추천: mysql 비디오 튜토리얼】
위 내용은 mysql 패브릭이 뭔가요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!