SlideShare a Scribd company logo
主库自动切换“漂移”
——基于zookeeper分布式选举和一致性保证


       朱金清 (穆公)

  mugong.zjq@taobao.com
    g g jq
       微博: 淘穆公
大纲
•   背景
•   基于zk的分布式选举
•   切换的数据一致性保证
•   zk的监控
•   效果页面
•   总结
背景
• 互联网应用以普通的PC服务器为主
   联 应  普 的      务 为
• 免费的开源软件: Linux平台、mysql

• 分布式系统的本质困难
 – Partial failure 部分故障
   • 如果要么一个都不坏,要么全坏,那处理简单多了
   • 无法及时准确定位出故障的原因
背景-可靠性衡量
                   背景 可靠性衡量
• 可靠性指标MTBF
   靠性指标
    – Mean Time between failures
• 1million hours的含义
    – 10 000台服务器同时运行100小时就会坏 台
      10,000台服务器同时运行100小时就会坏一台
• 服务器主要部件MTBF
    – 主板、CPU、硬盘 1million hours (厂家标称值)
    – 内存 4million hours(8根内存 ~ 1million hours)
• 整体的MTBF~1million/4=250000h~1万天
    – 年故障率约2%-4%
Ref URL: 分布式系统的工程化开发方法http://wenku.baidu.com/view/7943585c3b3567ec102d8a0f.html
背景—mysql切换
        背景 mysql切换
       的
• mysql的replication部署
• master挂了,如何?
  – 需根据IO/SQL的binlog位置
  – 因此 数据库的l d
    因此,数据库的leader
    election是有状态的分布式
    选举,不像分布式中由其它任何一台就可以替
    代 如
    代(如hbase中的HMaster)
              中的
• 着重问题:
  – 新主库的选举 / 应用程序感知
  – 选举完后各个数据的一致性保证
相关工作
        采 虚 的 式
• Master采用虚IP的方式
 – 前提:备库与主库在同一网段
   前提:备库与主库在同 网段
 – 阿里云的云聊PHPWind [1]
 – 腾讯的CDB[2]
• DB对外的接口是DNS
 – 优势:备库与主库可以在不同机房
 – 阿里云在考虑的自动切换
 – 缺点:受限于DNS,若DNS故障,服务不可用

 – [1] http://app.phpwind.com/
 – [2] http://wiki.opensns.qq.com/wiki/CDB
分布式系统常用方法
         半机 存
• Paxos:一半机器存活即可
• 实践中,常用master + lease来提高效率

• 分布式系统协调服务
     – Chubby (Google: Bigtable, MapReduce)
     – Zookeeper (Yahoo!: hbase, hadoop子项目)

•   [1] The Chubby lock service for loosely-coupled distributed systems (google论文)
•   [ ] p
    [2] http://nosql-wiki.org/wiki/bin/view/Main/ThePartTimeParliament
                  q         g
•   [3] http://hadoop.apache.org/zookeeper
•   [4] PaxosLease: PaxosLease: Diskless Paxos for Leases
我们的方式:漂移
•   拆分成很多套数据库
    拆     很多套数 库
•   Master(read only) Master slave
    Master(read-only)-Master-slave
•   数据库中间层部署在程序端,配置推送
•   采用IP的方式
•   优势
    – 备库与主库可以在不同机房
    – 不受限于
      不受限于DNS
    – 全页面操作
    – 人工情况下可以将
      主库切往任何备库
大纲
•   背景
•   基于zk的分布式选举
•   切换的数据一致性保证
•   zk的监控
•   效果页面
•   总结
zk介绍
        参考       发的 布式   务
• Yahoo!参考Chubby开发的分布式协调服务
 – Chubby采用Paxos算法
   C ubby采用 a os算法
 – zk采用zab协议,基于TCP来保证消息有序性


• 服务器端Java实现,客户端目前支持Perl,
             实
  Python,Java,C等编程语言(有第三方
  PHP)

• 我们的系统(漂移):C++ / PHP
zookeeper的配置
• Stand alone模式 & Cluster模式
  Stand-alone模式
  – 有三种端口配置
    • 客户端通信端口
    • 服务器通信端口
    • 服务器选举端口
• 超时设置(2~20倍限制)
  超时设置(    倍限制)
  – zk服务器之间的超时
    • initLimit (连接+同步)
    • syncLimit (同步)
  – 客户端程序与zk的超时
    • zookeeper_init(host, wacher, int recv_timeout …);
主库切换逻辑
                              watcher
                  /lock       事件
• 主库切换选举
   库 换
                          /x-0001
 – 每个mysql的客户端对应一个节点
   每个 ysq 的客户端对应 个节点
 – 主库对应的节点为第一个节点          /x-0002

 – 若主库挂了 节点消失
   若主库挂了,节点消失             /x-0003
 – 发起选举,只有一个节点获得lock
                              watcher
   即成为新主库                     事件
部署场景
• 可靠的zk集群保障
   靠的 集 保障
     机器可靠性可以保障
 – zk机器可靠性可以保障
 – 半数以上机器存活即可
 – 稳定的第三方
• 场景:有三个机房
 – zk部署在三个机房
 – mysql:3 4 6
   mysql:3,4,6
 – mysql:agent=1:1
主库切换的触发条件
        常
• agent异常
   a :age 异常退出
 – a1:agent异常退出
 – a2:agent与mysql的通信异常
 – a3 agent与zk之间的网络异常
   a3:agent与zk之间的网络异常
 – a4:机器死机
• mysql数据库
 – m1:访问异常
 – m2:机器死机(同a4)
    3 机器的网络异常(同 3)
 – m3:机器的网络异常(同a3)
 – m4:所在的整个机房down掉
主库切换的触发条件-agent
  主库切换的触发条件 agent
      常
• a1:异常退出
 – 要求在recv_timeout的时间内可重启
   要求在 ec     eou 的时间内可重启
 – 否则将会进行切换
   • 需要记住client端的session
   • 否则进行自动recover
   • 无法设置read only 需第三方
     无法设置read-only,需第三方
• a2:与mysql的通信异常
 – 与mysql进行读写测试
 – 重试机制,重试次数、间隔可控制
 – 若mysql正常,通信问题可以忽略(同一台机器)
主库切换的触发条件-agent(2)
 主库切换的触发条件 agent(2)
          的 络 常
• a3:与zk之间的网络异常(设置read-only)
 – 通过超时来控制,大于recv_timeout则切换
   通过超时来控制,大于 ec     eou 则切换
 – 由于session的绑定无法恢复,需进行切换
   4 机器死机(设置 d l )
• a4:机器死机(设置read-only)
 – agent与zk的通信中断
 – 在大于recv_timeout之后
   进行自动切换
主库切换的触发条件-mysql
  主库切换的触发条件 mysql
     访问异常
• m1:访问异常
 • 定期进行读写(设置read-only)
   – 主库:插入时间戳(可重试,重试间隔可设置)
     » 若mysql连接被kill掉,重新创建连接
   – 从库 读取时间戳(同上)
     从库:读取时间戳(同上)
   – 若异常,认为mysql挂断,进行切换
• m2:机器死机(同a4)
• m3:机器的网络异常(同a3)
      在的整个机房    掉
• m4:所在的整个机房down掉
 • zookeeper也挂掉,被踢出集群
 • 类似于mysql机器与majority隔离
   发起自动切换
故障测试—影响写入时间
   故障测试 影响写入时间
• 1. 超时
     超时设置4秒钟
          秒




• 影响写入的时间为4 5秒钟
  影响写入的时间为4-5秒钟。
故障测试—mysql挂掉
   故障测试 mysql挂掉
• 按照设置的检测超时来定(即为影响写入
  的时间)
故障测试—watch事件的迁移
 故障测试 watch事件的迁移
    集  结点各有     事件
• zk集群上结点各有watch事件

• Client A注册上来后watch比如在zk的M上
 – 如上图的,***00031结点
• 将zk的M进行shutdown
• 再进行主库切换,发现Client A成为主库

 – Watch照样生效,即watch可以在zk间无缝迁移
故障测试—agent的自动重启
 故障测试 agent的自动重启
       的  某种 度代表  库的
• agent的退出某种程度代表了主库的退出
 – 1. 自动重启agent (需要将sess o 保持到本地)
      自动重启age (需要将session保持到本地)
 – [REF: hadoop the definitive guide chapter 13]
大纲
•   背景
•   基于zk的分布式选举
•   切换的数据一致性保证
•   zk的监控
•   效果页面
•   总结
数据可能丢失的地方




• 挂掉的master的binlog能否获取到
• Slave机器上的relay-log损坏

 REF : http://code.google.com/p/mysql-master-ha/
数据可能丢失的地方-Cont.
   数据可能丢失的地方 Cont
        能
• binlog能否获取到
    ss 获取直接获取
  – ssh获取直接获取
  – 否则,semi-replication
    • DBA自己开发的ESR
  – 采用DRC:
    • DBA自己开发的类IO线程的模块
    • Slave机器上的relay-log损坏
• Slave的relay-log损坏
  – 判断Exec和Read的pos
  – 若无法相等说明可能有丢失
大纲
•   背景
•   基于zk的分布式选举
•   切换的数据一致性保证
•   zk的监控
•   效果页面
•   总结
官方支持的监控
• 4-letter monitoring (mntr)
• jmx监控




URL: http://zookeeper.apache.org/doc/r3.3.3/zookeeperJMX.html
4-letter
      4 letter monitoring
• 版本
  版本3.3.3需要添加patch-744方可(ant编译)
            加               编
• 版本3 4自动支持(另外,3 4引入observer)
  版本3.4自动支持(另外,3.4引入observer)
• mntr监控
Ganglia监控
Nagios监控
• http://127.0.0.1/nagios/
大纲
•   背景
•   基于zk的分布式选举
•   切换的数据一致性保证
•   zk的监控
•   效果页面
•   总结
漂移切换界面
大纲
•   背景
•   基于zk的分布式选举
•   切换的数据一致性保证
•   zk的监控
•   效果页面
•   总结
总结
• 主从库构成分布式环境,但是有状态
    库构  布式 境   有 态
 – 确保agent可重启,可以任意次重启
   确保age 可重启,可以任意次重启
 – 但是有超时限制


• 主库切换逻辑可以通过zookeeper实现
 – 锁的升级实现


• read-only的设置显得尤为重要,
• 故障切换 + APP切换
Q&A
微博:
http://www.weibo.com/suinking
Email: mugong.zjq@taobao.com
Email mugong zjq@taobao com
关注方向: mysql、hbase、HDFS

More Related Content

PDF
基于MHA的MySQL高可用方案
PDF
美团点评技术沙龙010-美团Atlas实践
PDF
美团点评技术沙龙010-Redis Cluster运维实践
PDF
淘宝主备数据库自动切换
PDF
主库自动切换 V2.0
PPTX
Track2 -刘继伟--openstack in gamewave
PPT
Mysql展示功能与源码对应
PPTX
My sql 5.6新特性深入剖析——innodb引擎
基于MHA的MySQL高可用方案
美团点评技术沙龙010-美团Atlas实践
美团点评技术沙龙010-Redis Cluster运维实践
淘宝主备数据库自动切换
主库自动切换 V2.0
Track2 -刘继伟--openstack in gamewave
Mysql展示功能与源码对应
My sql 5.6新特性深入剖析——innodb引擎

What's hot (20)

PDF
Mvcc (oracle, innodb, postgres)
PDF
再生龍於雲端環境之應用
PDF
Nova与虚拟机管理
PPTX
InnoDB Transaction Lock and MVCC
PDF
Oracle rac资源管理算法与cache fusion实现浅析
PPTX
线上问题排查交流
PDF
Web性能测试指标参考v0.2
PDF
Ceph in UnitedStack
PDF
基于OpenResty的百万级长连接推送
PDF
Bypat博客出品-服务器运维集群方法总结3
PPTX
硬件体系架构浅析
DOC
Mysql proxy+mysql-mmm
PPT
Traffic server overview
PDF
2011 06-12-lamp-mysql-顾春江
PDF
Golang 高性能实战
PPTX
Cgroup lxc在17173 iaas应用池中应用
PPT
Effective linux.3.(diagnosis)
PDF
Apache trafficserver
PPT
Aswan&hump
PPTX
MySQL压力测试经验
Mvcc (oracle, innodb, postgres)
再生龍於雲端環境之應用
Nova与虚拟机管理
InnoDB Transaction Lock and MVCC
Oracle rac资源管理算法与cache fusion实现浅析
线上问题排查交流
Web性能测试指标参考v0.2
Ceph in UnitedStack
基于OpenResty的百万级长连接推送
Bypat博客出品-服务器运维集群方法总结3
硬件体系架构浅析
Mysql proxy+mysql-mmm
Traffic server overview
2011 06-12-lamp-mysql-顾春江
Golang 高性能实战
Cgroup lxc在17173 iaas应用池中应用
Effective linux.3.(diagnosis)
Apache trafficserver
Aswan&hump
MySQL压力测试经验
Ad

Similar to MySQL自动切换设计与实现 (20)

PDF
Bypat博客出品-服务器运维集群方法总结2
PPTX
Nosql三步曲
PDF
Bypat博客出品-服务器运维集群方法总结
PDF
MySQL多机房容灾设计(with Multi-Master)
PDF
ElasticSearch Training#2 (advanced concepts)-ESCC#1
PDF
基于MySQL开放复制协议的同步扩展
PPT
从林书豪到全明星 - 虎扑网技术架构如何化解流量高峰
PDF
Hacking Nginx at Taobao
PPTX
云端的数据库
PDF
豆瓣网技术架构变迁
PDF
Redis在唯品会的应用实践.pdf
PDF
Databases on AWS
PDF
Kvmopt osforce
PPTX
1到100000000 - 分布式大型网站的架构设计
PPTX
Notes of jcip
PDF
廣宣學堂: 企業導入微服務實戰
PDF
企業導入微服務實戰 - updated
PDF
Linux system security
PDF
合久必分,分久必合
Bypat博客出品-服务器运维集群方法总结2
Nosql三步曲
Bypat博客出品-服务器运维集群方法总结
MySQL多机房容灾设计(with Multi-Master)
ElasticSearch Training#2 (advanced concepts)-ESCC#1
基于MySQL开放复制协议的同步扩展
从林书豪到全明星 - 虎扑网技术架构如何化解流量高峰
Hacking Nginx at Taobao
云端的数据库
豆瓣网技术架构变迁
Redis在唯品会的应用实践.pdf
Databases on AWS
Kvmopt osforce
1到100000000 - 分布式大型网站的架构设计
Notes of jcip
廣宣學堂: 企業導入微服務實戰
企業導入微服務實戰 - updated
Linux system security
合久必分,分久必合
Ad

More from orczhou (8)

PPTX
2012 dtcc-itpub-runing-critical-data-on-mysql
PPT
MySQL Replication新功能介绍
PPTX
飞信核心库Ha设计及实现
PPT
海量数据迁移方案
PPTX
MySQL新技术研究与实践
PPTX
Manage MySQL with open source
PPTX
MySQL Replication
PPTX
MySQL Replication
2012 dtcc-itpub-runing-critical-data-on-mysql
MySQL Replication新功能介绍
飞信核心库Ha设计及实现
海量数据迁移方案
MySQL新技术研究与实践
Manage MySQL with open source
MySQL Replication
MySQL Replication

MySQL自动切换设计与实现

  • 1. 主库自动切换“漂移” ——基于zookeeper分布式选举和一致性保证 朱金清 (穆公) mugong.zjq@taobao.com g g jq 微博: 淘穆公
  • 2. 大纲 • 背景 • 基于zk的分布式选举 • 切换的数据一致性保证 • zk的监控 • 效果页面 • 总结
  • 3. 背景 • 互联网应用以普通的PC服务器为主 联 应 普 的 务 为 • 免费的开源软件: Linux平台、mysql • 分布式系统的本质困难 – Partial failure 部分故障 • 如果要么一个都不坏,要么全坏,那处理简单多了 • 无法及时准确定位出故障的原因
  • 4. 背景-可靠性衡量 背景 可靠性衡量 • 可靠性指标MTBF 靠性指标 – Mean Time between failures • 1million hours的含义 – 10 000台服务器同时运行100小时就会坏 台 10,000台服务器同时运行100小时就会坏一台 • 服务器主要部件MTBF – 主板、CPU、硬盘 1million hours (厂家标称值) – 内存 4million hours(8根内存 ~ 1million hours) • 整体的MTBF~1million/4=250000h~1万天 – 年故障率约2%-4% Ref URL: 分布式系统的工程化开发方法http://wenku.baidu.com/view/7943585c3b3567ec102d8a0f.html
  • 5. 背景—mysql切换 背景 mysql切换 的 • mysql的replication部署 • master挂了,如何? – 需根据IO/SQL的binlog位置 – 因此 数据库的l d 因此,数据库的leader election是有状态的分布式 选举,不像分布式中由其它任何一台就可以替 代 如 代(如hbase中的HMaster) 中的 • 着重问题: – 新主库的选举 / 应用程序感知 – 选举完后各个数据的一致性保证
  • 6. 相关工作 采 虚 的 式 • Master采用虚IP的方式 – 前提:备库与主库在同一网段 前提:备库与主库在同 网段 – 阿里云的云聊PHPWind [1] – 腾讯的CDB[2] • DB对外的接口是DNS – 优势:备库与主库可以在不同机房 – 阿里云在考虑的自动切换 – 缺点:受限于DNS,若DNS故障,服务不可用 – [1] http://app.phpwind.com/ – [2] http://wiki.opensns.qq.com/wiki/CDB
  • 7. 分布式系统常用方法 半机 存 • Paxos:一半机器存活即可 • 实践中,常用master + lease来提高效率 • 分布式系统协调服务 – Chubby (Google: Bigtable, MapReduce) – Zookeeper (Yahoo!: hbase, hadoop子项目) • [1] The Chubby lock service for loosely-coupled distributed systems (google论文) • [ ] p [2] http://nosql-wiki.org/wiki/bin/view/Main/ThePartTimeParliament q g • [3] http://hadoop.apache.org/zookeeper • [4] PaxosLease: PaxosLease: Diskless Paxos for Leases
  • 8. 我们的方式:漂移 • 拆分成很多套数据库 拆 很多套数 库 • Master(read only) Master slave Master(read-only)-Master-slave • 数据库中间层部署在程序端,配置推送 • 采用IP的方式 • 优势 – 备库与主库可以在不同机房 – 不受限于 不受限于DNS – 全页面操作 – 人工情况下可以将 主库切往任何备库
  • 9. 大纲 • 背景 • 基于zk的分布式选举 • 切换的数据一致性保证 • zk的监控 • 效果页面 • 总结
  • 10. zk介绍 参考 发的 布式 务 • Yahoo!参考Chubby开发的分布式协调服务 – Chubby采用Paxos算法 C ubby采用 a os算法 – zk采用zab协议,基于TCP来保证消息有序性 • 服务器端Java实现,客户端目前支持Perl, 实 Python,Java,C等编程语言(有第三方 PHP) • 我们的系统(漂移):C++ / PHP
  • 11. zookeeper的配置 • Stand alone模式 & Cluster模式 Stand-alone模式 – 有三种端口配置 • 客户端通信端口 • 服务器通信端口 • 服务器选举端口 • 超时设置(2~20倍限制) 超时设置( 倍限制) – zk服务器之间的超时 • initLimit (连接+同步) • syncLimit (同步) – 客户端程序与zk的超时 • zookeeper_init(host, wacher, int recv_timeout …);
  • 12. 主库切换逻辑 watcher /lock 事件 • 主库切换选举 库 换 /x-0001 – 每个mysql的客户端对应一个节点 每个 ysq 的客户端对应 个节点 – 主库对应的节点为第一个节点 /x-0002 – 若主库挂了 节点消失 若主库挂了,节点消失 /x-0003 – 发起选举,只有一个节点获得lock watcher 即成为新主库 事件
  • 13. 部署场景 • 可靠的zk集群保障 靠的 集 保障 机器可靠性可以保障 – zk机器可靠性可以保障 – 半数以上机器存活即可 – 稳定的第三方 • 场景:有三个机房 – zk部署在三个机房 – mysql:3 4 6 mysql:3,4,6 – mysql:agent=1:1
  • 14. 主库切换的触发条件 常 • agent异常 a :age 异常退出 – a1:agent异常退出 – a2:agent与mysql的通信异常 – a3 agent与zk之间的网络异常 a3:agent与zk之间的网络异常 – a4:机器死机 • mysql数据库 – m1:访问异常 – m2:机器死机(同a4) 3 机器的网络异常(同 3) – m3:机器的网络异常(同a3) – m4:所在的整个机房down掉
  • 15. 主库切换的触发条件-agent 主库切换的触发条件 agent 常 • a1:异常退出 – 要求在recv_timeout的时间内可重启 要求在 ec eou 的时间内可重启 – 否则将会进行切换 • 需要记住client端的session • 否则进行自动recover • 无法设置read only 需第三方 无法设置read-only,需第三方 • a2:与mysql的通信异常 – 与mysql进行读写测试 – 重试机制,重试次数、间隔可控制 – 若mysql正常,通信问题可以忽略(同一台机器)
  • 16. 主库切换的触发条件-agent(2) 主库切换的触发条件 agent(2) 的 络 常 • a3:与zk之间的网络异常(设置read-only) – 通过超时来控制,大于recv_timeout则切换 通过超时来控制,大于 ec eou 则切换 – 由于session的绑定无法恢复,需进行切换 4 机器死机(设置 d l ) • a4:机器死机(设置read-only) – agent与zk的通信中断 – 在大于recv_timeout之后 进行自动切换
  • 17. 主库切换的触发条件-mysql 主库切换的触发条件 mysql 访问异常 • m1:访问异常 • 定期进行读写(设置read-only) – 主库:插入时间戳(可重试,重试间隔可设置) » 若mysql连接被kill掉,重新创建连接 – 从库 读取时间戳(同上) 从库:读取时间戳(同上) – 若异常,认为mysql挂断,进行切换 • m2:机器死机(同a4) • m3:机器的网络异常(同a3) 在的整个机房 掉 • m4:所在的整个机房down掉 • zookeeper也挂掉,被踢出集群 • 类似于mysql机器与majority隔离 发起自动切换
  • 18. 故障测试—影响写入时间 故障测试 影响写入时间 • 1. 超时 超时设置4秒钟 秒 • 影响写入的时间为4 5秒钟 影响写入的时间为4-5秒钟。
  • 19. 故障测试—mysql挂掉 故障测试 mysql挂掉 • 按照设置的检测超时来定(即为影响写入 的时间)
  • 20. 故障测试—watch事件的迁移 故障测试 watch事件的迁移 集 结点各有 事件 • zk集群上结点各有watch事件 • Client A注册上来后watch比如在zk的M上 – 如上图的,***00031结点 • 将zk的M进行shutdown • 再进行主库切换,发现Client A成为主库 – Watch照样生效,即watch可以在zk间无缝迁移
  • 21. 故障测试—agent的自动重启 故障测试 agent的自动重启 的 某种 度代表 库的 • agent的退出某种程度代表了主库的退出 – 1. 自动重启agent (需要将sess o 保持到本地) 自动重启age (需要将session保持到本地) – [REF: hadoop the definitive guide chapter 13]
  • 22. 大纲 • 背景 • 基于zk的分布式选举 • 切换的数据一致性保证 • zk的监控 • 效果页面 • 总结
  • 24. 数据可能丢失的地方-Cont. 数据可能丢失的地方 Cont 能 • binlog能否获取到 ss 获取直接获取 – ssh获取直接获取 – 否则,semi-replication • DBA自己开发的ESR – 采用DRC: • DBA自己开发的类IO线程的模块 • Slave机器上的relay-log损坏 • Slave的relay-log损坏 – 判断Exec和Read的pos – 若无法相等说明可能有丢失
  • 25. 大纲 • 背景 • 基于zk的分布式选举 • 切换的数据一致性保证 • zk的监控 • 效果页面 • 总结
  • 26. 官方支持的监控 • 4-letter monitoring (mntr) • jmx监控 URL: http://zookeeper.apache.org/doc/r3.3.3/zookeeperJMX.html
  • 27. 4-letter 4 letter monitoring • 版本 版本3.3.3需要添加patch-744方可(ant编译) 加 编 • 版本3 4自动支持(另外,3 4引入observer) 版本3.4自动支持(另外,3.4引入observer) • mntr监控
  • 30. 大纲 • 背景 • 基于zk的分布式选举 • 切换的数据一致性保证 • zk的监控 • 效果页面 • 总结
  • 32. 大纲 • 背景 • 基于zk的分布式选举 • 切换的数据一致性保证 • zk的监控 • 效果页面 • 总结
  • 33. 总结 • 主从库构成分布式环境,但是有状态 库构 布式 境 有 态 – 确保agent可重启,可以任意次重启 确保age 可重启,可以任意次重启 – 但是有超时限制 • 主库切换逻辑可以通过zookeeper实现 – 锁的升级实现 • read-only的设置显得尤为重要, • 故障切换 + APP切换