1. 首页 > 国产数据库教程 > PolarDB教程 > 正文

polardb教程FG014-PolarDB高可用与灾难恢复

本文档风哥主要介绍PolarDB高可用与灾难恢复,包括高可用基础概念、灾难恢复原理、可用性级别、高可用规划与设计、灾难恢复计划、风险评估与管理、高可用实施方案、灾难恢复实施方案、监控与告警、高可用实战、灾难恢复实战、故障切换实战等内容,风哥教程参考PolarDB官方文档内容编写,适合DBA人员在学习和测试中使用,如果要应用于生产环境则需要自行确认。更多视频教程www.fgedu.net.cn

Part01-基础概念与理论知识

1.1 高可用基础概念

高可用是指系统在面对各种故障时,能够保持服务的连续性和可用性。高可用是数据库系统的重要特性,直接影响业务的连续性和可靠性。

高可用的核心概念:

  • 可用性:系统能够正常提供服务的时间比例
  • 故障:导致系统无法正常提供服务的事件
  • 故障切换:当主节点故障时,切换到备用节点的过程
  • 恢复时间目标(RTO):从故障发生到系统恢复的时间
  • 恢复点目标(RPO):故障发生后,系统能够恢复到的最近时间点

1.2 灾难恢复原理

灾难恢复是指在灾难发生后,恢复系统的正常运行。灾难恢复是高可用的重要组成部分,能够在严重故障或灾难发生时,确保系统的恢复。

# 灾难恢复的核心内容
– 灾难:导致系统严重损坏或完全不可用的事件
– 灾难恢复:在灾难发生后,恢复系统的正常运行
– 灾难恢复计划:制定灾难恢复的步骤和流程
– 灾难恢复演练:定期演练灾难恢复过程,确保其有效性

# 灾难恢复的步骤
1. 灾难检测:检测灾难的发生
2. 灾难评估:评估灾难的影响范围和程度
3. 启动恢复:启动灾难恢复计划
4. 执行恢复:执行恢复操作
5. 验证恢复:验证系统是否恢复正常
6. 恢复服务:恢复业务服务

1.3 可用性级别

可用性级别是指系统的可用程度,通常用几个9来表示。

风哥提示:高可用与灾难恢复是PolarDB运维的重要组成部分,直接影响业务的连续性和可靠性。建议DBA人员熟悉高可用与灾难恢复的相关知识和操作。学习交流加群风哥微信: itpux-com

Part02-生产环境规划与建议

2.1 高可用规划与设计

高可用规划与设计是指根据业务需求,制定合理的高可用方案,确保系统的可用性。

# 高可用规划与设计的步骤
1. 分析业务需求:了解业务的可用性要求、RTO和RPO要求
2. 评估风险:评估可能的故障类型和影响
3. 选择高可用方案:根据业务需求选择合适的高可用方案
4. 设计架构:设计高可用架构,包括节点数量、网络拓扑等
5. 测试验证:在测试环境中验证高可用方案的有效性

# 高可用方案
– 主从复制:主节点处理读写请求,从节点作为备用
– 多主复制:多个主节点同时处理读写请求
– 集群:多个节点组成集群,共同提供服务
– 异地多活:在不同地域部署多个实例,实现异地容灾

# 高可用架构设计
– 节点数量:根据业务需求和可用性要求确定节点数量
– 网络拓扑:设计合理的网络拓扑,确保节点间通信顺畅
– 存储方案:选择合适的存储方案,确保数据一致性
– 监控系统:配置合理的监控系统,及时发现和解决问题

2.2 灾难恢复计划

灾难恢复计划是指制定灾难恢复的步骤和流程,确保在灾难发生时能够快速恢复系统。

# 灾难恢复计划的内容
1. 灾难定义:定义什么是灾难
2. 恢复步骤:详细的灾难恢复操作步骤
3. 恢复团队:负责灾难恢复的人员
4. 恢复工具:需要使用的恢复工具
5. 恢复时间:预计的恢复时间
6. 恢复验证:恢复后的验证步骤
7. 回滚计划:恢复失败的回滚计划

# 灾难恢复计划示例
– 灾难类型:数据中心故障
– 恢复步骤:
1. 检测灾难
2. 评估影响
3. 启动异地备份
4. 恢复系统
5. 验证恢复
6. 恢复服务

# 灾难恢复演练
– 定期演练:每年执行一次灾难恢复演练
– 演练环境:在模拟环境中执行演练
– 演练记录:记录演练结果和问题
– 演练改进:根据演练结果改进灾难恢复计划

2.3 风险评估与管理

风险评估与管理是指评估系统可能面临的风险,并采取措施降低风险。

# 风险评估的步骤
1. 识别风险:识别系统可能面临的风险
2. 评估风险:评估风险的可能性和影响程度
3. 制定措施:制定降低风险的措施
4. 实施措施:实施降低风险的措施
5. 监控风险:监控风险的变化

# 常见风险
– 硬件故障:服务器、存储、网络等硬件故障
– 软件故障:操作系统、数据库等软件故障
– 人为错误:误操作、配置错误等
– 自然灾害:地震、洪水、火灾等
– 网络攻击:黑客攻击、病毒感染等

# 风险降低措施
– 冗余设计:设计冗余的硬件和软件
– 备份策略:制定合理的备份策略
– 监控系统:配置合理的监控系统
– 安全措施:实施安全措施,防止网络攻击
– 灾难恢复计划:制定灾难恢复计划

生产环境建议:根据业务需求和可用性要求,制定合理的高可用方案和灾难恢复计划,确保系统的可用性和可靠性。学习交流加群风哥QQ113257174

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

3.1 高可用实施方案

3.1.1 主从复制

# 配置主从复制
# 步骤1:在主库上创建复制用户
mysql> CREATE USER ‘repl’@’%’ IDENTIFIED BY ‘password’;
Query OK, 0 rows affected (0.01 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO ‘repl’@’%’;
Query OK, 0 rows affected (0.01 sec)

# 步骤2:在主库上查看binlog位置
mysql> SHOW MASTER STATUS;
+——————+———-+————–+——————+——————-+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+——————+———-+————–+——————+——————-+
| mysql-bin.000001 | 12345 | | | |
+——————+———-+————–+——————+——————-+

# 步骤3:在从库上配置主从复制
mysql> CHANGE MASTER TO
-> MASTER_HOST=’pc-12345678.mysql.polardb.rds.aliyuncs.com’,
-> MASTER_USER=’repl’,
-> MASTER_PASSWORD=’password’,
-> MASTER_LOG_FILE=’mysql-bin.000001′,
-> MASTER_LOG_POS=12345;
Query OK, 0 rows affected, 2 warnings (0.01 sec)

# 步骤4:启动从库复制
mysql> START SLAVE;
Query OK, 0 rows affected (0.01 sec)

# 步骤5:查看从库状态
mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: pc-12345678.mysql.polardb.rds.aliyuncs.com
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 12345
Relay_Log_File: relay-bin.000001
Relay_Log_Pos: 12345
Relay_Master_Log_File: mysql-bin.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: 12345
Relay_Log_Space: 12345
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-1234567890ab
Master_Info_File: mysql.slave_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:
1 row in set (0.00 sec)

3.1.2 多主复制

# 配置多主复制
# 步骤1:在每个节点上启用GTID
# 修改my.cnf文件
[mysqld]
gtid_mode = ON
enforce_gtid_consistency = ON

# 步骤2:在每个节点上创建复制用户
mysql> CREATE USER ‘repl’@’%’ IDENTIFIED BY ‘password’;
Query OK, 0 rows affected (0.01 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO ‘repl’@’%’;
Query OK, 0 rows affected (0.01 sec)

# 步骤3:在节点1上配置复制到节点2
mysql> CHANGE MASTER TO
-> MASTER_HOST=’pc-12345679.mysql.polardb.rds.aliyuncs.com’,
-> MASTER_USER=’repl’,
-> MASTER_PASSWORD=’password’,
-> MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected, 2 warnings (0.01 sec)

# 步骤4:在节点2上配置复制到节点1
mysql> CHANGE MASTER TO
-> MASTER_HOST=’pc-12345678.mysql.polardb.rds.aliyuncs.com’,
-> MASTER_USER=’repl’,
-> MASTER_PASSWORD=’password’,
-> MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected, 2 warnings (0.01 sec)

# 步骤5:启动复制
mysql> START SLAVE;
Query OK, 0 rows affected (0.01 sec)

# 步骤6:查看复制状态
mysql> SHOW SLAVE STATUS\G;

3.1.3 集群

# 配置PolarDB集群
# 步骤1:登录阿里云控制台
# 步骤2:进入PolarDB管理控制台
# 步骤3:点击”创建集群”
# 步骤4:选择集群类型和规格
# 步骤5:设置集群名称和描述
# 步骤6:选择可用区和网络
# 步骤7:设置数据库版本和参数
# 步骤8:点击”创建”
# 步骤9:等待集群创建完成

# 查看集群状态
$ aliyun polardb DescribeDBClusters \
–DBClusterId “pc-12345678”

# 查看节点状态
$ aliyun polardb DescribeDBNodes \
–DBClusterId “pc-12345678”

3.2 灾难恢复实施方案

3.2.1 异地备份

# 配置异地备份
# 步骤1:登录阿里云控制台
# 步骤2:进入PolarDB管理控制台
# 步骤3:选择实例
# 步骤4:点击”备份恢复”
# 步骤5:点击”备份设置”
# 步骤6:开启异地备份
# 步骤7:选择异地备份区域
# 步骤8:点击”确定”

# 查看异地备份
$ aliyun polardb DescribeDBClusterBackups \
–DBClusterId “pc-12345678”

# 使用异地备份恢复
$ aliyun polardb RestoreDBCluster \
–DBClusterId “pc-12345678” \
–RestoreTime “2026-03-31T10:00:00Z” \
–RestoreType “Backup”

3.2.2 异地多活

# 配置异地多活
# 步骤1:在不同地域创建PolarDB实例
# 步骤2:配置主从复制,实现数据同步
# 步骤3:配置应用程序,实现故障自动切换
# 步骤4:测试异地多活功能

# 配置主从复制
mysql> CHANGE MASTER TO
-> MASTER_HOST=’pc-12345678.mysql.polardb.rds.aliyuncs.com’,
-> MASTER_USER=’repl’,
-> MASTER_PASSWORD=’password’,
-> MASTER_LOG_FILE=’mysql-bin.000001′,
-> MASTER_LOG_POS=12345;
Query OK, 0 rows affected, 2 warnings (0.01 sec)

# 启动复制
mysql> START SLAVE;
Query OK, 0 rows affected (0.01 sec)

# 查看复制状态
mysql> SHOW SLAVE STATUS\G;

3.3 监控与告警

监控与告警是指对高可用和灾难恢复系统进行监控,及时发现和解决问题。

# 配置监控
# 步骤1:登录阿里云控制台
# 步骤2:进入云监控管理控制台
# 步骤3:点击”创建监控面板”
# 步骤4:选择PolarDB实例
# 步骤5:添加监控指标,如CPU使用率、内存使用率、IOPS等
# 步骤6:设置告警规则
# 步骤7:点击”保存”

# 监控指标
– 实例状态:实例是否正常运行
– 复制状态:主从复制是否正常
– 资源使用率:CPU、内存、存储等资源的使用率
– 性能指标:QPS、TPS、响应时间等
– 错误日志:实例的错误日志

# 告警规则
– CPU使用率超过80%,持续5分钟
– 内存使用率超过90%,持续5分钟
– 复制延迟超过300秒
– 实例状态异常

风哥提示:监控与告警是确保高可用和灾难恢复系统正常运行的重要手段,建议配置合理的监控指标和告警规则,及时发现和解决问题。更多学习教程公众号风哥教程itpux_com

Part04-生产案例与实战讲解

4.1 高可用实战

高可用实战:

# 配置主从复制
# 步骤1:在主库上创建复制用户
mysql> CREATE USER ‘repl’@’%’ IDENTIFIED BY ‘password’;
Query OK, 0 rows affected (0.01 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO ‘repl’@’%’;
Query OK, 0 rows affected (0.01 sec)

# 步骤2:在主库上查看binlog位置
mysql> SHOW MASTER STATUS;
+——————+———-+————–+——————+——————-+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+——————+———-+————–+——————+——————-+
| mysql-bin.000001 | 12345 | | | |
+——————+———-+————–+——————+——————-+

# 步骤3:在从库上配置主从复制
mysql> CHANGE MASTER TO
-> MASTER_HOST=’pc-12345678.mysql.polardb.rds.aliyuncs.com’,
-> MASTER_USER=’repl’,
-> MASTER_PASSWORD=’password’,
-> MASTER_LOG_FILE=’mysql-bin.000001′,
-> MASTER_LOG_POS=12345;
Query OK, 0 rows affected, 2 warnings (0.01 sec)

# 步骤4:启动从库复制
mysql> START SLAVE;
Query OK, 0 rows affected (0.01 sec)

# 步骤5:查看从库状态
mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: pc-12345678.mysql.polardb.rds.aliyuncs.com
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 12345
Relay_Log_File: relay-bin.000001
Relay_Log_Pos: 12345
Relay_Master_Log_File: mysql-bin.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: 12345
Relay_Log_Space: 12345
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-1234567890ab
Master_Info_File: mysql.slave_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:
1 row in set (0.00 sec)

# 测试主从复制
# 在主库上插入数据
mysql> INSERT INTO fgedudb.fgedu_user (name, age, email) VALUES (‘test4’, 23, ‘test4@example.com’);
Query OK, 1 row affected (0.01 sec)

# 在从库上查看数据
mysql> SELECT * FROM fgedudb.fgedu_user;
+—-+——-+—–+——————+
| id | name | age | email |
+—-+——-+—–+——————+
| 1 | test1 | 20 | test1@example.com |
| 2 | test2 | 21 | test2@example.com |
| 3 | test3 | 22 | test3@example.com |
| 4 | test4 | 23 | test4@example.com |
+—-+——-+—–+——————+

4.2 灾难恢复实战

灾难恢复实战:

# 灾难恢复场景:主库所在数据中心故障

# 步骤1:检测灾难
# 通过监控系统发现主库所在数据中心故障

# 步骤2:评估影响
# 主库不可用,业务无法正常运行

# 步骤3:启动灾难恢复计划
# 切换到异地备份实例

# 步骤4:执行恢复
# 使用阿里云CLI恢复备份
$ aliyun polardb RestoreDBCluster \
–DBClusterId “pc-12345678” \
–RestoreTime “2026-03-31T10:00:00Z” \
–RestoreType “Backup”

# 查看恢复状态
$ aliyun polardb DescribeDBClusters \
–DBClusterId “pc-12345678”

# 步骤5:验证恢复
# 登录新实例,验证数据是否完整
$ mysql -u fgedu -p -h pc-12345678.mysql.polardb.rds.aliyuncs.com -P 3306 -e “SELECT * FROM fgedudb.fgedu_user;”
Enter password:
+—-+——-+—–+——————+
| id | name | age | email |
+—-+——-+—–+——————+
| 1 | test1 | 20 | test1@example.com |
| 2 | test2 | 21 | test2@example.com |
| 3 | test3 | 22 | test3@example.com |
| 4 | test4 | 23 | test4@example.com |
+—-+——-+—–+——————+

# 步骤6:恢复服务
# 更新应用配置,将数据库连接地址改为新实例的地址
# 启动业务服务

4.3 故障切换实战

故障切换实战:

# 故障切换场景:主库故障,切换到从库

# 步骤1:检测主库故障
# 通过监控系统发现主库故障

# 步骤2:验证主库故障
# 尝试连接主库,确认主库不可用
$ mysql -u fgedu -p -h pc-12345678.mysql.polardb.rds.aliyuncs.com -P 3306 -e “SELECT 1;”
Enter password:
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2003 (HY000): Can’t connect to MySQL server on ‘pc-12345678.mysql.polardb.rds.aliyuncs.com’ (111)

# 步骤3:检查从库状态
# 确认从库复制正常,数据同步完成
mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: pc-12345678.mysql.polardb.rds.aliyuncs.com
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 23456
Relay_Log_File: relay-bin.000001
Relay_Log_Pos: 23456
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: No
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: 23456
Relay_Log_Space: 23456
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: 1045
Last_IO_Error: error connecting to master ‘repl@pc-12345678.mysql.polardb.rds.aliyuncs.com:3306’: Authentication plugin ‘caching_sha2_password’ reported error: Authentication requires secure connection.
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: mysql.slave_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:
1 row in set (0.00 sec)

# 步骤4:将从库提升为主库
mysql> STOP SLAVE;
Query OK, 0 rows affected (0.01 sec)

mysql> RESET SLAVE ALL;
Query OK, 0 rows affected (0.01 sec)

# 步骤5:更新应用配置
# 将应用的数据库连接地址改为从库的地址

# 步骤6:验证应用服务
# 启动应用服务,验证服务是否正常运行

生产环境建议:定期测试故障切换和灾难恢复操作,确保在故障发生时能够快速恢复系统,减少业务中断时间。from polardb视频:www.itpux.com

Part05-风哥经验总结与分享

5.1 最佳实践

PolarDB高可用与灾难恢复最佳实践:

  • 高可用架构:根据业务需求选择合适的高可用架构,如主从复制、多主复制、集群等
  • 灾难恢复计划:制定详细的灾难恢复计划,定期演练
  • 监控与告警:配置合理的监控指标和告警规则,及时发现和解决问题
  • 备份策略:制定合理的备份策略,确保数据安全
  • 异地容灾:部署异地备份或异地多活,提高系统的容灾能力
  • 故障切换测试:定期测试故障切换操作,确保其有效性
  • 文档管理:编写高可用与灾难恢复文档,规范操作流程
  • 定期审查:定期审查高可用与灾难恢复方案,确保其有效性

5.2 常见问题与解决

PolarDB高可用与灾难恢复常见问题与解决方法:

  • 主从复制延迟:优化网络连接,调整复制参数,使用半同步复制
  • 故障切换失败:检查从库状态,确保从库数据同步完成,优化故障切换流程
  • 灾难恢复时间过长:优化备份策略,使用增量备份,提高存储性能
  • 监控告警误报:调整告警阈值,优化监控规则
  • 权限不足:确保备份用户和复制用户有足够的权限
  • 网络问题:优化网络拓扑,确保节点间通信顺畅

PolarDB高可用与灾难恢复未来发展趋势:

  • 智能化:引入AI技术,实现故障预测和自动故障切换
  • 云原生深化:进一步融合云原生技术,提供更弹性、更高效的高可用服务
  • 多模支持:支持更多数据类型和处理模式,满足不同业务需求
  • 生态完善:加强与其他云服务的集成,提供更完整的高可用解决方案
  • 国产化替代:助力企业实现数据库高可用系统国产化替代,提升数据安全
风哥提示:PolarDB高可用与灾难恢复是数据库运维的重要组成部分,建议DBA人员熟悉相关知识和操作,确保系统的可用性和可靠性。

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

联系我们

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

微信号:itpux-com

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