Rao's Blog

  • 首页

  • 标签

  • 分类

  • 归档

  • 搜索

MySQL · 调优案例 · HMQM

发表于 2019-10-23 | 更新于 2019-12-09 | 分类于 MySQL

问题现象

原因分析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
mysql> select table_name,table_rows,CONCAT(TRUNCATE(SUM(data_length)/1024/1024,2),'MB') AS data_size, CONCAT(TRUNCATE(SUM(index_length)/1024/1024,2),'MB') AS index_size from information_schema.tables where TABLE_SCHEMA = 'mqm' and table_name='t_batch';
+------------+------------+-----------+------------+
| table_name | table_rows | data_size | index_size |
+------------+------------+-----------+------------+
| t_batch | 10289197 | 4895.00MB | 7578.23MB |
+------------+------------+-----------+------------+
1 row in set (0.03 sec)

DROP INDEX idx_group
Analyze table t_batch;

+------------+------------+-----------+------------+
| table_name | table_rows | data_size | index_size |
+------------+------------+-----------+------------+
| t_batch | 10657643 | 4895.00MB | 1230.93MB |
+------------+------------+-----------+------------+
1 row in set (0.00 sec)

+------------+------------+-----------+------------+
| table_name | table_rows | data_size | index_size |
+------------+------------+-----------+------------+
| t_batch | 9852520 | 4895.00MB | 2863.00MB |
+------------+------------+-----------+------------+
1 row in set (0.04 sec)

mysql> ALTER TABLE t_batch ADD INDEX idx_check_style_id(check_style_id);
Query OK, 0 rows affected (2 min 27.34 sec)

mysql> ALTER TABLE t_batch ADD INDEX idx_check_status_id(check_status_id);
Query OK, 0 rows affected (1 min 0.12 sec)

mysql> ALTER TABLE t_batch ADD INDEX idx_iqc_leader_id(iqc_leader_id);
Query OK, 0 rows affected (1 min 14.52 sec)

mysql> ALTER TABLE t_batch ADD INDEX idx_create_date(create_date);
Query OK, 0 rows affected (53.03 sec)

mysql> ALTER TABLE t_batch ADD INDEX idx_IQC_manager_id(IQC_manager_id);
Query OK, 0 rows affected (1 min 11.37 sec)

mysql> ALTER TABLE t_batch ADD INDEX idx_syb_id(syb_id);
Query OK, 0 rows affected (1 min 3.97 sec)

mysql> ALTER TABLE t_batch ADD INDEX idx_group(check_style_id, check_status_id, delete_status);
Query OK, 0 rows affected (2 min 3.08 sec)

测试数据库

1
2
实例:10.138.22.192:3306/mqm
账号:hmqm/hmqm
1
2
3
4
5
6
7
8
+----+-------------+---------+-------------+----------------------------------------------------------+---------------------------------------+---------+------+------+---------------------------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------+-------------+----------------------------------------------------------+---------------------------------------+---------+------+------+---------------------------------------------------------------------+
| 1 | SIMPLE | t_batch | index_merge | idx_check_style_id,idx_check_status_id,idx_iqc_leader_id | idx_check_status_id,idx_iqc_leader_id | 5,63 | NULL | 4955 | Using intersect(idx_check_status_id,idx_iqc_leader_id); Using where |
+----+-------------+---------+-------------+----------------------------------------------------------+---------------------------------------+---------+------+------+---------------------------------------------------------------------+

type: index_merge: 表示查询使用了两个以上的索引,最后取交集或者并集,常见and ,or的条件使用了不同的索引,官方排序这个在ref_or_null之后,但是实际上由于要读取所个索引,性能可能大部分时间都不如range
extra: using intersect,表示使用and的各个索引的条件时,该信息表示是从处理结果获取交集
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
explain select '' batch_fail_id,'' uuid_Fail,b.send_goods_No,b.test_type,b.order_no,b.row_no,b.bu,b.mtl_no,b.mtl_name,b.mtl_group,b.mtl_group_name,b.materiel_category_id,b.materiel_category_name,b.pattern_amount,b.plan_pattern_amount,b.goods_unit,b.plan_send_day,b.fact_send_Day,b.stock_Day,b.supply_code,b.supply_name,b.supply_check_level,b.sap_mark_id,b.sap_mark_name,b.syb_id,b.syb_name,b.check_style_id,b.check_style_name,b.check_type_id,b.check_type_name,b.QC_STATUS,b.QC_STATUS_INSTR_DATE,b.QC_NO,b.factory_code,b.goods_sort,b.price_unit,b.stock_price,b.LICHA,b.BSART,b.LGORT,b.plan_Date,b.TEST_CONCLUSION,b.IQC_manager_id,b.IQC_manager_name,b.iqc_leader_id,b.iqc_leader_name,b.test_complete_day,b.test_start_day,b.new_or_old,b.check_status_id,b.is_appeal,b.is_start_check,b.standard_type,b.check_reason,b.is_stop,b.check_time,b.instance_id,b.create_date createDate,b.delete_status
from t_batch b
where b.mtl_no like CONCAT('%470A%')
and b.syb_id in (18,306,323,17,483,15,519)
and b.lgort like CONCAT('%J191023878681%')
and b.delete_status = 'N'
UNION ALL
select f.batch_fail_id,f.uuid,f.send_goods_No,f.test_type,f.order_no,f.row_no,f.bu,f.mtl_no,f.mtl_name,f.mtl_group,f.mtl_group_name,f.materiel_category_id,f.materiel_category_name,f.pattern_amount,f.plan_pattern_amount,f.goods_unit,f.plan_send_day,f.fact_send_Day,f.stock_Day,f.supply_code,f.supply_name,f.supply_check_level,f.sap_mark_id,f.sap_mark_name,f.syb_id,f.syb_name,f.check_style_id,f.check_style_name,f.check_type_id,f.check_type_name,f.QC_STATUS,f.QC_STATUS_INSTR_DATE,f.QC_NO,f.factory_code,f.goods_sort,f.price_unit,f.stock_price,f.LICHA,f.BSART,f.LGORT,f.plan_Date,f.TEST_CONCLUSION,f.IQC_manager_id,f.IQC_manager_name,f.iqc_leader_id,f.iqc_leader_name,f.test_complete_day,f.test_start_day,f.new_or_old,f.check_status_id,f.is_appeal,f.is_start_check,f.standard_type,f.check_reason,f.is_stop,f.check_time,f.instance_id,f.create_date createDate,f.delete_status
from t_batch_fail f
where f.mtl_no like CONCAT('%470A%')
and f.syb_id in (18,306,323,17,483,15,519)
and f.lgort like CONCAT('%J191023878681%')
and f.delete_status = 'N'
order by createDate DESC
limit 0,10

// 查询时 limit 0,10
// 导出时 limit 0,5000
// 外检查询入场数据,常用的参数:物料号mtl_no截取后几位,看单号lgort,系统自动获取外检的事业部信息syb_id,有时候是一个事业部,有时候是多个事业部遍历。
and b.syb_id = 18
and b.syb_id in (18,306,323,17,483,15,519) 这两个条件只会存在一个。

MySQL · 数据库迁移

发表于 2019-10-22 | 更新于 2019-12-03 | 分类于 MySQL

背景

源数据库:MySQL 5.5.20

  • 主库:10.159.39.38
  • 从库:10.159.39.39
源库信息 (10.159.39.38:3306) 目标库信息 (10.199.96.188:3306)
版本 MySQL 5.5.20
数据量 137.50 GB …
操作系统 CentOS release 6.5 (Final) CentOS release 6.10 (Final)

目的数据库:MySQL 5.6.36

  • 主库:10.199.96.188
  • 从库:10.199.96.189

方案对比

特性 xtrabackup (开源第三方) mysqldump (自带) mysqldumper
性能 最佳 最差 次之
数据量 最大 次之 最少
远程备份 不支持 支持 支持
数据一致性 支持 支持 支持
工具便捷性 次之 较好 较好
版本兼容性 较差 较好 较好
备份类型 物理备份 逻辑备份 逻辑备份

参考案例

需求背景:xx 项目,将生产环境数据库迁移至测试环境,迁移数据量约 185GB

环境信息:

  • 生产库:10.138.22.218:3100,MySQL 5.6.27
  • 测试库:10.138.22.192:3306,MySQL 5.6.27

Tips:数据库版本一致,且配置文件 my.cnf 一致,才能使用 XtraBackup

准备条件:

  • 生产库和测试库服务器都已 安装 XtraBackup
  • 已配置互信

操作步骤:

  • 备份主库(约耗时 30min)
1
$ innobackupex --defaults-file=/etc/my.cnf --user=root --password='xx' --no-timestamp /data/backup
  • 传输备份数据到测试服务器 (约耗时 30min,速度取决于服务器 IO 性能)
1
$ scp -r /data/backup/* root@10.138.22.192:/data/backup
  • 恢复全备数据(约耗时 60min)
1
2
3
4
5
6
7
$ mysqladmin -S /data/mysql/mysql.sock -uroot -p'xx' shutdown
$ innobackupex --defaults-file=/etc/my.cnf --apply-log /data/backup
$ mv mysql mysql_bak
$ mkdir mysql
$ innobackupex --defaults-file=/etc/my.cnf --copy-back /data/backup
$ chown -R mysql:mysql mysql
$ /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf --user=mysql >/dev/null &

MySQL · 案例分析 · information_schema.tables 与 count(*) 查询数不一致

发表于 2019-10-22 | 更新于 2019-11-15 | 分类于 MySQL

问题现象

查询表 mqm.t_batch 总行数,发现两种方式查询的结果不一致。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# information_schema.tables
mysql> select table_name,table_rows from information_schema.tables where TABLE_SCHEMA = 'mqm' and table_name='t_batch';
+------------+------------+
| table_name | table_rows |
+------------+------------+
| t_batch | 9527271 |
+------------+------------+
1 row in set (0.02 sec)

# count(*)
mysql> select count(*) from t_batch;
+----------+
| count(*) |
+----------+
| 10474287 |
+----------+
1 row in set (21.52 sec)

原因分析

默认情况下,MySQL 对表进行增删操作时,是不会自动更新 information_schema.tables 表 table_rows 字段,只有 10% 的行数发生变化才会自动收集,执行 ANALYZE TABLE 'table_name' 后会统计所有表数据,结果和 count(*) 一致。

Tips:生产环境中不建议使用,因为会锁表!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
mysql> ANALYZE TABLE t_batch;
+-------------+---------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+-------------+---------+----------+----------+
| mqm.t_batch | analyze | status | OK |
+-------------+---------+----------+----------+
1 row in set (3.85 sec)

mysql> select table_name,table_rows from information_schema.tables where TABLE_SCHEMA = 'mqm' and table_name='t_batch';
+------------+------------+
| table_name | table_rows |
+------------+------------+
| t_batch | 10261904 |
+------------+------------+
1 row in set (0.07 sec)

MySQL · 调优案例 · 千万级大表模糊查询

发表于 2019-10-22 | 更新于 2019-11-15 | 分类于 MySQL

背景

模糊查询:使用 like %% 类 SQL

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
# 生产环境执行的SQL
SELECT '' AS batch_fail_id, '' AS uuid_Fail, b.send_goods_No, b.test_type, b.order_no
, b.row_no, b.bu, b.mtl_no, b.mtl_name, b.mtl_group, b.mtl_group_name
, b.materiel_category_id, b.materiel_category_name, b.pattern_amount
, b.plan_pattern_amount, b.goods_unit, b.plan_send_day, b.fact_send_Day, b.stock_Day
, b.supply_code, b.supply_name, b.supply_check_level, b.sap_mark_id, b.sap_mark_name
, b.syb_id, b.syb_name, b.check_style_id, b.check_style_name, b.check_type_id
, b.check_type_name, b.QC_STATUS, b.QC_STATUS_INSTR_DATE, b.QC_NO, b.factory_code
, b.goods_sort, b.price_unit, b.stock_price, b.LICHA, b.BSART, b.LGORT
, b.plan_Date, b.TEST_CONCLUSION, b.IQC_manager_id, b.IQC_manager_name, b.iqc_leader_id
, b.iqc_leader_name, b.test_complete_day, b.test_start_day, b.new_or_old,b.check_status_id
, b.is_appeal, b.is_start_check, b.standard_type, b.check_reason, b.is_stop
, b.check_time, b.instance_id, b.create_date AS createDate, b.delete_status
FROM t_batch b
WHERE b.mtl_no LIKE '%0594A%' AND b.delete_status = 'N'
UNION ALL
SELECT f.batch_fail_id, f.uuid, f.send_goods_No, f.test_type, f.order_no, f.row_no
, f.bu, f.mtl_no, f.mtl_name, f.mtl_group, f.mtl_group_name
, f.materiel_category_id,f.materiel_category_name, f.pattern_amount
, f.plan_pattern_amount
, f.goods_unit, f.plan_send_day, f.fact_send_Day, f.stock_Day, f.supply_code
, f.supply_name, f.supply_check_level, f.sap_mark_id, f.sap_mark_name, f.syb_id
, f.syb_name, f.check_style_id, f.check_style_name, f.check_type_id, f.check_type_name
, f.QC_STATUS, f.QC_STATUS_INSTR_DATE, f.QC_NO, f.factory_code, f.goods_sort
, f.price_unit, f.stock_price, f.LICHA, f.BSART, f.LGORT
, f.plan_Date, f.TEST_CONCLUSION, f.IQC_manager_id, f.IQC_manager_name, f.iqc_leader_id
, f.iqc_leader_name, f.test_complete_day, f.test_start_day, f.new_or_old
, f.check_status_id, f.is_appeal, f.is_start_check, f.standard_type, f.check_reason
, f.is_stop, f.check_time, f.instance_id, f.create_date AS createDate, f.delete_status
FROM t_batch_fail f
WHERE f.mtl_no LIKE '%0594A%' AND f.delete_status = 'N'
ORDER BY createDate DESC
LIMIT 0, 10

# 表数据量
mysql> select table_name,table_rows,CONCAT(TRUNCATE(SUM(data_length)/1024/1024,2),'MB') AS data_size, CONCAT(TRUNCATE(SUM(index_length)/1024/1024,2),'MB') AS index_size from information_schema.tables where TABLE_SCHEMA = 'mqm' and table_name='t_batch';
+------------+------------+-----------+------------+
| table_name | table_rows | data_size | index_size |
+------------+------------+-----------+------------+
| t_batch | 10261904 | 4895.00MB | 8643.23MB |
+------------+------------+-----------+------------+
1 row in set (0.00 sec)

+--------------+------------+-----------+------------+
| table_name | table_rows | data_size | index_size |
+--------------+------------+-----------+------------+
| t_batch_fail | 43683 | 19.56MB | 14.57MB |
+--------------+------------+-----------+------------+
1 row in set (0.01 sec)

# 执行时间
10 rows in set (1 min 26.92 sec)

分析

Union All:对两个结果集进行并集操作,包括重复行。

执行计划:

1
2
3
4
5
6
7
+----+--------------+------------+------+-------------------+-------------------+---------+-------+---------+------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------+------------+------+-------------------+-------------------+---------+-------+---------+------------------------------------+
| 1 | PRIMARY | b | ALL | NULL | NULL | NULL | NULL | 9527271 | Using where |
| 2 | UNION | f | ref | idx_delete_status | idx_delete_status | 9 | const | 20469 | Using index condition; Using where |
| NULL | UNION RESULT | <union1,2> | ALL | NULL | NULL | NULL | NULL | NULL | Using temporary; Using filesort |
+----+--------------+------------+------+-------------------+-------------------+---------+-------+---------+------------------------------------+
1
2
3
4
5
6
7
8
9
10
11
12
13
# 添加索引
mysql> ALTER TABLE t_batch ADD INDEX idx_delete_status (delete_status);
Query OK, 0 rows affected (2 min 47.24 sec)

# 执行计划
+----+--------------+------------+------+-------------------+-------------------+---------+-------+---------+------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------+------------+------+-------------------+-------------------+---------+-------+---------+------------------------------------+
| 1 | PRIMARY | b | ref | idx_delete_status | idx_delete_status | 9 | const | 5130952 | Using index condition; Using where |
| 2 | UNION | f | ref | idx_delete_status | idx_delete_status | 9 | const | 20469 | Using index condition; Using where |
| NULL | UNION RESULT | <union1,2> | ALL | NULL | NULL | NULL | NULL | NULL | Using temporary; Using filesort |
+----+--------------+------------+------+-------------------+-------------------+---------+-------+---------+------------------------------------+
3 rows in set (0.07 sec)

模糊查询方法对比:

1
2
3
4
5
6
7
8
① mtl_no like '%0594A%'
10 rows in set (1 min 26.92 sec)

② locate('0594A', mtl_no) > 0
10 rows in set (32.71 sec)

③ instr(mtl_no,'0594A') > 0
10 rows in set (32.72 sec)

结论:

  • 这三种方法都只能用全表扫描的方式进行查询,但 locate 和 instr 方法速度比 like 稍快。
  • like %% 此类模糊查询,推荐使用搜索引擎,比如 Elasticsearch。

Confluence

发表于 2019-10-22 | 更新于 2019-11-15 | 分类于 项目

基础概念

空间(Space)

  • 团队空间:存放与该项目相关的文档信息放置到该空间中,对项目成员开设访问/编辑权限
  • 个人空间:存放工作总结或笔记等文档放置到自己的空间中

页面(Page)

  • 页面是存储和共享信息的主要方式,以树状结构进行组织,放置于空间之中。
  • 页面支持大量的内容展现形式,除了富文本文档外,还包括图表、视频、附件(可预览)、流程图、公式等等,如果还不够,还可以通过海量的第三方插件进行扩展。

权限(Permission)

权限控制分 3 个维度,分别是团队(Group),个人(Individual Users),匿名用户(Anonymous)。

登录

1
2
3
4
5
# 普通地址
http://wiki.qd-aliyun-internal.haier.net

# 管理员地址
http://wiki.qd-aliyun-internal.haier.net/login.action?oauth_sso=false

Jira

发表于 2019-10-22 | 更新于 2019-11-15 | 分类于 项目

简介

JIRA 是 Atlassian 公司的产品,Atlassian 最核心的产品仍然是 JIRA 和 Confluence,JIRA 被业界公认为最好的项目管理和开发管理工具,Confluence 被认为是最好用的企业级知识管理工具。

基本概念

Project

创建项目:项目名称、简称、URL

  • Story:故事

  • Sprint:迭代

  • Backlog:需求列表

  • 项目创建

  • 项目组件和版本

  • 项目角色

Issue

  • 创建、编辑与删除问题

  • 问题跟踪

  • 子任务

Issue Type(问题单类型)

  • Bug - 故障,功能失效
  • Improvement - 提升,既有功能增强
  • New Feature - 新功能
  • Task - 任务
  • Custom Issue - 根据需要客户化定制

Priority(优先级)

  • Highest - 最高级别,表明问题阻塞了业务流程正常进行
  • High - 高级,表明问题引发明显故障,需要紧急关注
  • Medium - 中级,表明问题有一个明显的影响
  • Low - 低级,表明问题有一个轻微的影响
  • Lowest - 最低级

Status(状态)

  • Open - 打开状态,表明问题单已经被创建,等待被分配到开始处理状态
  • In Progress - 处理中状态,表明问题单已经被分配人激活,并处于被处理状态中
  • Resolved - 已解决状态,表明问题已经被处理完成,等待问题报告人的验证。从这个状态,问题单一般可以进一步变更为重新打开状态(Reopened)或关闭状态(Closed)
  • Reopened - 重新打开状态,问题经过验证发现没有被解决,就可以变更到这个状态
  • Closed - 关闭状态,问题被彻底解决就可以转为这个状态

Resolution(解决结果)

  • Fixed - 修复
  • Won’t Fix - 不用修复,例如这个问题所描述的现象已不再有影响了
  • Duplicate - 重复,同其它已经存在的问题重复了,推荐把相关的单子链接起来
  • Incomplete - 未完成,没有足够的信息继续完成这个问题
  • Cannot Reproduce - 不能重现,如果以后有更多信息可以继续可以重新打开这张单子ß
  • Won’t Do - 不做,类似于不用修复的方案,试用于软件项目的默认状态

工作流

Jira 管理员

配置方案

项目报表

敏捷管理

用户、用户组、项目角色配置

  • 问题类型

  • 权限

  • 工作流

登录

1
2
3
4
5
6
7
8
# 普通用户登录
http://jira.qd-aliyun-internal.haier.net

# 管理员登录
http://jira.qd-aliyun-internal.haier.net/login.jsp?oauth_sso=false

# 版本
Jira v8.3.0

最佳使用实践

  • Bug 跟踪管理

  • 任务流程管理

删除任务

  • 权限说明:删除任务需要具备项目管理员权限
  • 项目设置 -> 用户和角色 -> 添加用户到 Administrators 组

雅思

发表于 2019-10-22 | 更新于 2019-10-23 | 分类于 其他

报名

  • 报名入口

  • 考试费用:¥2020

  • 转考费用:¥420

资料

  • 《剑桥雅思官方真题》
  • 《剑桥雅思真题精讲》
  • 《7天搞定雅思高频核心词》
  • 《雅思词汇真经》
  • 《顾家北手把手教你雅思写作》
  • 《雅思王听力真题语料库》

TiDB

发表于 2019-10-22 | 更新于 2019-10-24 | 分类于 数据库

简介

TiDB 是一款定位于在线事务处理/在线分析处理( HTAP: Hybrid Transactional/Analytical Processing)的融合型数据库产品,实现了一键水平伸缩、强一致性的多副本数据安全、分布式事务、实时 OLAP 等重要特性,同时兼容 MySQL 协议和生态,迁移便捷,运维成本极低。

[ 文档 | 代码 | 社区]

部署

1. 安装依赖包

1
$ yum -y install libtool zlib-devel autoconf readline-devel readline libuuid-devel zlib-devel automake libuuid readline-devel readline ncurses-devel.x86_64 ncurses.x86_64 gcc-c++ vim wget net-tools svn libstdc++.so.6 glibc.i686 unzip make lrzsz libtool zlib-devel autoconf readline-devel readline libuuid-devel zlib-devel automake libuuid readline-devel readline ncurses-devel.x86_64 ncurses.x86_64 gcc-c++ vim wget net-tools svn libstdc++.so.6 libcurl-dev libcurl-devel expat-devel perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker zip git gcc openssl-devel libnl3-devel net-snmp-devel libnfnetlink-devel zlib zlib-devel openssl openssl-devel tree lrzsz tree net-tools nmap vim bash-completion lsof dos2unix nc telnet ntp wget rng-tools psmisc screen pcre pcre-devel

2. 安装 TiDB

1
2
3
4
5
6
7
8
9
10
$ cd /usr/local/
$ wget http://download.pingcap.org/tidb-latest-linux-amd64.tar.gz
$ tar -xzf tidb-latest-linux-amd64.tar.gz /usr/local
$ mkdir -p /data/tidb
$ cd /usr/local/tidb-latest-linux-amd64
$ ln -s /usr/local/tidb-latest-linux-amd64/bin/pd-tso-bench /usr/bin
$ ln -s /usr/local/tidb-latest-linux-amd64/bin/tikv-server /usr/bin/
$ ln -s /usr/local/tidb-latest-linux-amd64/bin/tidb-server /usr/bin/
$ ln -s /usr/local/tidb-latest-linux-amd64/bin/pd-server /usr/bin/
$ ln -s /usr/local/tidb-latest-linux-amd64/bin/pd-ctl /usr/bin/

3. 启动 PD

1
2
$ cd bin
$ ./pd-server -data-dir=/data/tidb/pd -log-file=/data/tidb/log/pd.log -name=pd1 &

4. 启动 TiKV

1
$ ./tikv-server --pd="127.0.0.1:2379" --data-dir=/data/tidb/tikv --log-file=/data/tidb/log/tikv.log &

5. 连接 TiDB

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
$ mysql -h 127.0.0.1 -P 4000 -u root

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 12
Server version: 5.7.25-TiDB-v3.0.0-rc.1-290-g21d2590ac MySQL Community Server (Apache License 2.0)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+--------------------+
| Database |
+--------------------+
| INFORMATION_SCHEMA |
| PERFORMANCE_SCHEMA |
| mysql |
| test |
+--------------------+
4 rows in set (0.00 sec)

6. 修改密码

1
2
3
mysql> use mysql; 
mysql> update user set password=PASSWORD("Changeme_123") where User='root';
mysql> flush privileges;

7. 设置远程可访问

1
2
mysql> grant all privileges on *.* to 'root'@'%' identified by 'Changeme_123';
mysql> flush privileges;

Prometheus

发表于 2019-10-22 | 分类于 Prometheus

基础

Prometheus 是一个开源的完整监控解决方案,其对传统监控系统的测试和告警模型进行了彻底的颠覆,形成了基于中央化的规则计算、统一分析和告警的新模型,基于 Golang 编写。

优点

易于管理

Prometheus 基于 Pull 模型的架构方式,可以在任何地方(本地电脑,开发环境,测试环境)搭建我们的监控系统。对于一些复杂的情况,还可以使用 Prometheus 服务发现 (Service Discovery) 能力动态管理监控目标。

强大的数据模型

所有采集的监控数据均以指标 metric 的形式保存在内置的时间序列数据库当中 TSDB。所有的样本除了基本的指标名称以外,还包含一组用于描述该样本特征的标签。

如下所示:

1
2
http_request_status{code='200',content_path='/api/path', environment='produment'} => [value1@timestamp1,value2@timestamp2...]
http_request_status{code='200',content_path='/api/path2', environment='produment'} => [value1@timestamp1,value2@timestamp2...]

每一条时间序列由指标名称 Metrics Name 以及一组标签 Labels 唯一标识。每条时间序列按照时间的先后顺序存储一系列的样本值。表示维度的标签可能来源于你的监控对象的状态,比如 code=404 或者 content_path=/api/path。基于这些 Labels ,我们可以方便地对监控数据进行聚合、过滤、裁剪。

强大的查询语言 PromSQL

Prometheus 内置了一个强大的数据查询语言 PromQL。 通过 PromQL 可以实现对监控数据的查询、聚合。同时 PromQL 也被应用于数据可视化(如 Grafana )以及告警当中。

高效

对于监控系统而言,大量的监控任务必然导致有大量的数据产生。而Prometheus 可以高效地处理这些数据,对于单一 Prometheus Server 实例而言它可以处理:

  • 数以百万的监控指标
  • 每秒处理数十万的数据点

易于集成

Prometheus 社区还提供了大量第三方实现的监控数据采集支持:MySQL、Consul、Redis 等等。

可视化

Prometheus Server 中自带了一个 Prometheus UI,通过这个 UI 可以方便地直接对数据进行查询,并且支持直接以图形化的形式展示数据。开源第三方可视化工具 Grafana 也已经提供了完整的 Prometheus 支持,基于 Grafana 可以创建更加精美的监控图标。

缺点:相比于 zabbix,更加消耗资源

架构

Prometheus architecture

Prometheus Server:是 Prometheus 组件中的核心部分,负责实现对监控数据的获取、存储以及查询。

  • Prometheus Server 可以通过静态配置管理监控目标(prometheus.yml),也可以配合使用 Service Discovery 的方式动态管理监控目标,并从这些监控目标中获取数据。
  • Prometheus Server 需要对采集到的监控数据进行存储,它本身就是一个时序数据库,将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。
  • Prometheus Server 对外提供了自定义的 PromQL 语言,实现对数据的查询以及分析。

exporters:负责将监控数据采集的端点通过 HTTP 服务的形式暴露给 Prometheus Server,Prometheus Server 通过访问该 exporter 提供的 Endpoint 端点,即可获取到需要采集的监控数据。一般来说可以将exporter 分为 2 类:

  • 直接采集:这一类 exporter 直接内置了对 Prometheus 监控的支持,例如:Kubernetes。
  • 间接采集:原有监控目标并不直接支持 Prometheus,因此我们需要通过 Prometheus 提供的 Client Library 编写该监控目标的监控采集程序。例如:监控主机有 node_exporter,监控 MySQL 有 mysqld_exporter。

Pushgateway:由于 Prometheus 数据采集基于 Pull 模型进行设计,因此在网络环境的配置上必须要让Prometheus Server 能够直接与 exporter 进行通信。 当这种网络需求无法直接满足时,就可以利用PushGateway 来进行中转。可以通过 PushGateway 将内部网络的监控数据主动 Push 到 Gateway 当中。而 Prometheus Server 则可以采用同样 Pull 的方式从 PushGateway 中获取到监控数据。

Alertmanager:在 Prometheus Server 中支持基于 PromQL 创建告警规则,如果满足 PromQL 定义的规则,则会产生一条告警,而告警的后续处理流程则由 AlertManager 进行管理。在 AlertManager 中我们可以与邮件,Slack 等等内置的通知方式进行集成,也可以通过 Webhook 自定义告警处理方式。AlertManager 即 Prometheus 体系中的告警处理中心。

Web UI:数据可视化,主要使用第三方工具 Grafana 来实现。

安装

Prometheus Server

二进制包方式安装

(1)下载最新版本 软件包

(2)解压

1
2
3
wget https://github.com/prometheus/prometheus/releases/download/v2.12.0/prometheus-2.12.0.linux-amd64.tar.gz
tar -xzf prometheus-2.12.0.linux-amd64.tar.gz
cd prometheus-2.12.0.linux-amd64

(3)配置文件 promethes.yml,修改 job_name。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'

# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.

static_configs:
- targets: ['localhost:9090']

(4)创建数据存储目录,默认的存储路径为 data/,用户也可以通过参数 --storage.tsdb.path="data/" 修改本地数据存储的路径。

1
mkdir -p data

(5)启动 prometheus 服务,http://10.133.0.53:9090

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ ./prometheus
level=info ts=2019-08-26T07:33:43.420Z caller=main.go:293 msg="no time or size retention was set so using the default time retention" duration=15d
level=info ts=2019-08-26T07:33:43.420Z caller=main.go:329 msg="Starting Prometheus" version="(version=2.12.0, branch=HEAD, revision=43acd0e2e93f9f70c49b2267efa0124f1e759e86)"
level=info ts=2019-08-26T07:33:43.420Z caller=main.go:330 build_context="(go=go1.12.8, user=root@7a9dbdbe0cc7, date=20190818-13:53:16)"
level=info ts=2019-08-26T07:33:43.421Z caller=main.go:331 host_details="(Linux 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 ptdsmapp05 (none))"
level=info ts=2019-08-26T07:33:43.421Z caller=main.go:332 fd_limits="(soft=65536, hard=65536)"
level=info ts=2019-08-26T07:33:43.421Z caller=main.go:333 vm_limits="(soft=unlimited, hard=unlimited)"
level=info ts=2019-08-26T07:33:43.423Z caller=web.go:448 component=web msg="Start listening for connections" address=0.0.0.0:9090
level=info ts=2019-08-26T07:33:43.423Z caller=main.go:654 msg="Starting TSDB ..."
level=info ts=2019-08-26T07:33:43.442Z caller=head.go:509 component=tsdb msg="replaying WAL, this may take awhile"
level=info ts=2019-08-26T07:33:43.445Z caller=head.go:557 component=tsdb msg="WAL segment loaded" segment=0 maxSegment=0
level=info ts=2019-08-26T07:33:43.446Z caller=main.go:669 fs_type=XFS_SUPER_MAGIC
level=info ts=2019-08-26T07:33:43.446Z caller=main.go:670 msg="TSDB started"
level=info ts=2019-08-26T07:33:43.446Z caller=main.go:740 msg="Loading configuration file" filename=prometheus.yml
level=info ts=2019-08-26T07:33:43.448Z caller=main.go:768 msg="Completed loading of configuration file" filename=prometheus.yml
level=info ts=2019-08-26T07:33:43.448Z caller=main.go:623 msg="Server is ready to receive web requests."

docker 方式安装

直接使用 Prometheus 的镜像即可启动 Prometheus Server。启动完成后,可以通过 http://10.133.0.53:9090 访问 UI 界面:

1
docker run -p 9090:9090 -v /etc/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus

Prometheus UI

node_exporter

采集主机的运行指标如 CPU、内存、磁盘等信息。同样采用 Golang 编写,并且不存在任何的第三方依赖。

1
2
3
4
5
wget https://github.com/prometheus/node_exporter/releases/download/v0.18.1/node_exporter-0.18.1.linux-amd64.tar.gz
tar -xzf node_exporter-0.18.1.linux-amd64.tar.gz
cd node_exporter-0.18.1.linux-amd64
cp node_exporter-0.18.1.linux-amd64/node_exporter /usr/local/bin
./node_exporter

启动成功后,可以看到如下输出:

1
INFO[0000] Listening on :9100                            source="node_exporter.go:170"

访问 http://10.133.0.53:9100/metrics,可以看到采集到的监控数据:

1
2
3
4
5
6
# HELP node_cpu Seconds the cpus spent in each mode.
# TYPE node_cpu counter
node_cpu{cpu="cpu0",mode="idle"} 362812.7890625
# HELP node_load1 1m load average.
# TYPE node_load1 gauge
node_load1 3.0703125

HELP:解释当前指标的含义。

TYPE:说明当前指标的数据类型。有四种数据类型,counter(计数器)、gauge(仪表盘)、histogram(直方图)、summary(求和)

除了这些之外,还可以看到如下监控指标:

  • node_boot_time:系统启动时间
  • node_cpu:系统 CPU 使用量
  • node_disk_*:磁盘 IO
  • node_filesystem_*:文件系统用量
  • node_load1:系统负载
  • node_memeory_*:内存使用量
  • node_network_*:网络带宽
  • node_time:当前系统时间
  • go_*:node_exporter 中 go 相关指标
  • process_*:node_exporter 自身进程相关运行指标

mysqld_exporter

(1)下载二进制包

1
2
3
wget https://github.com/prometheus/mysqld_exporter/releases/download/v0.12.1/mysqld_exporter-0.12.1.linux-amd64.tar.gz
tar -xzf mysqld_exporter-0.12.1.linux-amd64.tar.gz
cd mysqld_exporter-0.12.1.linux-amd64

(2)编辑 .my.cnf

1
2
3
4
5
[client]
user=hdm
password=Hdm@123!
host=10.133.0.53
port=3306

(3)启动 mysqld_exporter,默认端口是 9104,可以看到采集到的 MySQL Metrics。

1
./mysqld_exporter --config.my-cnf=/data/mysqld_exporter-0.12.1.linux-amd64/.my.cnf

数据收集

为了能够让 Prometheus Server 能够从当前 node_exporter 获取到监控数据,这里需要修改 Prometheus 配置文件,编辑 prometheus.yml 并在 scrape_configs 节点下添加以下内容:

1
2
3
4
5
6
7
8
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
# 采集node exporter监控数据
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']

重新启动 Prometheus Server,访问 http://10.133.0.53:9090,进入到 Prometheus Server。如果输入 up 并且点击执行按钮以后,可以看到如下结果:

image-20190826215234095

如果 Prometheus 能够正常从 node_exporter 获取数据,则会看到以下结果:

1
2
up{instance="localhost:9090",job="prometheus"}	1
up{instance="localhost:9100",job="node"} 1

其中 "1" 表示正常,反之 "0" 则为异常。

数据模型

Prometheus 存储的是 时序数据,即按照相同时序(相同的名字和标签),以时间维度存储连续的数据的集合。时序(Time Series)是由名字(Metric),以及一组 key/value 标签定义的,具有相同的名字以及标签属于相同时序。时序的名字由 ASCII 字符、数字、下划线、以及冒号组成,它必须满足正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]*, 其名字应该具有语义化,一般表示一个可以度量的指标,例如: http_requests_total, 可以表示 http 请求的总数。

时序的标签可以使 Prometheus 的数据更加丰富,能够区分具体不同的实例,例如 http_requests_total{method="POST"} 可以表示所有 Http 中的 POST 请求。标签名称由 ASCII 字符,数字,以及下划线组成, 其中 __ 开头属于 Prometheus 保留,标签的值可以是任何 Unicode 字符,支持中文。

1
<metric name>{<label name>=<label value>, ...}

数据可视化

Prometheus UI 提供了快速验证 PromQL 以及临时可视化支持的能力,而在大多数场景下引入监控系统通常还需要构建可以长期使用的监控数据可视化面板( Dashboard )。这时用户可以考虑使用第三方的可视化工具如Grafana,Grafana 是一个开源的可视化平台,并且提供了对 Prometheus 的完整支持。

安装 Grafana(使用向导:安装 -> 添加数据源 -> 创建 Dashboard -> 邀请成员 -> 安装应用和插件)

1
2
3
4
5
6
7
8
9
10
11
12
13
docker方式:
docker run -d -p 3000:3000 grafana/grafana

二进制包方式:
wget https://dl.grafana.com/oss/release/grafana-6.3.3.linux-amd64.tar.gz
tar -zxvf grafana-6.3.3.linux-amd64.tar.gz

rpm方式:
wget https://dl.grafana.com/oss/release/grafana-6.3.3-1.x86_64.rpm
sudo yum localinstall grafana-6.3.3-1.x86_64.rpm

Pie Chart插件:
grafana-cli plugins install grafana-piechart-panel

访问 http://10.133.0.53:3000 就可以进入到 Grafana 的界面中,默认情况下使用账户 admin/admin 进行登录

任务和实例

在 Prometheus 中,每一个暴露监控样本数据的 HTTP 服务称为一个实例。例如在当前主机上运行的 node_exporter 可以被称为一个实例(Instance)。

1
2
3
4
5
6
7
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']

而一组用于相同采集目的的实例,或者同一个采集进程的多个副本则通过一个任务(Job)进行管理。

1
2
3
* job: node
* instance 2: 1.2.3.4:9100
* instance 4: 5.6.7.8:9100

当前在每一个 Job 中主要使用了静态配置(static_configs)的方式定义监控目标,Prometheus 还支持与 Consul、Kubernetes 等进行集成实现自动发现实例,并从这些实例上获取监控数据。可以访问 targets 直接查看当前所有的任务以及每个任务对应的实例信息。

服务发现

Push vs Pull

Push

如上所示,展示了 Push 系统和 Pull 系统的核心差异。相较于 Push 模式,Pull 模式的优点可以简单总结为以下几点:

  • 只要 exporter 在运行,你可以在任何地方(比如在本地),搭建你的监控系统;
  • 你可以更容易的查看监控目标实例的健康状态,并且可以快速定位故障;
  • 更利于构建 DevOps 文化的团队;
  • 松耦合的架构模式更适合于云原生的部署环境。

Consul

Consul:由 HashiCorp 开发的一个支持多数据中心的分布式服务发现和键值对存储服务的开源软件,被大量应用于基于微服务的软件架构当中,使用 Golang 语言开发。

安装

下载二进制包

与 Prometheus 集成

PromQL

PromQL(Prometheus Query Language),是 Prometheus 自己开发的数据查询 DSL 语言,PromQL 作为Prometheus 的核心能力除了实现数据的对外查询和展现,同时告警监控也是依赖 PromQL 实现的。

时间序列

Prometheus 可以采集到当前主机所有监控指标的样本数据,例如:

1
2
3
4
5
6
# HELP node_cpu Seconds the cpus spent in each mode.
# TYPE node_cpu counter
node_cpu{cpu="cpu0",mode="idle"} 362812.7890625
# HELP node_load1 1m load average.
# TYPE node_load1 gauge
node_load1 3.0703125

其中非 # 开头的每一行表示当前 node_exporter 采集到的一个监控样本:node_cpu 和 node_load1 表明了当前指标的名称、大括号中的标签则反映了当前样本的一些特征和维度、浮点数则是该监控样本的具体值。

样本

Prometheus 会将所有采集到的样本数据以时间序列(time-series)的方式保存在内存数据库中,并且定时保存到硬盘上。如下所示,可以将 time-series 理解为一个以时间为 Y 轴的数字矩阵:

1
2
3
4
5
6
7
^
│ . . . . . . . . . . . . . . . . . . . node_cpu{cpu="cpu0",mode="idle"}
│ . . . . . . . . . . . . . . . . . . . node_cpu{cpu="cpu0",mode="system"}
│ . . . . . . . . . . . . . . . . . . node_load1{}
│ . . . . . . . . . . . . . . . . . .
v
<------------------ 时间 ---------------->

在 time-series 中的每一个点称为一个样本(sample),样本由以下三部分组成:

  • 指标 (metric):metric name 和描述当前样本特征的 label sets。
  • 时间戳 (timestamp):一个精确到毫秒的时间戳。
  • 样本值 (value): 一个 folat64 的浮点型数据表示当前样本的值。
1
2
3
4
5
6
7
8
9
<--------------- metric ---------------------><-timestamp -><-value->
http_request_total{status="200", method="GET"}@1434417560938 => 94355
http_request_total{status="200", method="GET"}@1434417561287 => 94334

http_request_total{status="404", method="GET"}@1434417560938 => 38473
http_request_total{status="404", method="GET"}@1434417561287 => 38544

http_request_total{status="200", method="POST"}@1434417560938 => 4748
http_request_total{status="200", method="POST"}@1434417561287 => 4785

指标 (Metric)

在形式上,所有的指标 (Metric) 都通过如下格式标示:

1
<metric name>{<label name>=<label value>, ...}

指标名称(metric name):反映监控样本的含义。

标签(label):反映当前样本的特征维度。

指标类型:Counter(计数器)、Gauge(仪表盘)、Histogram(直方图)、Summary(摘要)

Counter:只增不减的计数器

Gauge:可增可减的仪表盘

使用 Histogram 和 Summary 分析数据分布情况

告警

项目

发表于 2019-10-22 | 更新于 2020-04-29 | 分类于 项目

监控告警

背景:为了托管已上线 MySQL 系统,建立完善的监控体系,提升业务系统稳定性,达到以下 3 个目的:

  • 告警:当系统出现或者即将出现故障时,监控系统需要迅速反应并通知管理员,从而能够对问题进行快速的处理或者提前预防问题的发生,避免出现对业务的影响。
  • 故障分析与定位:当问题发生后,需要对问题进行调查和处理。通过对不同监控监控以及历史数据的分析,能够找到并解决根源问题。
  • 数据可视化:通过可视化仪表盘能够直接获取系统的运行状态、资源使用情况、以及服务运行状态等直观的信息。

技术方案:[Prometheus] [Grafana] [Consul] [PMM]

运维工单

背景:日常运维问题繁多,提高运维效率。

技术方案:[Golang] [Vue] [Element UI] [HeidiSQL] [Percona Toolkit]

备份

背景:上线项目系统(MySQL、Oracle、Server SQL、小型机、etc. )之前未做备份恢复演练,也有部分上线系统未备份,存在巨大的数据安全风险,全量排查消除隐患。

技术方案:[Commvault] [Percona XtraBackup]

优化

背景:数据库 slowlog 发布每周报告,需要从管理视角驱动质量提升,展现技术平台的价值。

技术方案:[HDM] [Percona Toolkit]

堡垒机

背景:核心功能是用于实现对运维操作人员的权限控制与操作行为审计,工作原理

技术方案:[Jumpserver]

容灾

背景:为解决本地机房发生重大灾难,数据不可恢复,特在红岛建立的灾备数据中心。

技术方案:[容灾]

数据库运维平台

项目架构图

  • nginx:负载均衡
  • vue:前端开发框架
  • webpack:打包部署
  • rest api:为前端提供接口
  • service:处理业务逻辑
  • dao:操作 mysql 接口
  • cache:操作 redis 接口
  • mysql:数据库存储
  • redis:缓存
1…101112…18
Hui Rao

Hui Rao

最好的成长是分享
173 日志
19 分类
14 标签
GitHub E-Mail
© 2021 Hui Rao
由 Hexo 强力驱动 v3.9.0
|
主题 – NexT.Gemini v7.1.0
|