为什么要做主备机房

简单来说,主备机房切换只是我们 “上云五步骤” 中的初始化环节,最终实现将我们的应用逐步逐步的搬上云:
看到这样的步骤,许多老师会萌生吐槽的极大冲动,您先别急,容我来对 “上云五步骤” 做些解释:
1、出于成本的考虑,除ucache之外(包括阿里与腾讯),没有一家供应商允许将 ‘IOE’ 搬入他们的机房,所以最终选择在 ‘ucache’ 内搭建我们的新机房,然后通过内网与ucache进行互联。
2、出于成本的考虑,专线扩容的申请被CEO驳回,最终无法实现伪双活的方案(要求拿出应用视角的流量数据提供参考,由于缺乏完美的监控体系,无法做到)。
3、出于成本的考虑,也同时考虑到将来迁移至云机房后的折旧因素,新机房的硬件投入只有老机房的50%。
除了以上三点之外,还有一些细节,因为不是重点就不一一举例了,说多了都是泪。

  • 那些客观条件下的迁移方案 -
    方案一:整体冷切
    策略:利用周末交易停止,访问量下降的环境优势,进行整体环境切换。
    方式:核心业务数据库1:0.5建立环境,核心业务应用1:0.3建立环境、非核心业务数据库直接搬迁,非核心业务应用直接搬迁
    优势:
    只须考虑搬迁设备的安全及留足设备上下架时间
    只须考虑域名及CDN切换时间
    缺点:
    整机搬迁存在设备搬迁后故障,无法启动的问题,设备搬迁的数量较多,此情况易出现,搬迁前须做好数据库导出独立存储的准备;
    设备一次性迁移数量较多,搬迁过程中上下架时间较长,加上外高桥机房对设备有严格的出入管理,报关、检查时间较长;
    当发现备节点无法承接业务时,回退时间较长;
    停机时间较长;
    方案二:降级冷切
    策略:利用周末交易停止,访问量下降的环境优势,进行主机房降级,备机房升级的切换。
    方式:将主节点所有业务应用+数据库数量由1:0.5,将下架设备集中运往备份节点,进行环境调试,完成备份机房由0.5升级为1的过程。
    优势:
    停机时间短,预计总停机时间在数小时内(第二次切换须进行大面积程序验证,预计耗时N小时以上)
    数据风险较小,核心及非核心业务数据部分在切换前都采用热备方式进行双向同步
    提供回退保障,在备份节点业务出现无法启动情况下,可以快速将服务切换回原主节点
    在切换前可以通过提前验证的方式提高切换质量
    部分关键设备(如数据库),由单机转换成大容量虚拟机,可有效保障切换顺利
    切换时间可控性强,包括联合测试、运营进行线上检测也可灵活安排
    缺点:
    整须提前搭建环境,须前期占用一部分人力资源搭建第二套全环境
    方案三:伪双活逐步切换
    策略:两端通过负载均衡设备进行访问均衡,逐步将业务从主节点切换至备份节点。
    方式:利用机房内负载均衡设备将部分主机房流量引入备份机房,然后备份机房配置数据库实现写回源、读本地,逐步将访问全部切换至备份机房,然后直接将访问切换至备份机房。
    优势:
    访问停机少,前期分流存在多次闪断,后期有一次N分钟的DNS切换
    缺点:
    业务访问环境构建复杂,除两节点搭建前端应用外,还须快速配置后端访问节点,易出现人为操作故障(在数据库配置错误的情况下也易出现脏数据,届时对清算、交易可能产生较大的数据恢复难度)
    前端应用在未实现统一配置管理的情况下,靠人工配置危险系数极高
    双向伪双活对主备间带宽要求较高,目前X兆带宽只能保证业务数据库的同步
    产生的成本最高,线路费用、人工费用、多次搬迁存在的风险

其实,最终我们执行的是方案一和方案二的结合:
切换当天:整体冷切,将老机房的所有硬件数量由1容量,迁移至新机房的0.5容量,并通过降级、限流等手段,顺利的挺过了首个交易日。
切换后的三天内:将老机房的硬件逐步下架运往新机房,并完成备份机房由0.5升级为1的过程。

  • 最后说两句 -

Ucache灾备云企业数据备份软件提供了多种备份模式,在新建任务时,用户可自由设置各种备份模式,如单双向同步、镜像同步、移动同步等,还可以根据文件名或者目录名来选择性的备份,在设置时,选择“文件过滤”。
再比如,Ucache灾备云企业数据备份软件还具有另一个人性化的功能—定时备份,它提供了每月、每周、每日、间隔和实时多种定时方式,根据需要设置固定时间来进行数据备份。

Ucache灾备云电脑备份不仅高效稳定,而且占用的资源很少,在备份文件时也异常迅速,完全不会影响电脑速度,可以说它是国内最好的电脑备份软件,使用它为企业建立一个完善的备份与恢复的灾备体系,实现数据自动化备份容灾管理,时刻保护企业数据安全。

### 配置 MySQL 数据库复制 #### 1. 准工作 在配置 MySQL 的复制之前,需要确保服务器和从服务器都已正确安装并运行。以下是必要的准工作: - **版本一致性**:确认服务器和从服务器的 MySQL 版本一致[^1]。 - **唯一 server_id**:为服务器和从服务器分配唯一的 `server_id` 值。可以通过修改 MySQL 配置文件(通常是 `/etc/my.cnf` 或 `/etc/mysql/my.cnf`),添加如下内容: ```ini [mysqld] server-id=1 # 对于服务器设置为1 log-bin=mysql-bin # 开启二进制日志功能 ``` 对于从服务器,则需将其 `server_id` 设置为其他值,例如 `2`。 #### 2. 创建复制账户 为了使从服务器能够连接到服务器获取更新记录,在服务器上创建一个用于复制操作的专用用户账号。执行以下 SQL 语句完成此过程: ```sql CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'Password@2024'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES; ``` 以上命令会创建名为 `repl` 的用户,并赋予其所需的权限以便进行数据同步[^1]。 #### 3. 获取服务器状态信息 登录至服务器上的 MySQL 客户端界面,输入下列指令来查看当前二进制日志的位置以及文件名: ```sql SHOW MASTER STATUS; ``` 这一步骤非常重要,因为稍后当我们在从服务器启动复制进程的时候需要用到这些参数。 #### 4. 配置从服务器 接着转到从服务器环境里做相应的调整。同样编辑该机器中的 MySQL 配置文档加入下面几项设定: ```ini [mysqld] server-id=2 # 设定不同于服务端ID号 relay-log=slave-relay-bin log-slave-updates=true read-only=true # 可选项目,建议开启只读模式防止意外写入破坏数据一致性. ``` 重启 MySQL 服务让更改生效之后再次进入 CLI 工具下发出变更通知给 Slave Node: ```sql CHANGE MASTER TO MASTER_HOST='<Master_IP>', -- 替换为实际IP地址或者域名解析后的数值形式表示法 MASTER_USER='repl', -- 刚才建立好的用户名字串 MASTER_PASSWORD='Password@2024', -- 用户密码字符串表达方式呈现出来即可满足需求标准条件下的情况分析讨论环节当中涉及到的内容部分展示效果更佳一些吧? MASTER_LOG_FILE='<BinLogFile>', -- 来源于先前查询所得结果集里面的File字段对应的名称描述文字表述清楚一点比较好哦~ MASTER_LOG_POS=<Position>; -- 同样也是依据前面所获得的数据位置点数填写进去就可以了呀! START SLAVE; -- 正式激活Slave角色身份定义关系链路构建成功与否取决于这里是否能正常运转起来呢?😊 ``` 最后验证一下整个架构体系能否稳定运作无误的话就可以放心大胆地投入使用啦! --- ### 注意事项 - 如果网络延迟较高可能会影响性能表现,请考虑优化网络质量或采用压缩传输选项减少带宽消耗量级提升效率水平达到预期目标范围之内才行哟~ 😊 - 当遇到任何异常状况发生时记得及时查阅错误日记寻找解决办法尽快恢复正常运营秩序维护业务连续性和用户体验满意度不受影响才是最重要的事情之一啊朋友们!!!💪 --- ```python # 示例 Python 脚本监控从同步状态 (可选扩展功能开发方向参考用途) import pymysql def check_replication_status(host, port, user, password): try: connection = pymysql.connect( host=host, port=int(port), user=user, passwd=password) cursor = connection.cursor() query = """ SELECT Slave_IO_Running, Slave_SQL_Running, Seconds_Behind_Master FROM INFORMATION_SCHEMA.PROCESSLIST WHERE Command LIKE '%binlog%'; """ cursor.execute(query) result = cursor.fetchone() io_running = result[0].lower() == "yes" sql_running = result[1].lower() == "yes" lag_seconds = int(result[2]) if isinstance(result[2], str) and result[2].isdigit() else None return { "io_running": io_running, "sql_running": sql_running, "lag_seconds": lag_seconds } except Exception as e: raise ValueError(f"Error checking replication status: {e}") if __name__ == "__main__": status = check_replication_status('localhost', 3306, 'root', '') print(status) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值