# 가용 영역 장애 시 TiDB 무중단 서비스 ## 개요 이 실습에서는 TiDB 클러스터가 세 개의 가용 영역에 걸쳐 배포되며, 각각은 서브넷에 대응됩니다. 서브넷 1에서 네트워크 차단을 시뮬레이션합니다. 이는 클러스터에서 하나의 TiDB 서버, 하나의 TiKV 서버, 그리고 하나의 PD 서버의 연결을 끊습니다. 인프라 장애는 데이터베이스 클라이언트가 나머지 TiDB 서버 인스턴스에 자동으로 연결되므로 서버 측 페일오버가 필요하지 않습니다. ![80%](https://lab-static.pingcap.com/quick-demo/demo_001_en.png) ### 소요 시간 + 이 실습을 완료하는 데 약 60분이 소요됩니다. ### 과제 + TiDB 클러스터 상태 및 토폴로지를 검토합니다. + 전체 가용 영역에 대한 네트워크 통신을 차단합니다. + 전체 가용 영역에 액세스할 수 없는 상황에서도 TiDB 클러스터가 기능을 유지할 수 있음을 관찰하고 확인합니다. > [!TIP] > 실습 환경을 시작하려면 **시작**을 클릭하세요. > 환경이 준비되면 하단 도구 모음에서 **다음**을 선택하여 **모듈 1**로 진행하세요. > 그리고 단계별 실습 가이드를 따라 실습 환경에 연결하고 작업을 시작하세요. ## 모듈 1: 세 개의 가용 영역에 걸쳐 TiDB 클러스터 배포 ### 1단계. 노드 ${LAB:HOST_MONITOR1_PUBLIC_IP}에 SSH 로그인 + 실습 가상 머신에 세 개의 SSH 연결을 열려면 다음을 클릭하세요: + [터미널 1](ssh://monitor1-ssh#1) + [터미널 2](ssh://monitor1-ssh#2) + [터미널 3](ssh://monitor1-ssh#3) + 이제 세 개의 활성 터미널 세션이 생성됩니다. + 로그인 후 표시되는 배너는 다음과 같습니다. ```output , #_ ~\_ ####_ Amazon Linux 2 ~~ \_#####\ ~~ \###| ~~ \#/ ___ ~~ V~' '-> ~~~ / A newer version of Amazon Linux is available! ~~._. _/ _/ _/ Amazon Linux 2023, GA and supported until 2028-03-15. _/m/' https://aws.amazon.com/linux/amazon-linux-2023/ ``` ### 2단계. 여러 가용 영역에 걸쳐 TiDB 클러스터 시작 + [터미널 1](ssh://monitor1-ssh#1)에서 프로비저닝된 클러스터 토폴로지 YAML을 검토합니다. ```bash cat nine-nodes.yaml ``` ```output global: user: "ec2-user" ssh_port: 22 deploy_dir: "/tidb-deploy" data_dir: "/tidb-data" arch: "amd64" server_configs: pd: replication.max-replicas: 3 pd_servers: - host: 10.90.3.145 client_port: 2379 peer_port: 2380 advertise_client_addr: "http://54.203.147.80:2379" - host: 10.90.1.184 client_port: 2379 peer_port: 2380 advertise_client_addr: "http://34.221.154.223:2379" - host: 10.90.2.106 client_port: 2379 peer_port: 2380 advertise_client_addr: "http://35.86.165.210:2379" tidb_servers: - host: 10.90.1.177 port: 4000 status_port: 10080 deploy_dir: /tidb-deploy/tidb-4000 log_dir: /tidb-deploy/tidb-4000/log - host: 10.90.2.16 port: 4000 status_port: 10080 deploy_dir: /tidb-deploy/tidb-4000 log_dir: /tidb-deploy/tidb-4000/log tikv_servers: - host: 10.90.3.115 port: 20160 status_port: 20180 - host: 10.90.2.143 port: 20160 status_port: 20180 - host: 10.90.1.247 port: 20160 status_port: 20180 monitoring_servers: - host: 10.90.4.92 grafana_servers: - host: 10.90.4.92 alertmanager_servers: - host: 10.90.4.92 ``` + TiDB 클러스터를 배포하기 위해 시스템 구성을 수정합니다. ```bash tiup mirror set tidb-community-server-${LAB:TIDB_VERSION}-linux-amd64 tiup cluster check nine-nodes.yaml \ --user ec2-user \ -i /home/ec2-user/.ssh/pe-class-key-${LAB:REGION_NAME}.pem \ --apply ``` ```output . . . + Try to apply changes to fix failed checks - Applying changes on 10.90.3.145 ... ⠧ Sysctl: host=10.90.3.145 vm.swappiness = 0 + Try to apply changes to fix failed checks - Applying changes on 10.90.3.145 ... ⠇ Sysctl: host=10.90.3.145 vm.swappiness = 0 + Try to apply changes to fix failed checks + Try to apply changes to fix failed checks - Applying changes on 10.90.3.145 ... Done + Try to apply changes to fix failed checks - Applying changes on 10.90.3.145 ... Done + Try to apply changes to fix failed checks - Applying changes on 10.90.3.145 ... Done - Applying changes on 10.90.2.106 ... Done - Applying changes on 10.90.2.143 ... Done - Applying changes on 10.90.1.177 ... Done - Applying changes on 10.90.1.184 ... Done - Applying changes on 10.90.3.115 ... Done - Applying changes on 10.90.1.247 ... Done - Applying changes on 10.90.2.16 ... Done - Applying changes on 10.90.4.92 ... Done ``` + TiDB 클러스터를 배포합니다. ```bash tiup cluster deploy tidb-demo ${LAB:TIDB_VERSION} ./nine-nodes.yaml \ --user ec2-user \ -i /home/ec2-user/.ssh/pe-class-key-${LAB:REGION_NAME}.pem \ --yes ``` ```output . . . Cluster `tidb-demo` deployed successfully, you can start it with command: `tiup cluster start tidb-demo --init` ``` + 배포된 TiDB 클러스터를 시작합니다. ```bash tiup cluster start tidb-demo ``` ```output . . . Started cluster `tidb-demo` successfully ``` ### 3단계. TiDB 클러스터의 상태 확인 + 주요 클러스터 구성 요소는 세 개의 서브넷에 분산되어 있습니다: 10.90.1.0/24, 10.90.2.0/24, 10.90.3.0/24, 각각은 가용 영역에 대응됩니다. + 클러스터는 3개의 PD 서버, 3개의 TiKV 서버, 2개의 TiDB 서버를 포함합니다. + PD 서버, TiDB 서버, TiKV 서버를 호스팅하는 서브넷 10.90.1.0/24에 특히 주의를 기울이세요. + 환경의 IP 주소와 샘플 출력은 다를 수 있지만 서브넷 구성은 일관됩니다. ```bash tiup cluster display tidb-demo ``` ```output Cluster type: tidb Cluster name: tidb-demo Cluster version: v${LAB:TIDB_VERSION} Deploy user: ec2-user SSH type: builtin Dashboard URL: http://35.86.135.34:2379/dashboard Grafana URL: http://10.90.4.7:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.7:9093 alertmanager 10.90.4.7 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.7:3000 grafana 10.90.4.7 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.110:2379 pd 10.90.1.110 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.2.63:2379 pd 10.90.2.63 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.3.162:2379 pd 10.90.3.162 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.7:9090 prometheus 10.90.4.7 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.116:4000 tidb 10.90.1.116 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.15:4000 tidb 10.90.2.15 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.35:20160 tikv 10.90.1.35 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.2.138:20160 tikv 10.90.2.138 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.3.220:20160 tikv 10.90.3.220 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 Total nodes: 11 ``` ## 모듈 2: 읽기 및 쓰기 워크로드 시작 ### 1단계. 테스트용 테이블 생성 + [터미널 2](ssh://monitor1-ssh#2)에서 TiDB 서버 인스턴스 중 하나에 연결하여 테스트 테이블을 생성하고 터미널로 종료합니다. ```bash mysql -h ${HOST_DB1_PRIVATE_IP} -P 4000 -uroot ``` ```sql DROP TABLE IF EXISTS test.dummy; CREATE TABLE test.dummy ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(80), event JSON); EXIT; ``` ### 2단계. INSERT 워크로드 적용 + [터미널 2](ssh://monitor1-ssh#2)에서 샘플 Java 프로그램을 실행하여 INSERT 워크로드를 시작합니다. + 프로그램은 두 개의 워커를 사용하여 INSERT 작업을 실행하도록 TiDB 서버 인스턴스에 연결됩니다. 연결된 TiDB 서버가 연결을 잃으면 프로그램은 자동으로 사용 가능한 다른 TiDB 서버로 전환합니다. 출력은 INSERT 요청을 처리하는 TiDB 서버의 개인 IP 주소를 표시합니다. 두 개가 있어야 합니다. 워크로드를 실행 상태로 두고 다음 단계로 진행합니다. ```bash cd scripts javac -cp .:misc/mysql-connector-java-5.1.36-bin.jar DemoJdbcEndlessInsertDummyCSP.java java -cp .:misc/mysql-connector-java-5.1.36-bin.jar DemoJdbcEndlessInsertDummyCSP ``` ```output Worker 2 -> TiDB:Thu May 09 07:05:33 UTC 2024 at 10.90.1.116 Worker 1 -> TiDB:Thu May 09 07:05:33 UTC 2024 at 10.90.2.15 Worker 1 -> TiDB:Thu May 09 07:05:34 UTC 2024 at 10.90.1.116 Worker 2 -> TiDB:Thu May 09 07:05:34 UTC 2024 at 10.90.2.15 Worker 1 -> TiDB:Thu May 09 07:05:35 UTC 2024 at 10.90.2.15 Worker 2 -> TiDB:Thu May 09 07:05:35 UTC 2024 at 10.90.1.116 Worker 1 -> TiDB:Thu May 09 07:05:36 UTC 2024 at 10.90.1.116 ... ``` ### 3단계. 샘플 QUERY 워크로드 적용 + [터미널 3](ssh://monitor1-ssh#3)에서 아래 스크립트를 실행합니다. 스크립트는 두 개의 TiDB 서버 인스턴스에 연결하여 쿼리를 실행하려고 시도합니다. 하나의 TiDB 서버가 실패하거나 응답할 수 없으면 스크립트는 자동으로 사용 가능한 다른 인스턴스로 전환합니다. TiDB 서버 인스턴스는 연결 요청에 1초만 응답할 수 있도록 설정되어 있으며, 이는 2단계의 Java 프로그램과 유사한 설정입니다. 출력은 test.dummy 테이블의 행 수가 꾸준히 증가하는 것을 보여줍니다. 워크로드를 실행 상태로 두고 다음 단계로 진행합니다. ```bash qdb1(){ mysql -h ${HOST_DB1_PRIVATE_IP} -P 4000 -uroot --connect-timeout 1 2>/dev/null << EOF SELECT COUNT(event) FROM test.dummy; EOF } qdb2(){ mysql -h ${HOST_DB2_PRIVATE_IP} -P 4000 -uroot --connect-timeout 1 2>/dev/null << EOF SELECT COUNT(event) FROM test.dummy; EOF } query1(){ echo; date; qdb1 || qdb2 sleep 2; } query2(){ echo; date; qdb2 || qdb1 sleep 2; } while true; do query1; query2; done; ``` ```output Mon May 13 05:27:33 UTC 2024 COUNT(event) 2608 Mon May 13 05:27:35 UTC 2024 COUNT(event) 2612 Mon May 13 05:27:37 UTC 2024 COUNT(event) 2616 Mon May 13 05:27:39 UTC 2024 COUNT(event) 2620 ... ``` ### 4단계. TiKV 리전 복제본 설정이 3으로 구성되어 있는지 확인 + [터미널 1](ssh://monitor1-ssh#1)로 돌아가서 TiKV 리전 복제본 설정이 3으로 구성되어 있는지 확인합니다. 이는 데이터 센터 또는 가용 영역 장애로 인해 TiKV 서버 중 하나가 손실되더라도 나머지 두 TiKV 서버가 정상적으로 계속 작동할 수 있도록 보장합니다. ```bash mysql -h ${HOST_DB1_PRIVATE_IP} -P 4000 -uroot ``` ```sql SHOW CONFIG WHERE type='pd' AND name='replication.max-replicas'; EXIT ``` ```output +------+---------------------+--------------------------+-------+ | Type | Instance | Name | Value | +------+---------------------+--------------------------+-------+ | pd | 52.13.86.218:2379 | replication.max-replicas | 3 | | pd | 34.212.25.193:2379 | replication.max-replicas | 3 | | pd | 34.222.233.112:2379 | replication.max-replicas | 3 | +------+---------------------+--------------------------+-------+ 3 rows in set (0.02 sec) Bye ``` ## 모듈 3: 가용 영역 1의 서브넷 1 격리 ### 1단계. 가용 영역 1에서 완전한 가용 영역 장애 시뮬레이션 + [터미널 1](ssh://monitor1-ssh#1)로 돌아가서 스크립트를 실행하여 서브넷 `demo-subnet-1`(가용 영역 1의 서브넷 10.90.1.0/24)을 차단함으로써 완전한 가용 영역 장애를 시뮬레이션합니다. ```bash VPC_ID=`aws ec2 describe-vpcs \ --filters "Name=tag:Name,Values=user_unique_tag" \ --query "Vpcs[0].VpcId" \ --output text \ --region ${LAB:REGION_CODE}` SUBNET_ID=`aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=${VPC_ID}" "Name=tag:Name,Values=demo-subnet-1" \ --query "Subnets[0].SubnetId" \ --output text \ --region ${LAB:REGION_CODE}` CAGE_NACL_ID=`aws ec2 describe-network-acls \ --filters "Name=vpc-id,Values=${VPC_ID}" "Name=default,Values=false" "Name=tag:Name,Values=cage" \ --query "NetworkAcls[0].NetworkAclId" \ --output text \ --region ${LAB:REGION_CODE}` ASSOC_ID=`aws ec2 describe-network-acls \ --filters "Name=vpc-id,Values=${VPC_ID}" "Name=default,Values=true" \ --query "NetworkAcls[0].Associations" \ --output text \ --region ${LAB:REGION_CODE} | grep ${SUBNET_ID} | awk -F" " '{print $1}'` aws ec2 replace-network-acl-association \ --association-id ${ASSOC_ID} \ --network-acl-id ${CAGE_NACL_ID} \ --region ${LAB:REGION_CODE} ``` ```output { "NewAssociationId": "aclassoc-0402a6103febf799f" } ``` ### 2단계. 여러 구성 요소의 연결이 끊어진 것을 확인 + [터미널 1](ssh://monitor1-ssh#1)에서 클러스터 상태를 다시 확인하여 가용 영역 장애로 인해 PD, TiDB, TiKV 서버를 포함한 여러 구성 요소가 연결 해제/격리되었는지 확인합니다. + 샘플 출력에서 영향을 받은 서버는 `10.90.1.208:2379 pd`, `10.90.1.247:4000 tidb`, `10.90.1.122:20160 tikv`입니다. 따라서 클러스터 구성 요소의 1/3이 연결을 잃었습니다. ```bash tiup cluster display tidb-demo ``` ```output Cluster type: tidb Cluster name: tidb-demo Cluster version: v${LAB:TIDB_VERSION} Deploy user: ec2-user SSH type: builtin Dashboard URL: http://52.13.86.218:2379/dashboard Grafana URL: http://10.90.4.74:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.74:9093 alertmanager 10.90.4.74 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.74:3000 grafana 10.90.4.74 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.208:2379 pd 10.90.1.208 2379/2380 linux/x86_64 Down /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.2.39:2379 pd 10.90.2.39 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.3.68:2379 pd 10.90.3.68 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.74:9090 prometheus 10.90.4.74 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.247:4000 tidb 10.90.1.247 4000/10080 linux/x86_64 Down - /tidb-deploy/tidb-4000 10.90.2.33:4000 tidb 10.90.2.33 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.122:20160 tikv 10.90.1.122 20160/20180 linux/x86_64 Disconnected /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.2.5:20160 tikv 10.90.2.5 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.3.14:20160 tikv 10.90.3.14 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 Total nodes: 11 ``` ### 3단계. INSERT 및 QUERY 워크로드가 여전히 실행 중인지 확인 + [터미널 2](ssh://monitor1-ssh#2)와 [터미널 3](ssh://monitor1-ssh#3)에서 샘플 INSERT/QUERY 워크로드가 여전히 실행 중인지 확인합니다. INSERT와 QUERY 워크로드가 이제 하나의 TiDB 서버 인스턴스로만 작업하고 있다는 점에 주목하세요. ```output Worker 1 -> TiDB:Mon May 13 05:51:52 UTC 2024 at 10.90.2.33 Worker 2 -> TiDB:Mon May 13 05:51:52 UTC 2024 at 10.90.2.33 Worker 1 -> TiDB:Mon May 13 05:51:53 UTC 2024 at 10.90.2.33 Worker 2 -> TiDB:Mon May 13 05:51:53 UTC 2024 at 10.90.2.33 Worker 1 -> TiDB:Mon May 13 05:51:54 UTC 2024 at 10.90.2.33 ... ``` ```output Mon May 13 05:51:51 UTC 2024 COUNT(event) 5481 Mon May 13 05:51:54 UTC 2024 COUNT(event) 5485 ... ``` ### 4단계. 가용 영역 1에 대한 연결 복원 + [터미널 1](ssh://monitor1-ssh#1)에서 스크립트를 실행하여 `demo-subnet-1`에 대한 연결을 복원합니다. 실제 상황에서는 이 단계가 일반적으로 불필요합니다. 가용 영역의 문제가 빠르게 해결되면 네트워크가 복원되면 연결이 끊어진 구성 요소가 자동으로 클러스터에 다시 합류합니다. 가용 영역 또는 데이터 센터 문제가 지속되어 문제가 지속되면 나머지 가용 영역에서 새 구성 요소를 스케일 아웃하고 연결이 끊어진 구성 요소를 제거하여 영향을 완화할 수 있습니다. 접근 방식에 관계없이 TiDB는 중단 없는 비즈니스 운영을 보장합니다. 고급 TiDB 기술에 대한 자세한 내용은 [https://tidb.io/education/](https://tidb.io/education/)을 방문하세요. ```bash VPC_ID=`aws ec2 describe-vpcs \ --filters "Name=tag:Name,Values=user_unique_tag" \ --query "Vpcs[0].VpcId" \ --output text \ --region ${LAB:REGION_CODE}` SUBNET_ID=`aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=${VPC_ID}" "Name=tag:Name,Values=demo-subnet-1" \ --query "Subnets[0].SubnetId" \ --output text \ --region ${LAB:REGION_CODE}` DEFAULT_NACL_ID=`aws ec2 describe-network-acls \ --filters "Name=vpc-id,Values=${VPC_ID}" "Name=default,Values=true" \ --query "NetworkAcls[0].NetworkAclId" \ --output text \ --region ${LAB:REGION_CODE}` ASSOC_ID=`aws ec2 describe-network-acls \ --filters "Name=vpc-id,Values=${VPC_ID}" "Name=default,Values=false" \ --query "NetworkAcls[0].Associations" \ --output text \ --region ${LAB:REGION_CODE} | grep ${SUBNET_ID} | awk -F" " '{print $1}'` aws ec2 replace-network-acl-association \ --association-id ${ASSOC_ID} \ --network-acl-id ${DEFAULT_NACL_ID} \ --region ${LAB:REGION_CODE} ``` ```output { "NewAssociationId": "aclassoc-0df1e05cfc70356a8" } ``` ### 5단계. 모든 클러스터 구성 요소가 동기화되었는지 확인 + 클러스터 상태를 확인하여 이전에 연결이 끊어진 구성 요소가 이제 동기화되었는지 확인합니다. ```bash tiup cluster display tidb-demo ``` ```output Cluster type: tidb Cluster name: tidb-demo Cluster version: v${LAB:TIDB_VERSION} Deploy user: ec2-user SSH type: builtin Dashboard URL: http://52.13.86.218:2379/dashboard Grafana URL: http://10.90.4.74:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.74:9093 alertmanager 10.90.4.74 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.74:3000 grafana 10.90.4.74 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.208:2379 pd 10.90.1.208 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.2.39:2379 pd 10.90.2.39 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.3.68:2379 pd 10.90.3.68 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.74:9090 prometheus 10.90.4.74 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.247:4000 tidb 10.90.1.247 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.33:4000 tidb 10.90.2.33 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.122:20160 tikv 10.90.1.122 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.2.5:20160 tikv 10.90.2.5 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.3.14:20160 tikv 10.90.3.14 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 Total nodes: 11 ``` + [터미널 2](ssh://monitor1-ssh#2)와 [터미널 3](ssh://monitor1-ssh#3)에서 Ctrl+C를 눌러 두 워크로드를 모두 중지합니다. ## 결론 TiDB의 분산 아키텍처 덕분에 데이터 센터 또는 가용 영역 수준의 장애는 서버 측 페일오버를 트리거하거나 데이터베이스 클라이언트가 페일오버가 완료되기를 기다릴 필요가 없습니다. 대신 데이터베이스 클라이언트는 사용 가능한 TiDB 서버 인스턴스에 원활하게 연결하여 지속적인 비즈니스 운영을 보장할 수 있습니다. 이러한 재해가 발생하면 애플리케이션은 비즈니스 요구 사항에 따라 작업 타임아웃을 설정할 수 있습니다. 기존 시스템과 달리 TiDB는 데이터베이스 클라이언트 또는 서버 측 프록시가 다시 연결하기 전에 서버 측 페일오버가 완료될 필요가 없습니다. ```hbsptform { "ui": { "titleLevel": 3 }, "portalId": "4466002", "formId": "89fa8368-eba1-4b84-b91e-eb9eb6613ddf", "region": "na1", "sfdcCampaignId": "701RC00000VqCODYA3" } ```