JDK《Java问答-我的IT技术路》笔记

MySQL：

单机

高性能：

整体架构设计？

连接器，缓存，分析、优化、执行。

基本语句执行流程？

undolog, redolog_prepare, binlog, redolog_commit。

buffer_pool，change_buffer，orderBy/GroupBy内部临时表…

如何优化？有哪些地方或参数是性能瓶颈？

加内存，加buffer_pool。

索引优化：慢日志。explain。命中率。

网卡/连接数、磁盘IOPS，SSD或机械/IOPS参数、内存/buffer_pool。

事务隔离级别。binlog落盘策略。

如何确定基线性能？

https://blog.51cto.com/u_15127556/3959710

mysqlslap是MySQL5.1.4之后自带的benchmark基准测试工具。

此外，Jmeter也可以用来测试数据库性能。

如何监测线上性能？

Zabbix：

• RT接口响应时间？
• 访问连接数？
• 内存、Cpu、磁盘监控。

线上执行很慢，什么问题？

• 大事务undo回滚大量数据版本。
• 没加索引，索引判断错了。
• 在刷脏页，被锁了。
• 内存不够，如何调参高效利用内存。
• 数据/连接确实多。

资源满了怎么办？突然CPU彪升、内存满了、磁盘满了、网卡/网络连接数满了、假死、死锁，怎么处理？

1.看慢查询日志：慢查询。计算慢，导致运行时间长。
当然，不想详细的分析 MySQL 指标或者是情况比较紧急的话，可以直接在 slowlog 里面用 rows_sent 和 row_examined 做个简单的除法，比如 row_examined/rows_sent > 1000 的都可以拿出来作为“嫌疑人”处理。这类问题一般在索引方面做好优化就能解决。

2.看processlist：计算量大，导致运行时间长
据量比较大，即使索引没什么问题，执行计划也 OK，也会导致 CPU 100%，而且结合 MySQL one-thread-per-connection 的特性，并不需要太多的并发就能把 CPU 使用率跑满。这一类查询其实是是比较好查的，因为执行时间一般会比较久，在 processlist 里面就会非常显眼

3.看QPS：高 QPS
不论是 row_examined/rows_sent 的比值，还是 SQL 的索引、执行计划，或者是 SQL 的计算量都不会有什么明显问题，只是 QPS 指标会比较高，而且 processlist 里面可能什么内容都看不到

总结一下
实际上 CPU 100% 的问题其实不仅仅是单纯的 %us，还会有 %io，%sys 等，这些会涉及到 MySQL 与 Linux 相关联的一部分内容，展开来就会比较多了。本文仅从 %us 出发尝试梳理一下排查&定位的思路和方法，在分析 %io，%sys 等方面的问题时，也可以用类似的思路，从这些指标的意义开始，结合 MySQL 的一些特性或者特点，逐步理清楚表象背后的原因。

线上高性能参数如何配置？

• 双1写。即redo log 和 bin log都是每次事务都落盘。
• RR + raw格式的binlog。为什么要要用RR而不用RC？RC性能不行。RR为什么要用Row格式？避免主从时，主先删后插，而从为先插后删，引起Bug。
• 打开慢日志记录。
• 配置全量备份：mysqldump工具。
• buffer_pool配大点。
• 连接数配大点。
• 磁盘IOPS参数：innodb_io_capacity。
• 关注脏页IO占比参数，innodb_max_dirty_pages_pct ：刷脏页的IO资源占所有IO资源的百分比。不要超过75%。
• 可考虑重建索引来处理数据空洞问题。

如何解决热点问题？

分表。注意处理数据一致性问题。

如何解决数据偏斜问题？

分表。注意处理数据一致性问题。

高可用：

如何持久化？整体流程？有哪些持久化策略？

两阶段提交： undolog -> changebuffer（先写进系统表还是redolog忘了，后续刷脏页）-> redolog_prepare（环形） -> binlog -> redolog_commit。

持久化时，有新数据写入怎么办？如果是两阶段日志，如何保证新老日志数据相同？写时复制？

MySQL直接双1落盘就行，没这种需求。

Redis的RDB是瞬间的快照，AOF需要重写，都会对变更进行缓存。

持久化时，突然宕机怎么办？日志还完整吗？

redolog_prepare（环形） -> binlog -> redolog_commit，两阶段，处于任何阶段都能恢复，问题不大。

宕机时，如何保证数据不丢？

双1配置。主从注意，如果用RR，需要保证binlog格式为raw。

重启后，数据如何恢复？恢复流程？

https://zhuanlan.zhihu.com/p/516793325

全量备份 + binlog。

如果MySQL服务器启用了二进制日志，在数据库出现意外丢失数据时，可以使用mysqlbinlog工具恢复数据，语法格式为：

mysqlbinlog [option] binlog_name | mysql -u user -p

半同步问题，会多出来数据。建议手动恢复？

如何备份？

全量备份：使用mysqlpump，备份文件。本质上是insert…select…。是一个SQL文本。注意加 –single-transaction参数。

增量备份：使用mysqlbinlog，备份binlog。本质上是通过 mysqlbinlog 模拟一个 slave 从服务器，然后主服务器不断将二进制日志推送给从服务器。

备份系统还需要一个备份文件的校验功能：备份文件校验的大致逻辑是恢复全部文件，接着通过增量备份进行恢复，然后将恢复的 MySQL实例连上线上的 MySQL 服务器作为从服务器，然后再次进行数据核对。

线上高可用参数如何配置？

高可用：双1。RC + raw格式的binlog。

MySQL有哪些日志？

https://zhuanlan.zhihu.com/p/516793325

MySQL日志主要分为四类，使用这些日志文件可以查看MySQL内部发生的事情：

• 二进制日志，记录所有更改数据的语句，可以用于主从数据库复制，数据恢复等
• 错误日志，记录MySQL服务的启动、运行或停止MySQL服务出现的问题
  • 开启错误日志：在配置文件中添加一行代码：log_error = /home/lwz/Public/mysql/3306/data/My_Error.log。之后重启服务。
  • 查看错误日志：show variables like "log_error"。一个普通文本文件，可以直接打开。
• 通用查询日志，记录建立的客户端连接和执行的语句。默认关闭。通用查询日志记录MySQL的用户的所有SQL操作，是一个普通文本文件。
• 慢查询日志，记录所有执行时间超过long_query_time的所有查询或不使用索引的查询
  • 开启慢查询日志：set @@global.slow_query_log = 1;。默认保存路径，和我们的数据库文件在同一个目录
  • 查看慢查询日志：一个普通文本文件，可以直接打开。

默认情况下，所有日志创建于MySQL数据目录中，

线上如何监控运行情况？出错了怎么看日志？怎么排查日志和错误？

看processlist：可以看到各个连接的执行状态。
据量比较大，即使索引没什么问题，执行计划也 OK，也会导致 CPU 100%，而且结合 MySQL one-thread-per-connection 的特性，并不需要太多的并发就能把 CPU 使用率跑满。这一类查询其实是是比较好查的，因为执行时间一般会比较久，在 processlist 里面就会非常显眼。

慢查询日志用命令打开，错误日志用命令打开。日志可以直接到相应目录查看。

可扩展：

哪些地方是性能瓶颈？如果此时流量/数据量大幅提升，可以如何扩展？

单机：

• 加内存，调大 buffer_pool。
• 换SSD磁盘，调大 IOPS参数。
• 索引优化：慢日志。explain。命中率。
• 事务隔离级别。binlog落盘策略。

集群：

• 主从
• 一主多从：MHA
• 分库分表：mycat坑比较多。用sharding-JDBC。大厂自研。
• 集群：MGR，还不是很成熟
• newSQL：TiDB，OceanDB

使用的版本？都有啥区别？

5.7。性能优化，多线程读relay-log？

和其他同类中间件的区别？选型依据？

• Orcle，要钱
• newSQL：TiDB，还是不太成熟。

主从：

高性能：

数据如何同步？第一次如何同步？后续如何同步？

• 半同步。binlog -> 从relayLog -> ack/commit ->从binlog。
• 一直都是用binlog同步。

怎么解决数据不一致问题？从没有主快？从的数据不是最新的？

• 同一个事务内，可以返回GTID。用GTID去从库查询，看下有没有同步完成了，OK就行。这种方式和具体业务耦合太强。
• 强制走主，一个请求，或是一整个微服务，全部走主。辅助AOP实现。
• 半同步。binlog -> 从relayLog -> ack/commit ->从binlog。

https://www.cnblogs.com/jimoer/p/14673646.html

MySQL复制类型？

• 异步复制模式：很好理解，很可能丢数据。
• 同步复制模式：所有从ack才commit。
• 半同步复制：有一个从ack就commit。
• GTID复制（MySQL5.6）：从连上主时，把自己已执行的和待执行的（relay_log）GTID发给主即可。

半同步复制：

• 坑：
  • 注意老的AFTER_COMMIT模式（5.6版本，主先commit，从后ack）有问题：事务写两遍。幻读。
  • 新的方式AFTER_SYNC模式（5.7版本，从先ack，主后commit）也有问题：多出数据。即主虽然没提交，但恢复后为提交状态。主库挂掉时，数据有可能已经写到从库的relay_log了。所以从库会多数据。MySQL，在没办法解决分布式数据一致性问题的情况下，它能保证的是不丢数据，多了数据总比丢数据要好。
  • 会退化为异步提交：本质是主超时后自动提交。当出现异常时，Slave没有ACK事务，那么将自动降级为异步复制，直到异常修复后再自动变为半同步复制。
• 性能优化：
  • 5.6 master的dump线程不但要发送binlog到从库，还有负责接收slave的ACK。
  • 5.7 分了两条线程，分别负责发送binlog和ACK。

GTID复制模式：

• 数据恢复时会根据GTID自动处理。
• 不支持非事务引擎。
• 集群中所有实例都要支持GTID。
• 只支持GTID，不支持老模式：不像半同步，失败时可以回退为异步。
• GTID是用来代替传统复制的方法，GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置;

https://learn.lianglianglee.com/%E4%B8%93%E6%A0%8F/MySQL%E5%AE%9E%E6%88%98%E5%AE%9D%E5%85%B8/15%20%20MySQL%20%E5%A4%8D%E5%88%B6%EF%BC%9A%E6%9C%80%E7%AE%80%E5%8D%95%E4%B9%9F%E6%9C%80%E5%AE%B9%E6%98%93%E9%85%8D%E7%BD%AE%E5%87%BA%E9%94%99.md

复制配置：

gtid_mode = on
enforce_gtid_consistency = 1
binlog_gtid_simple_recovery = 1
relay_log_recovery = ON
master_info_repository = TABLE 
relay_log_info_repository = TABLE

半同步要下载插件：

plugin-load="rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
rpl-semi-sync-master-enabled = 1
rpl-semi-sync-slave-enabled = 1
rpl_semi_sync_master_wait_no_slave = 1	# 至少1个slave接到日志。

从没有主快？配上MySQL5.7，多线程回放relaylog。

如何检测线上性能？

主从复制间隔检查？从跟不上主怎么办？

想要实时准确地监控主从复制延迟，可以在主服务器上引入一张心跳表 heartbeat，用于定期更新时间（比如每 3 秒一次）。于主从复制机制，主机上写入的时间会被复制到从机，这时对于主从复制延迟的判断可以根据如下规则：

主从延迟 = 从机当前时间 - 表 heartbeat 中的时间

USE DBA;

CREATE TABLE heartbeat (
  server-uuid VARCHAR(36) PRIMARY KEY,
  ts TIMESTAMP(6) NOT NULL
);

REPLACE INTO heartbeat(@@server_uuid, NOW())

线上高性能参数如何配置？

MySQL5.7支持多线程复制relaylog？半同步加入了async模式？

高可用：

同步数据在主和从是怎么做持久化的？有哪些持久化策略？

见前文。异步、同步、半同步。

持久化时，有新的数据写入怎么办？如何解决主从数据不一致问题？

MySQL一般采用半同步。坑见前文。

主故障，如何自动切换？如何选主？如何保证数据不丢？

MySQL一般采用半同步。坑见前文。

• 用keepAlived + 切换脚本（A停主，B升主，流量切过去）。之后手动恢复（半同步多余数据问题）。
• 用MHA。

主故障后，如何保证从的数据是最新的？

MySQL一般采用半同步。坑见前文。

主重启后，数据如何恢复？

MySQL一般采用半同步。坑见前文。

主重启后，如何重新加入集群？

MySQL一般采用半同步。坑见前文。

• 用keepAlived + 切换脚本（A停主，B升主，流量切过去）。之后手动恢复（半同步多余数据问题）。
• 用MHA。

从故障，数据如何做持久化？如何保证数据不丢？

MySQL问题不大。

从重启后，数据如何恢复？

• 方式一：binlog + pos
• 方式二：GTID

从重启后，如何重新加入集群？

网络波动，主未响应，造成脑裂问题，如何预防或处理？

网络波动，从未响应，如何处理？

半同步，主会自己提交事务。

主要的高可用参数设置？

参考单机。

线上如何监控运行情况？出错了怎么看日志？怎么排查日志和错误？

Zabbix。MySQL开启错误日志、慢日志，查看日志文本。

可扩展：

数据分布策略？节点部署方式？

• 主从
• 主主：
  1. 当主节点上MySQL实例发生故障后,可能会存在部分数据(Binlog)未同步到另外的主节点,导致数据丢失(直到故障节点恢复)。
  2. 主主模式下,很容易因数据访问控制不当导致数据冲突。
  3. 为提高系统高可用性,双主架构会被扩展成双主多从结构,同样存在主节点发生故障后多个从库选主和恢复复制的问题。
• MHA

怎么加子节点？数据如何平滑迁移？

分表

怎么删子节点？数据如何平滑迁移？

• 正常切换：主节点：Reset master。然后CHANGE MASTER。TOMASTER_HOST=’原从服务器IP’,MASTER_USER=’用户名’,MASTER_PASSWORD=’密码’,master_log_file=’master-bin.000015’ ;
• 主机直接宕机：在备机上执行STOP SLAVE 和 RESET MASTER

Redis

单机

高性能：

整体架构设计

基本语句执行流程

如何优化？有哪些地方或参数是性能瓶颈？

如何确定基线性能？

如何检测线上性能？

线上执行很慢，什么问题？

资源满了怎么办？突然CPU彪升、内存满了、磁盘满了、网络连接数满了、假死、死锁，怎么处理？

线上参数如何配置？

如何解决热点问题？

如何解决数据偏斜问题？

高可用：

如何持久化？整体流程？

持久化时，有新数据写入怎么办？如果是两阶段日志，如何保证新老日志数据相同？写时复制？

RDB日志，快照时需要新老快照一起写。会有写时复制，有缓存存起来。

AOF（环形），需要定期重写。也是会把变更先缓存起来。

持久化时，突然宕机怎么办？日志还完整吗？

Redis是异步复制，没办法，会丢的。

不过可以设置master超过N秒没响应就拒绝接受写请求，从而减少丢失的数据。

宕机时，如何保证数据不丢？

重启后，数据如何恢复？恢复流程？

线上参数如何配置？

线上如何监控运行情况？出错了怎么看日志？怎么排查日志和错误？

可扩展：

哪些地方是性能瓶颈？如果此时流量/数据量大幅提升，可以如何扩展？

使用的版本？都有啥区别？

和其他同类中间件的区别？选型依据？

主从：

高性能：

数据如何同步？第一次如何同步？后续如何同步？

怎么解决数据不一致问题？从没有主快？从的数据不是最新的？

如何检测线上性能？

线上参数如何配置？

高可用：

同步数据在主和从是怎么做持久化的？

持久化时，有新的数据写入怎么办？如何解决主从数据不一致问题？

主故障，如何切换？如何选主？如何保证数据不丢？

主故障后，如何保证从的数据是最新的？

主重启后，数据如何恢复？

主重启后，如何重新加入集群？

从故障，数据如何做持久化？如何保证数据不丢？

从重启后，数据如何恢复？

从重启后，如何重新加入集群？

网络波动，主未响应，造成脑裂问题，如何预防或处理？

网络波动，从未响应，如何处理？

主要的参数设置？

线上如何监控运行情况？出错了怎么看日志？怎么排查日志和错误？

可扩展：

数据分布策略？节点部署方式？

怎么加子节点？数据如何平滑迁移？

怎么删子节点？数据如何平滑迁移？

---

转载请注明来源