MySQL DBA需要掌握的 7 个问题

1、MySQL适用的场景是什么?

数据量建议单实例T级或以内,不依赖存储过程、函数、触发器的传统oltp场景都适用,因为是一个相对轻量级的数据库

灾备使用MySQL各类的高可用方案即可,比如主从、mha、mgr等。

2、MySQL巡检应该怎么做?优先关注哪些参数?

可以从以下几个方面去做:

  • 服务器配置
  • 操作系统配置及重要参数
  • MySQL层配置及重要参数
  • MySQL对象
  • MySQL运行时的重要状态(日志、锁)

3、MySQL如何排查CPU占用高的问题?

重点是关于通过哪些系统表或者常用的sql来确定导致问题的sql?

方案一、通过pidstat命令定位

首先我们先找到mysqld进程的PID,然后执行pidstat -t -p $PID,结果如下图:

进入mysql交互命令,通过以下命令查询具体SQL。

select * from performance_schema.threads where thread_os_id = '1';

定位到了具体定位sql接下来就可以分析优化了。

方案二、通过TOP命令定位

  • 首先执行TOP命令,输入H,可以按照显示线程状态。
  • 输入P,可以按照cpu的使用时间份额进行排序,这时候我们就可以看下是否有超过70%-90%以上的线程了。

登录mysql,执行以下命令

select * from performance_schema.threads where THREAD_OS_ID=4461 \G

4、MySQL数据库内存使用率高,应该如何进行排查?

Mysql Server Memory Usage= Sum of Global Buffers + (number of Connection * Per thread memory variables)

单个mysql连接线程的内存消耗统计,这里只是统计分配值(具体驻留内存占用值统计不到)

SELECT b.thd_id, b.user, current_count_used, current_allocated, current_avg_alloc  , current_max_alloc, total_allocated, current_statementFROM memory_by_thread_by_current_bytes a, session bWHERE a.thread_id = b.thd_idLIMIT 1;

统计 top 10 的buffer pool占用内存的表

SELECT * FROM innodb_buffer_stats_by_table ORDER BY pages DESCLIMIT 10;

5、MySQL数据库磁盘IO使用高,请问如何进行排查?

mysql5.7版本为例,结合performance_schema来查看MySQL数据库的各种指标。相当于Oracle数据库中的各种性能视图,可以查看几乎所有的数据库状态。

IO的话,可以查看这张表:

performance_schema.file_instances:列出了文件I / O操作及其相关文件的工具实例

排查思路:

1、慢SQL排除

2、硬件问题-RAID降级,磁盘故障等排除

2、innodb_log、innodb_buffer_pool_wait相关配置和等待

3、IO相关参数配置

innodb_flush_method = O_DIRECT

innodb_file_per_table = 1

innodb_doublewrite = 1

delay_key_write

innodb_read_io_threads

innodb_read_io_threads

innodb_io_capacity

innodb_flush_neighbors

sync_binlog

对比历史性能记录,结合业务以及负载来分析。

6、有哪些工具可以帮助优化MySQL的?

以下工具可以参考:

pt-mysql-summary

pt-variable-advisor

pt-duplicate-key-checker

pt-deadlock-logger 

或者

tuning-primer.sh

https://github.com/major/MySQLTuner-perl

7、目前主流的MySQL高可用采用哪种方式,MHA还是MGR?

由于MGR技术相对较新,目前使用MHA更多。但个人认为,MGR或者基于此的innodb cluster架构(或替代方案)会成为未来主流。

MHA:

优点:成熟稳定,自动切换主从,主节点宕机后尽可能少丢失数据(自动抓取未复制的binlog)。

缺点:管理节点单点、可能脑裂、可能有不必要切换、还是有丢数据风险、组件多维护相对麻烦

MGR:

优点:基于paxos的高可用架构,支持多主(不建议),强一致

缺点:需要innodb引擎(丢业务有改造代价),应用端没有自动切换(可以通过中间件解决),技术太新可能有未知bug。


更多精彩内容,关注我们▼▼

为您推荐

发表评论

您的电子邮箱地址不会被公开。