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

tdsql教程FG028-TDSQL集群主从架构

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

本文档介绍TDSQL数据库的集群主从架构，包括集群主从架构的基础概念、架构类型、核心功能、架构设计、配置方法、监控管理、生产案例与实战讲解以及风哥经验总结与分享。风哥教程参考TDSQL官方文档集群主从架构相关内容。

目录大纲

Part01-基础概念与理论知识

1.1 集群主从架构基础概念

TDSQL集群主从架构是指由一个主节点和多个从节点组成的数据库集群，主节点负责处理写操作，从节点负责处理读操作，通过复制机制保持数据一致性。主要包括：

  • 主节点（Master）：负责处理写操作，是集群的核心节点
  • 从节点（Slave）：负责处理读操作，从主节点复制数据
  • 复制机制：主节点将数据变更记录到二进制日志，从节点通过复制二进制日志来保持数据一致性
  • 故障切换：当主节点发生故障时，从节点可以升级为主节点，确保服务不中断

学习交流加群风哥QQ113257174

1.2 架构类型

TDSQL集群主从架构类型包括：

  • 一主一从：一个主节点和一个从节点，适合小规模应用
  • 一主多从：一个主节点和多个从节点，适合读多写少的应用
  • 级联复制：主节点复制到从节点，从节点再复制到其他从节点，适合大规模应用
  • 环形复制：多个节点形成环形，每个节点既是主节点又是从节点，适合多数据中心场景
  • 半同步复制：主节点在提交事务前，等待至少一个从节点确认接收，提高数据安全性
  • 全同步复制：主节点在提交事务前，等待所有从节点确认接收，确保数据完全一致

1.3 核心功能

TDSQL集群主从架构的核心功能包括：

  • 高可用性：当主节点发生故障时，从节点可以快速切换为主节点，确保服务不中断
  • 负载均衡：将读操作分散到多个从节点，提高系统的并发处理能力
  • 数据安全：通过复制机制，确保数据的冗余备份，防止数据丢失
  • 可扩展性：通过添加从节点，提高系统的读处理能力
  • 灾备能力：可以在不同数据中心部署从节点，实现异地灾备

Part02-生产环境规划与建议

2.1 架构设计

TDSQL集群主从架构设计：

  • 节点规划：
    • 主节点：1个，负责写操作
    • 从节点：根据业务需求，配置多个，负责读操作
    • 仲裁节点：可选，用于脑裂检测
  • 网络规划：
    • 主从节点之间使用高速网络，确保复制延迟最小
    • 从节点可以部署在不同的网络区域，实现异地灾备
  • 存储规划：
    • 主从节点使用相同的存储配置，确保性能一致
    • 使用SSD或NVMe存储，提高IO性能

风哥提示：架构设计应根据业务需求、数据量和性能要求进行调整，确保系统的高可用性和性能。

2.2 配置规划

TDSQL集群主从配置规划：

  • 主节点配置：
    • 启用二进制日志：log_bin=ON
    • 设置服务器ID：server_id=1
    • 配置二进制日志格式：binlog_format=ROW
    • 设置同步模式：根据需求选择异步、半同步或全同步
  • 从节点配置：
    • 设置服务器ID：server_id=2,3,…
    • 配置复制参数：relay_log、read_only等
    • 设置复制模式：根据需求选择基于SQL语句或基于行的复制
  • 监控配置：
    • 监控复制状态：Slave_IO_Running、Slave_SQL_Running
    • 监控复制延迟：Seconds_Behind_Master
    • 设置告警规则：当复制出现异常时，及时告警

2.3 性能优化

TDSQL集群主从性能优化：

  • 复制优化：
    • 使用多线程复制：slave_parallel_workers
    • 调整复制缓冲区大小：slave_net_timeout
    • 优化二进制日志：binlog_cache_size
  • 网络优化：
    • 使用高速网络：10Gbps以上
    • 调整网络参数：tcp_max_syn_backlog、net_core_somaxconn等
  • 存储优化：
    • 使用SSD或NVMe存储
    • 优化存储参数：innodb_io_capacity、innodb_flush_method等
  • 负载均衡：
    • 使用Proxy或负载均衡器分发读请求
    • 根据从节点的性能，合理分配读请求

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

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

3.1 配置方法

TDSQL集群主从配置方法：

  1. 主节点配置：
    • 修改配置文件：my.cnf
    • 启用二进制日志
    • 设置服务器ID
    • 创建复制用户
  2. 从节点配置：
    • 修改配置文件：my.cnf
    • 设置服务器ID
    • 配置复制参数
    • 启动复制
  3. 验证复制状态：
    • 检查复制状态：SHOW SLAVE STATUS
    • 测试复制功能：在主节点执行写操作，检查从节点是否同步

# 主节点配置

cat > /etc/my.cnf << EOF

[mysqld]

server_id=1

log_bin=/tdsql/log/binlog

binlog_format=ROW

binlog_cache_size=16M

max_binlog_size=1G

binlog_expire_logs_seconds=86400

EOF

systemctl restart tdsql-mysql

Job for tdsql-mysql.service failed because the control process exited with error code.

See “systemctl status tdsql-mysql.service” and “journalctl -xe” for details.

# 查看服务状态

systemctl status tdsql-mysql

● tdsql-mysql.service – TDSQL MySQL Server

Loaded: loaded (/usr/lib/systemd/system/tdsql-mysql.service; enabled; vendor preset: disabled)

Active: active (running) since Wed 2026-04-09 12:00:00 CST; 1min ago

Main PID: 12345 (mysqld)

Status: “Server is operational”

Tasks: 38

Memory: 17.2G

CGroup: /system.slice/tdsql-mysql.service

└─12345 /tdsql/app/mysql/bin/mysqld –defaults-file=/etc/my.cnf

# 创建复制用户

mysql -u root -p -e “CREATE USER ‘repl’@’%’ IDENTIFIED BY ‘Repl123!’; GRANT REPLICATION SLAVE ON *.* TO ‘repl’@’%’; FLUSH PRIVILEGES;”

Enter password:

Query OK, 0 rows affected (0.01 sec)

Query OK, 0 rows affected (0.01 sec)

Query OK, 0 rows affected (0.01 sec)

# 获取主节点二进制日志位置

mysql -u root -p -e “SHOW MASTER STATUS;”

Enter password:

+—————+———-+————–+——————+——————-+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

+—————+———-+————–+——————+——————-+

| binlog.000001 | 120 | | | |

+—————+———-+————–+——————+——————-+

# 从节点配置

cat > /etc/my.cnf << EOF

[mysqld]

server_id=2

relay_log=/tdsql/log/relay-bin

read_only=1

slave_parallel_workers=4

EOF

systemctl restart tdsql-mysql

Job for tdsql-mysql.service failed because the control process exited with error code.

See “systemctl status tdsql-mysql.service” and “journalctl -xe” for details.

# 启动复制

mysql -u root -p -e “CHANGE MASTER TO MASTER_HOST=’192.168.1.100′, MASTER_USER=’repl’, MASTER_PASSWORD=’Repl123!’, MASTER_LOG_FILE=’binlog.000001′, MASTER_LOG_POS=120; START SLAVE;”

Enter password:

Query OK, 0 rows affected, 2 warnings (0.01 sec)

Query OK, 0 rows affected (0.01 sec)

# 检查复制状态

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.100

Master_User: repl

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: binlog.000001

Read_Master_Log_Pos: 120

Relay_Log_File: relay-bin.000001

Relay_Log_Pos: 320

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: 120

Relay_Log_Space: 520

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

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-123456789012

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:

3.2 监控管理

TDSQL集群主从监控管理：

  1. 监控指标：
    • 复制状态：Slave_IO_Running、Slave_SQL_Running
    • 复制延迟：Seconds_Behind_Master
    • 二进制日志：Binlog_Do_DB、Binlog_Ignore_DB
    • 从节点状态：Relay_Log_File、Relay_Log_Pos
  2. 监控工具：
    • Prometheus + Grafana：监控复制状态和延迟
    • Zabbix：监控系统和数据库状态
    • MySQL Enterprise Monitor：MySQL企业级监控工具
  3. 告警配置：
    • 复制中断告警：当Slave_IO_Running或Slave_SQL_Running为No时
    • 复制延迟告警：当Seconds_Behind_Master超过阈值时
    • 主节点故障告警：当主节点不可用时

# 使用Prometheus监控复制状态

cat > prometheus.yml << EOF

global:

scrape_interval: 15s

scrape_configs:

– job_name: ‘mysql’

static_configs:

– targets: [‘192.168.1.100:9104’, ‘192.168.1.101:9104’]

EOF

3.3 故障处理

TDSQL集群主从故障处理：

  1. 主节点故障：
    • 确认主节点故障：ping主节点，检查服务状态
    • 选择新主节点：选择复制延迟最小的从节点
    • 提升从节点为主节点：STOP SLAVE; RESET MASTER;
    • 重新配置其他从节点：CHANGE MASTER TO指向新主节点
    • 更新应用连接配置：更新应用的数据库连接字符串
  2. 从节点故障：
    • 确认从节点故障：ping从节点，检查服务状态
    • 修复从节点：重启服务，修复故障
    • 重新启动复制：START SLAVE;
    • 验证复制状态：SHOW SLAVE STATUS
  3. 复制中断：
    • 查看错误日志：tail -f /tdsql/log/error.log
    • 分析错误原因：根据错误信息分析原因
    • 修复错误：根据错误原因进行修复
    • 重新启动复制：START SLAVE;

# 主节点故障处理

# 在从节点上执行

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

Enter password:

Query OK, 0 rows affected (0.01 sec)

Query OK, 0 rows affected (0.01 sec)

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

Part04-生产案例与实战讲解

4.1 金融行业集群主从架构案例

案例背景：某银行核心交易系统，要求高可用性和数据安全。

架构设计：

  • 节点配置：
    • 主节点：1个，配置16核32GB内存
    • 从节点：2个，配置16核32GB内存
    • 仲裁节点：1个，配置4核8GB内存
  • 网络配置：
    • 主从节点之间使用25Gbps网络
    • 从节点部署在不同的可用区
  • 复制配置：
    • 使用半同步复制
    • 配置多线程复制
    • 监控复制延迟

性能指标：

  • 可用性：99.999%
  • 复制延迟：<100ms
  • 故障切换时间：<30秒

from tdsql视频:www.itpux.com

4.2 互联网行业集群主从架构案例

案例背景：某电商平台，要求高并发和高性能。

架构设计：

  • 节点配置：
    • 主节点：1个，配置32核64GB内存
    • 从节点：5个，配置16核32GB内存
  • 网络配置：
    • 主从节点之间使用10Gbps网络
    • 从节点部署在不同的服务器上
  • 复制配置：
    • 使用异步复制
    • 配置多线程复制
    • 使用Proxy分发读请求

性能指标：

  • 可用性：99.99%
  • 并发处理能力：>50000 QPS
  • 复制延迟：<500ms

4.3 制造业集群主从架构案例

案例背景：某制造企业ERP系统，要求稳定可靠和数据量大。

架构设计：

  • 节点配置：
    • 主节点：1个，配置16核32GB内存
    • 从节点：1个，配置16核32GB内存
  • 网络配置：
    • 主从节点之间使用1Gbps网络
    • 从节点部署在本地
  • 复制配置：
    • 使用半同步复制
    • 配置定时备份
    • 监控复制状态

性能指标：

  • 可用性：99.95%
  • 复制延迟：<1秒
  • 数据安全：零数据丢失

Part05-风哥经验总结与分享

5.1 集群主从架构最佳实践

  • 选择合适的架构类型：根据业务需求和数据量选择合适的集群主从架构类型
  • 合理配置节点数量：根据读负载，配置合适数量的从节点
  • 优化网络配置：确保主从节点之间的网络带宽足够，减少复制延迟
  • 使用高速存储：使用SSD或NVMe存储，提高IO性能
  • 建立监控系统：建立完善的监控系统，及时发现和处理问题

风哥提示：集群主从架构是提高数据库可用性和性能的重要手段，要合理设计和配置，确保系统的稳定运行。

5.2 配置最佳实践

  • 启用二进制日志：确保主节点启用二进制日志，便于复制
  • 设置合理的服务器ID：确保每个节点的服务器ID唯一
  • 配置合适的复制模式：根据业务需求选择异步、半同步或全同步复制
  • 优化复制参数：调整复制缓冲区大小、多线程复制等参数
  • 定期检查复制状态：定期检查复制状态，确保复制正常

5.3 常见问题与解决方案

常见问题及解决方法：

  • 复制中断：
    • 查看错误日志：tail -f /tdsql/log/error.log
    • 分析错误原因：根据错误信息分析原因
    • 修复错误：根据错误原因进行修复
    • 重新启动复制：START SLAVE;
  • 复制延迟：
    • 检查网络状态：ping主节点，检查网络带宽
    • 优化复制参数：调整slave_parallel_workers、slave_net_timeout等参数
    • 检查主节点负载：如果主节点负载过高，可能导致复制延迟
  • 主节点故障：
    • 确认主节点故障：ping主节点，检查服务状态
    • 选择新主节点：选择复制延迟最小的从节点
    • 提升从节点为主节点：STOP SLAVE; RESET MASTER;
    • 重新配置其他从节点：CHANGE MASTER TO指向新主节点
  • 脑裂问题：
    • 使用仲裁节点：配置仲裁节点，避免脑裂
    • 设置合理的网络超时：配置net_read_timeout、net_write_timeout等参数
    • 使用 fencing 机制：当节点发生故障时，隔离故障节点

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

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

相关推荐

联系我们

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

微信号：itpux-com

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