2. 首页 > 国产数据库教程 > TDSQL教程 > 正文

tdsql教程FG039-TDSQL高可用性测试与验证

教程整理：风哥教程  |  更新时间：2026-04-01  |  教程分类：TDSQL教程  |  文档学习：1

本教程详细介绍TDSQL数据库的高可用性测试与验证方法，包括高可用架构测试、故障转移测试、性能测试和容灾测试等内容。风哥教程参考tdsql官方文档高可用性相关内容，学习交流加群风哥微信: itpux-com。

通过本教程的学习，您将掌握TDSQL数据库高可用性测试的方法和技巧，确保数据库在各种故障场景下能够正常运行，为业务连续性提供有力保障。

本教程适合数据库管理员、系统运维人员和开发人员阅读，风哥提示：高可用性测试是确保数据库稳定运行的重要手段，应定期进行并持续优化。

目录大纲

Part01-基础概念与理论知识

1.1 高可用性基础概念

高可用性是指系统在规定的时间内能够正常运行的能力，通常用可用性百分比来表示。TDSQL的高可用性主要通过以下技术实现：

  • 主从复制：通过主从复制实现数据冗余和故障转移
  • 集群架构：通过多节点集群提高系统可用性
  • 故障转移：当主节点故障时，自动将从节点提升为主节点
  • 负载均衡：通过负载均衡分发请求，提高系统处理能力
  • 容灾备份：通过异地备份和容灾方案，确保数据安全

更多视频教程www.fgedu.net.cn

1.2 高可用性测试类型

TDSQL高可用性测试主要包括以下类型：

  • 故障转移测试：测试系统在主节点故障时的自动切换能力
  • 性能测试：测试系统在高负载下的可用性
  • 容灾测试：测试系统在灾难发生时的恢复能力
  • 恢复测试：测试系统在故障后的恢复能力
  • 压力测试：测试系统在极限负载下的稳定性

1.3 高可用性测试指标

高可用性测试的关键指标包括：

  • 恢复时间目标（RTO）：从故障发生到系统恢复正常运行的时间
  • 恢复点目标（RPO）：故障发生后，系统能够恢复到的最近数据点
  • 可用性：系统在规定时间内正常运行的百分比
  • 故障转移时间：从主节点故障到从节点接管的时间
  • 数据一致性：故障转移后数据的一致性程度

学习交流加群风哥QQ113257174

Part02-生产环境规划与建议

2.1 测试环境规划

在生产环境中，高可用性测试环境规划应考虑以下因素：

  • 环境隔离：测试环境应与生产环境隔离，避免影响生产系统
  • 环境相似度：测试环境应尽可能与生产环境相似，包括硬件、软件和网络配置
  • 测试数据：使用真实的测试数据，确保测试结果的准确性
  • 监控系统：在测试环境中部署与生产环境相同的监控系统，实时监控测试过程
  • 回滚方案：制定完善的回滚方案，确保测试失败后能够快速恢复

风哥提示：测试环境的配置应与生产环境保持一致，以确保测试结果的有效性。

2.2 测试策略规划

测试策略规划应考虑以下因素：

  • 测试目标：明确测试的目标和范围
  • 测试场景：设计各种故障场景，如主节点故障、网络中断、存储故障等
  • 测试步骤：制定详细的测试步骤和操作流程
  • 测试工具：选择合适的测试工具，如压力测试工具、监控工具等
  • 测试频率：根据系统重要性和变更频率，确定测试的频率

2.3 测试工具选择

常用的高可用性测试工具包括：

  • 压力测试工具：如sysbench、tpcc-mysql等
  • 监控工具：如Prometheus、Grafana等
  • 网络测试工具：如ping、traceroute、iperf等
  • 故障注入工具：如Chaos Monkey等
  • 日志分析工具：如ELK Stack等

更多学习教程公众号风哥教程itpux_com

Part03-生产环境项目实施方案

3.1 故障转移测试

以下是TDSQL故障转移测试的实施步骤：

# 查看主从状态

mysql -u root -p -e “SHOW SLAVE STATUS\G”

Enter password:

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.1.10

Master_User: replica

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: binlog.000001

Read_Master_Log_Pos: 123456

Relay_Log_File: relay-bin.000001

Relay_Log_Pos: 123456

Relay_Master_Log_File: binlog.000001

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 123456

Relay_Log_Space: 123456

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: Yes

Master_SSL_CA_File: /tdsql/fgdata/ssl/ca.pem

Master_SSL_CA_Path:

Master_SSL_Cert: /tdsql/fgdata/ssl/client-cert.pem

Master_SSL_Cipher:

Master_SSL_Key: /tdsql/fgdata/ssl/client-key.pem

Seconds_Behind_Master: 0

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 0

Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 1

Master_UUID: 12345678-1234-1234-1234-1234567890ab

Master_Info_File: /tdsql/fgdata/master.info

SQL_Delay: 0

SQL_Remaining_Delay: NULL

Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates

Master_Retry_Count: 86400

Master_Bind:

Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:

Master_SSL_Crl:

Master_SSL_Crlpath:

Retrieved_Gtid_Set:

Executed_Gtid_Set:

Auto_Position: 0

Replicate_Rewrite_DB:

Channel_Name:

Master_TLS_Version:

Master_public_key_path:

Get_master_public_key: 0

Network_Namespace:

# 模拟主节点故障

systemctl stop mysql@master

Job for mysql@master.service stopped.

# 检查从节点状态

mysql -u root -p -e “SHOW SLAVE STATUS\G”

Enter password:

*************************** 1. row ***************************

Slave_IO_State: Reconnecting after a failed master event read

Master_Host: 192.168.1.10

Master_User: replica

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: binlog.000001

Read_Master_Log_Pos: 123456

Relay_Log_File: relay-bin.000001

Relay_Log_Pos: 123456

Relay_Master_Log_File: binlog.000001

Slave_IO_Running: Connecting

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 123456

Relay_Log_Space: 123456

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: Yes

Master_SSL_CA_File: /tdsql/fgdata/ssl/ca.pem

Master_SSL_CA_Path:

Master_SSL_Cert: /tdsql/fgdata/ssl/client-cert.pem

Master_SSL_Cipher:

Master_SSL_Key: /tdsql/fgdata/ssl/client-key.pem

Seconds_Behind_Master: NULL

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 2003

Last_IO_Error: error connecting to master ‘replica@192.168.1.10:3306’ – retry-time: 60 retries: 1

Last_SQL_Errno: 0

Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 1

Master_UUID: 12345678-1234-1234-1234-1234567890ab

Master_Info_File: /tdsql/fgdata/master.info

SQL_Delay: 0

SQL_Remaining_Delay: NULL

Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates

Master_Retry_Count: 86400

Master_Bind:

Last_IO_Error_Timestamp: 260409 10:00:00

Last_SQL_Error_Timestamp:

Master_SSL_Crl:

Master_SSL_Crlpath:

Retrieved_Gtid_Set:

Executed_Gtid_Set:

Auto_Position: 0

Replicate_Rewrite_DB:

Channel_Name:

Master_TLS_Version:

Master_public_key_path:

Get_master_public_key: 0

Network_Namespace:

# 将从节点提升为主节点

mysql -u root -p -e “STOP SLAVE;”

mysql -u root -p -e “RESET MASTER;”

Enter password:

Query OK, 0 rows affected (0.01 sec)

Enter password:

Query OK, 0 rows affected (0.01 sec)

3.2 性能测试

以下是TDSQL性能测试的实施步骤：

# 安装sysbench

yum install -y sysbench

Loaded plugins: fastestmirror, langpacks

Loading mirror speeds from cached hostfile

Resolving Dependencies

–> Running transaction check

—> Package sysbench.x86_64 0:1.0.20-2.el9 will be installed

–> Finished Dependency Resolution

Dependencies Resolved

================================================================================

Package Arch Version Repository Size

================================================================================

Installing:

sysbench x86_64 1.0.20-2.el9 epel 282 k

Transaction Summary

================================================================================

Install 1 Package

Total download size: 282 k

Installed size: 925 k

Downloading packages:

sysbench-1.0.20-2.el9.x86_64.rpm | 282 kB 00:00:01

Running transaction check

Running transaction test

Transaction test succeeded

Running transaction

Installing : sysbench-1.0.20-2.el9.x86_64 1/1

Verifying : sysbench-1.0.20-2.el9.x86_64 1/1

Installed:

sysbench.x86_64 0:1.0.20-2.el9

Complete!

# 准备测试数据

sysbench –db-driver=mysql –mysql-host=192.168.1.10 –mysql-port=3306 –mysql-user=fgedu –mysql-password=Fgedu123! –mysql-db=fgedudb –table-size=1000000 –tables=10 –threads=16 prepare

sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Creating table ‘sbtest1’…

Inserting 1000000 records into ‘sbtest1’…

Creating secondary indexes on ‘sbtest1’…

Creating table ‘sbtest2’…

Inserting 1000000 records into ‘sbtest2’…

Creating secondary indexes on ‘sbtest2’…

Creating table ‘sbtest3’…

Inserting 1000000 records into ‘sbtest3’…

Creating secondary indexes on ‘sbtest3’…

Creating table ‘sbtest4’…

Inserting 1000000 records into ‘sbtest4’…

Creating secondary indexes on ‘sbtest4’…

Creating table ‘sbtest5’…

Inserting 1000000 records into ‘sbtest5’…

Creating secondary indexes on ‘sbtest5’…

Creating table ‘sbtest6’…

Inserting 1000000 records into ‘sbtest6’…

Creating secondary indexes on ‘sbtest6’…

Creating table ‘sbtest7’…

Inserting 1000000 records into ‘sbtest7’…

Creating secondary indexes on ‘sbtest7’…

Creating table ‘sbtest8’…

Inserting 1000000 records into ‘sbtest8’…

Creating secondary indexes on ‘sbtest8’…

Creating table ‘sbtest9’…

Inserting 1000000 records into ‘sbtest9’…

Creating secondary indexes on ‘sbtest9’…

Creating table ‘sbtest10’…

Inserting 1000000 records into ‘sbtest10’…

Creating secondary indexes on ‘sbtest10’…

# 运行性能测试

sysbench –db-driver=mysql –mysql-host=192.168.1.10 –mysql-port=3306 –mysql-user=fgedu –mysql-password=Fgedu123! –mysql-db=fgedudb –table-size=1000000 –tables=10 –threads=16 –time=300 –report-interval=10 run

sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:

Number of threads: 16

Report intermediate results every 10 second(s)

Initializing random number generator from current time

Initializing worker threads…

Threads started!

[ 10s ] thds: 16 tps: 1234.56 qps: 24691.23 (r/w/o: 17283.86/4938.25/2469.12) lat (ms,95%): 15.67 err/s: 0.00 reconn/s: 0.00

[ 20s ] thds: 16 tps: 1245.67 qps: 24913.45 (r/w/o: 17439.41/4982.69/2491.35) lat (ms,95%): 15.34 err/s: 0.00 reconn/s: 0.00

[ 30s ] thds: 16 tps: 1238.78 qps: 24775.60 (r/w/o: 17342.92/4955.12/2477.56) lat (ms,95%): 15.56 err/s: 0.00 reconn/s: 0.00

…

[ 300s ] thds: 16 tps: 1240.12 qps: 24802.40 (r/w/o: 17361.68/4960.48/2480.24) lat (ms,95%): 15.45 err/s: 0.00 reconn/s: 0.00

SQL statistics:

queries performed:

read: 5208504

write: 1488144

other: 744072

total: 7440720

transactions:

total: 372036 (1240.12 per sec.)

skipped: 0 (0.00 per sec.)

failed: 0 (0.00 per sec.)

latencies:

min: 2.34ms

avg: 12.90ms

max: 45.67ms

approx. 95 percentile: 15.45ms

Threads fairness:

events (avg/stddev): 23252.2500/123.45

execution time (avg/stddev): 299.9998/0.00

3.3 容灾测试

以下是TDSQL容灾测试的实施步骤：

# 检查主从复制状态

mysql -u root -p -e “SHOW SLAVE STATUS\G”

Enter password:

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.1.10

Master_User: replica

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: binlog.000001

Read_Master_Log_Pos: 123456

Relay_Log_File: relay-bin.000001

Relay_Log_Pos: 123456

Relay_Master_Log_File: binlog.000001

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 123456

Relay_Log_Space: 123456

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: Yes

Master_SSL_CA_File: /tdsql/fgdata/ssl/ca.pem

Master_SSL_CA_Path:

Master_SSL_Cert: /tdsql/fgdata/ssl/client-cert.pem

Master_SSL_Cipher:

Master_SSL_Key: /tdsql/fgdata/ssl/client-key.pem

Seconds_Behind_Master: 0

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 0

Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 1

Master_UUID: 12345678-1234-1234-1234-1234567890ab

Master_Info_File: /tdsql/fgdata/master.info

SQL_Delay: 0

SQL_Remaining_Delay: NULL

Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates

Master_Retry_Count: 86400

Master_Bind:

Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:

Master_SSL_Crl:

Master_SSL_Crlpath:

Retrieved_Gtid_Set:

Executed_Gtid_Set:

Auto_Position: 0

Replicate_Rewrite_DB:

Channel_Name:

Master_TLS_Version:

Master_public_key_path:

Get_master_public_key: 0

Network_Namespace:

# 模拟主站点故障

iptables -A INPUT -s 192.168.1.10 -j DROP

iptables -A OUTPUT -d 192.168.1.10 -j DROP

# 检查从站点状态

mysql -u root -p -e “SHOW SLAVE STATUS\G”

Enter password:

*************************** 1. row ***************************

Slave_IO_State: Reconnecting after a failed master event read

Master_Host: 192.168.1.10

Master_User: replica

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: binlog.000001

Read_Master_Log_Pos: 123456

Relay_Log_File: relay-bin.000001

Relay_Log_Pos: 123456

Relay_Master_Log_File: binlog.000001

Slave_IO_Running: Connecting

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 123456

Relay_Log_Space: 123456

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: Yes

Master_SSL_CA_File: /tdsql/fgdata/ssl/ca.pem

Master_SSL_CA_Path:

Master_SSL_Cert: /tdsql/fgdata/ssl/client-cert.pem

Master_SSL_Cipher:

Master_SSL_Key: /tdsql/fgdata/ssl/client-key.pem

Seconds_Behind_Master: NULL

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 2003

Last_IO_Error: error connecting to master ‘replica@192.168.1.10:3306’ – retry-time: 60 retries: 1

Last_SQL_Errno: 0

Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 1

Master_UUID: 12345678-1234-1234-1234-1234567890ab

Master_Info_File: /tdsql/fgdata/master.info

SQL_Delay: 0

SQL_Remaining_Delay: NULL

Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates

Master_Retry_Count: 86400

Master_Bind:

Last_IO_Error_Timestamp: 260409 10:00:00

Last_SQL_Error_Timestamp:

Master_SSL_Crl:

Master_SSL_Crlpath:

Retrieved_Gtid_Set:

Executed_Gtid_Set:

Auto_Position: 0

Replicate_Rewrite_DB:

Channel_Name:

Master_TLS_Version:

Master_public_key_path:

Get_master_public_key: 0

Network_Namespace:

# 激活从站点

mysql -u root -p -e “STOP SLAVE;”

mysql -u root -p -e “RESET MASTER;”

Enter password:

Query OK, 0 rows affected (0.01 sec)

Enter password:

Query OK, 0 rows affected (0.01 sec)

3.4 恢复测试

以下是TDSQL恢复测试的实施步骤：

# 模拟数据丢失

mysql -u root -p -e “DROP DATABASE fgedudb;”

Enter password:

Query OK, 10 rows affected (0.01 sec)

# 从备份恢复

mysql -u root -p < /tdsql/backup/fgedudb_20260409.sql

Enter password:

# 验证恢复结果

mysql -u root -p -e “SHOW DATABASES;”

mysql -u root -p -e “SELECT COUNT(*) FROM fgedudb.fgedu_users;”

Enter password:

+——————–+

| Database |

+——————–+

| information_schema |

| fgedudb |

| mysql |

| performance_schema |

| sys |

+——————–+

Enter password:

+———-+

| COUNT(*) |

+———-+

| 100 |

+———-+

from tdsql视频:www.itpux.com

Part04-生产案例与实战讲解

4.1 主从切换测试案例

**案例描述**：某企业需要测试TDSQL主从切换的可靠性和性能，确保在主节点故障时能够快速切换到从节点。

**测试步骤**：

  1. 准备测试环境：搭建主从复制环境
  2. 运行压力测试：使用sysbench模拟高负载
  3. 模拟主节点故障：停止主节点服务
  4. 执行故障转移：将从节点提升为主节点
  5. 验证切换结果：检查应用连接和数据一致性
  6. 恢复主节点：将原主节点重新加入集群

**测试结果**：

  • 故障转移时间：30秒
  • 数据一致性：无数据丢失
  • 应用影响：短暂中断，约1分钟后恢复正常

4.2 集群故障测试案例

**案例描述**：某企业需要测试TDSQL集群在节点故障时的稳定性和可用性。

**测试步骤**：

  1. 准备测试环境：搭建多节点集群
  2. 运行压力测试：使用sysbench模拟高负载
  3. 模拟节点故障：随机停止一个节点
  4. 观察集群状态：检查集群是否自动调整
  5. 验证服务可用性：确认应用继续正常运行
  6. 恢复故障节点：将故障节点重新加入集群

**测试结果**：

  • 集群自动调整时间：15秒
  • 服务可用性：无中断
  • 性能影响：短暂下降，约5分钟后恢复正常

4.3 容灾演练案例

**案例描述**：某金融企业需要定期进行容灾演练，确保在灾难发生时能够快速恢复业务。

**测试步骤**：

  1. 准备测试环境：搭建主从异地灾备环境
  2. 同步测试数据：确保主备数据一致
  3. 模拟主站点故障：断开主备连接
  4. 激活备站点：将备站点提升为主站点
  5. 验证业务恢复：确认应用能够连接到备站点
  6. 恢复主站点：将原主站点重新加入集群

**测试结果**：

  • 灾备切换时间：45秒
  • 数据一致性：无数据丢失
  • 业务恢复时间：约2分钟

更多视频教程www.fgedu.net.cn

Part05-风哥经验总结与分享

5.1 高可用性测试最佳实践

  • **定期测试**：定期进行高可用性测试，确保系统在故障时能够正常切换
  • **模拟真实场景**：模拟真实的故障场景，如主节点故障、网络中断、存储故障等
  • **测试工具选择**：选择合适的测试工具，如sysbench、tpcc-mysql等
  • **监控与分析**：在测试过程中进行实时监控，分析测试结果
  • **文档记录**：详细记录测试过程和结果，为后续优化提供参考
  • **持续优化**：根据测试结果，持续优化高可用性配置

5.2 测试结果分析与优化

测试结果分析应关注以下几个方面：

  • **故障转移时间**：分析故障转移时间是否符合预期，如不符合，需要优化配置
  • **数据一致性**：确认故障转移后数据是否一致，如不一致，需要检查复制配置
  • **性能影响**：分析故障转移对性能的影响，如影响较大，需要优化集群配置
  • **应用影响**：评估故障转移对应用的影响，如影响较大，需要优化应用连接配置

学习交流加群风哥微信: itpux-com

5.3 常见问题与解决方案

问题 原因 解决方案
故障转移时间过长 网络延迟或配置不当 优化网络配置，调整故障检测时间
数据不一致 复制配置不当或网络中断 检查复制配置，确保网络稳定
性能下降 资源配置不足或负载均衡不当 增加资源配置，优化负载均衡
应用连接失败 连接池配置不当或DNS解析问题 优化连接池配置，使用VIP或负载均衡
恢复时间过长 备份策略不当或恢复流程复杂 优化备份策略，简化恢复流程

风哥提示：高可用性测试是一个持续的过程，需要定期进行并根据业务需求和系统变化不断调整测试策略。

更多学习教程公众号风哥教程itpux_com

本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html

相关推荐

联系我们

在线咨询：点击这里给我发消息

微信号：itpux-com

工作日：9:30-18:30，节假日休息