高性能mysql笔记6_高性能MySQL读书笔记 (六)

1. 可扩展的Mysql

可扩展性: 通过增加资源提升容量的能力

1.1 考虑负载

容量可以简单地认为是处理负载的能力,考虑负载可从以下几个角度

数据量: 很多应用从不物理删除任何数据,应用所积累的数据量是可扩展的普遍挑战

用户量: 更多的用户意味着更多的事务,更多的复杂查询

用户活跃度

相关数据集的大小

1.2 规划可扩展性

估算需要承担的负载到底有多少

大致正确地估计日程表

应用的功能完成多少

预期的最大负载是多少

如果依赖系统的每个部分分担负载,某个部分失效时会发生什么

1.3 向上扩展(垂直扩展)

单台服务器增加各种高性能硬件

烧钱有效的方法

不应该无限制向上扩展

1.4 向外扩展

策略: 复制,拆分,数据分片

按功能拆分: 常见做法,根据功能将应用部署在不同服务器,并使用专用的数据库服务器

1.4.1 数据分片

数据分片是目前扩展大型MySQL最通用且最成功的方法

应用设计初期考虑到,后期实现就比较容易,否则很难将应用从单一数据存储转换为分片架构

文中举例: 通过用户id来对文章和评论进行分片,而将用户的信息保留在单个节点上

数据库访问抽象层,降低应用和分片数据之间通信的复杂度

如非必要尽量不分片

数据分片最大的挑战就是查找和获取数据

类似于表分区,选择分区键和数据分片方式是关键,具体请细查

1.5 通过集群扩展

可以使用集群或数据库分布式技术根据场景适当解决一些问题

书中提到技术: NDB Cluster, Clustrix等技术

1.6 向内扩展

对不再需要的数据进行归档和清理

需要考虑对应用的影响

需要考虑数据逻辑的一致性,例如清理A表历史数据时需要考虑所有关联数据的处理

冷热数据分离

1.7 负载均衡

1.7.1 目的

可扩展性: 如读写分离时从备库读数据

高效性: 把更多工作分配给更好的机器

可用性: 使用时刻保持可用的服务器

透明性: 客户端无需知道服务器

一致性: 如果应用是有状态的,负载均衡器就应该将相关的查询指向同一个服务器

1.7.2 直接连接

1.7.2.1 复制上的读写分离

基于查询分离: 将不能容忍脏数据的查询分配到主库,其他分配到备库

基于脏数据分离: 让应用检查复制延迟,许多报表类应用使用这个策略

基于会话分离: 可以在会话层做一个标记,如果用户修改了数据,则一段时间内总是指向主库

基于版本分离: 给用户的操作增加版本号,检查版本号决定从主库还是备库读取数据

1.7.2.3 修改DNS名

通过变更DNS名指定的服务器实现

缺点很多,不建议

1.7.2.4 转移IP地址

在服务器之间转移虚拟地址

给服务器分配固定的ip地址,为每个逻辑上的服务使用一个虚拟ip地址

1.7.3 引入中间件

负载均衡器,如HAproxy

负载均衡算法: 随机, 轮询,最少连接数,最快响应,哈希,权重

服务器池中增加或移除服务器: 在配置连接池中的服务器时,要保证有足够多未使用的容量

2. 高可用性

高可用性意味着更少的宕机时间

2.1 宕机原因

磁盘空间不足

糟糕的sql或者服务器bug引起

糟糕的表和索引设计

复制问题通常由于主备数据不一致导致

2.2 高可用性实现

衡量指标: 平均失效时间(MTBF), 平均恢复时间(MTTR)

避免问题: 适当的配置,监控和规范

保证在宕机时能快速恢复,系统制造冗余,具备故障转移能力

2.2.1 避免单点失效

通过增加冗余避免

共享存储或磁盘复制,如果服务器挂了,备用服务器可以挂载相同的文件系统执行需要的恢复操作

MySQL同步复制

2.2.2 故障转移和故障恢复

提升备库或切换角色

虚拟IP地址或IP接管: 当MySQL实例失效时可以将IP地址转移到另一台MySQL服务器上

使用中间件解决方案

3. 备份与恢复

3.1 设计MySQL备份方案考虑点

在线备份还是离线备份

逻辑备份还是物理备份

非显著数据: 如二进制日志和InnoDB事务日志

代码: 存储过程,触发器

服务器配置和复制配置

外部配置,管理脚本

增量备份和差异备份

存储引擎和数据一致性

3.2 备份数据方式

文件系统中或SAN快照中直接复制数据文件

Percona XtraBackup 做热备份

3.3 InnoDB崩溃恢复

二级索引损坏: 使用OPTIMIZE TABLE修复损坏的二级索引,此外可以通过构建一个新表重建受影响的索引

聚簇索引损坏: innodb_force_recovery导出表

损坏系统结构: 系统结构包括事务日志等,可能需要做整个数据库的导出和还原,因为InnoDB内部绝大部分的工作可能受影响

4. MySQL用户工具

工欲善其事,必先利其器

4.1 接口工具

MySQL Workbench: 一站式的工具

SQLyog: 可视化工具之一

4.2 命令行工具集

Percona Toolkit

MySQL Workbench 工具集

4.3 SQL实用集

common_schema

MySQL Forge

4.4 监测工具

Nagios

Zabbix: 同时支持监控和指标收集的完整系统

Zenoss: Python写的

Hyperic HQ: 基于Java

4.5 Innotop命令行监控

主要包括以下功能

事务列表

当前运行的查询

当前锁和锁等待列表

服务器状态和变量汇总信息

InnoDB内部信息

复制监控

以下是对提供的参考资料的总结,按照要求结构化多个要点分条输出: 4G/5G无线网络优化与网规案例分析: NSA站点下终端掉4G问题:部分用户反馈NSA终端频繁掉4G,主要因终端主动发起SCGfail导致。分析显示,在信号较好的环境下,终端可能因节能、过热保护等原因主动释放连接。解决方案建议终端侧进行分析处理,尝试关闭节电开关等。 RSSI算法识别天馈遮挡:通过计算RSSI平均值及差值识别天馈遮挡,差值大于3dB则认定有遮挡。不同设备分组规则不同,如64T和32T。此方法可有效帮助现场人员识别因环境变化引起的网络问题。 5G 160M组网小区CA不生效:某5G站点开启100M+60M CA功能后,测试发现UE无法正常使用CA功能。问题原因在于CA频点集标识配置错误,修正后测试正常。 5G网络优化与策略: CCE映射方式优化:针对诺基亚站点覆盖农村区域,通过优化CCE资源映射方式(交织、非交织),提升RRC连接建立成功率和无线接通率。非交织方式相比交织方式有显著提升。 5G AAU两扇区组网:与三扇区组网相比,AAU两扇区组网在RSRP、SINR、下载速率和上传速率上表现不同,需根据具体场景选择适合的组网方式。 5G语音解决方案:包括沿用4G语音解决方案、EPS Fallback方案和VoNR方案。不同方案适用于不同的5G组网策略,如NSA和SA,并影响语音连续性和网络覆盖。 4G网络优化与资源利用: 4G室分设备利旧:面对4G网络投资压减与资源需求矛盾,提出利旧多维度调优策略,包括资源整合、统筹调配既有资源,以满足新增需求和提质增效。 宏站RRU设备1托N射灯:针对5G深度覆盖需求,研究使用宏站AAU结合1托N射灯方案,快速便捷地开通5G站点,提升深度覆盖能力。 基站与流程管理: 爱立信LTE基站邻区添加流程:未提供具体内容,但通常涉及邻区规划、参数配置、测试验证等步骤,以确保基站间顺畅切换和覆盖连续性。 网络规划与策略: 新高铁跨海大桥覆盖方案试点:虽未提供详细内容,但可推测涉及高铁跨海大桥区域的4G/5G网络覆盖规划,需考虑信号穿透、移动性管理、网络容量等因素。 总结: 提供的参考资料涵盖了4G/5G无线网络优化、网规案例分析、网络优化策略、资源利用、基站管理等多个方面。 通过具体案例分析,展示了无线网络优化中的常见问题及解决方案,如NSA终端掉4G、RSSI识别天馈遮挡、CA不生效等。 强调了5G网络优化与策略的重要性,包括CCE映射方式优化、5G语音解决方案、AAU扇区组网选择等。 提出了4G网络优化与资源利用的策略,如室分设备利旧、宏站RRU设备1托N射灯等。 基站与流程管理方面,提到了爱立信LTE基站邻区添加流程,但未给出具体细节。 新高铁跨海大桥覆盖方案试点展示了特殊场景下的网络规划需求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值