
# 安装

下载地址: [https://www.percona.com/downloads/percona-toolkit/LATEST/](https://www.percona.com/downloads/percona-toolkit/LATEST/)

官方文档: [https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html](https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html)

下载依赖包：

```
yum -y install perl-Digest-MD5 perl-DBI perl-DBD-MySQL perl-Time-HiRes perl-IO-Socket-SSL
```

# 执行

增加一列：

```
/bin/pt-online-schema-change --print --execute --alter "ADD COLUMN test varchar(255) NOT NULL DEFAULT '' COMMENT '测试pt' AFTER status" D=videos_t,t=media_copy1,u=root,p=123456
```

看下执行过程:

```shell
[root@douyacun percona-toolkit-3.1.0]# ./bin/pt-online-schema-change --print --execute --alter "ADD COLUMN test varchar(255) NOT NULL DEFAULT '' COMMENT '测试pt' AFTER status" D=videos_t,t=media_copy1,u=root,p=123456
No slaves found.  See --recursion-method if host home has slaves.
Not checking slave lag because no slaves were found and --check-slave-lag was not specified.
Operation, tries, wait:
  analyze_table, 10, 1
  copy_rows, 10, 0.25
  create_triggers, 10, 1
  drop_triggers, 10, 1
  swap_tables, 10, 1
  update_foreign_keys, 10, 1
Altering `videos_t`.`media_copy1`...
Creating new table...
CREATE TABLE `videos_t`.`_media_copy1_new` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',
  `subtype` varchar(15) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '分类分类',
  `title` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '标题',
  `subject` bigint(19) unsigned DEFAULT NULL COMMENT '豆瓣subject，唯一索引',
  `source` tinyint(1) unsigned NOT NULL DEFAULT '1' COMMENT '1: 豆瓣 2: 百度百科 …',
  `torrent_num` smallint(6) unsigned NOT NULL DEFAULT '0' COMMENT '种子数量',
  `tags` varchar(255) NOT NULL COMMENT '标签',
  `original_title` varchar(500) NOT NULL DEFAULT '' COMMENT '原标题',
  `directors` varchar(500) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '导演',
  `casts` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL COMMENT ' 演员阵容',
  `genres` varchar(60) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '类型',
  `released` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '上映时间',
  `released_timestamp` timestamp NULL DEFAULT NULL,
  `alias` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '别名',
  `summary` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '摘要',
  `rate` float(3,2) unsigned NOT NULL DEFAULT '0.00' COMMENT '豆瓣得分',
  `duration` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '片长',
  `region` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '地区',
  `language` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '语言',
  `official_website` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '官网',
  `poster` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '海报',
  `cover` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '视频封面',
  `new_cover` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '解析下载以后的封面',
  `current_season` int(11) unsigned NOT NULL DEFAULT '0' COMMENT '更新集数',
  `episodes_update` int(11) unsigned NOT NULL DEFAULT '0',
  `episodes_count` int(11) unsigned NOT NULL DEFAULT '0' COMMENT '总集数',
  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `status` tinyint(3) NOT NULL DEFAULT '0' COMMENT '状态',
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE KEY `med` (`subject`,`source`) USING BTREE,
  KEY `idx_title` (`title`) USING BTREE,
  KEY `idx_torrent_num` (`torrent_num`),
  KEY `idx_rate` (`rate`) USING BTREE,
  KEY `idx_created_at` (`created_at`) USING BTREE,
  KEY `idx_tags` (`tags`),
  KEY `idx_subtype_genres` (`subtype`,`genres`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=194664 DEFAULT CHARSET=utf8 COMMENT='视频库'
Created new table videos_t._media_copy1_new OK.
Altering new table...
ALTER TABLE `videos_t`.`_media_copy1_new` ADD COLUMN test varchar(255) NOT NULL DEFAULT '' COMMENT '测试pt' AFTER status
Altered `videos_t`.`_media_copy1_new` OK.
2020-01-15T21:59:11 Creating triggers...
2020-01-15T21:59:11 Created triggers OK.
2020-01-15T21:59:11 Copying approximately 167063 rows...
INSERT LOW_PRIORITY IGNORE INTO `videos_t`.`_media_copy1_new` (`id`, `subtype`, `title`, `subject`, `source`, `torrent_num`, `tags`, `original_title`, `directors`, `casts`, `genres`, `released`, `released_timestamp`, `alias`, `summary`, `rate`, `duration`, `region`, `language`, `official_website`, `poster`, `cover`, `new_cover`, `current_season`, `episodes_update`, `episodes_count`, `created_at`, `updated_at`, `status`) SELECT `id`, `subtype`, `title`, `subject`, `source`, `torrent_num`, `tags`, `original_title`, `directors`, `casts`, `genres`, `released`, `released_timestamp`, `alias`, `summary`, `rate`, `duration`, `region`, `language`, `official_website`, `poster`, `cover`, `new_cover`, `current_season`, `episodes_update`, `episodes_count`, `created_at`, `updated_at`, `status` FROM `videos_t`.`media_copy1` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= ?)) AND ((`id` <= ?)) LOCK IN SHARE MODE /*pt-online-schema-change 24862 copy nibble*/
SELECT /*!40001 SQL_NO_CACHE */ `id` FROM `videos_t`.`media_copy1` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= ?)) ORDER BY `id` LIMIT ?, 2 /*next chunk boundary*/
Copying `videos_t`.`media_copy1`:  32% 01:03 remain
Copying `videos_t`.`media_copy1`:  61% 00:36 remain
Copying `videos_t`.`media_copy1`:  86% 00:13 remain
2020-01-15T22:00:55 Copied rows OK.
2020-01-15T22:00:55 Analyzing new table...
2020-01-15T22:00:55 Swapping tables...
RENAME TABLE `videos_t`.`media_copy1` TO `videos_t`.`_media_copy1_old`, `videos_t`.`_media_copy1_new` TO `videos_t`.`media_copy1`
2020-01-15T22:00:56 Swapped original and new tables OK.
2020-01-15T22:00:56 Dropping old table...
DROP TABLE IF EXISTS `videos_t`.`_media_copy1_old`
2020-01-15T22:00:57 Dropped old table `videos_t`.`_media_copy1_old` OK.
2020-01-15T22:00:57 Dropping triggers...
DROP TRIGGER IF EXISTS `videos_t`.`pt_osc_videos_t_media_copy1_del`
DROP TRIGGER IF EXISTS `videos_t`.`pt_osc_videos_t_media_copy1_upd`
DROP TRIGGER IF EXISTS `videos_t`.`pt_osc_videos_t_media_copy1_ins`
2020-01-15T22:00:57 Dropped triggers OK.
Successfully altered `videos_t`.`media_copy1`.
```

**详细执行流程如下：**

1. 相关环境参数检查
2. 检查该表格是否存在
3. show create table media_copy1
4. create table _media_copy1_new
5. alter table _media_copy1_new 
6. 创建删除触发器: `pt_osc_videos_t_media_copy1_del` , (如果数据修改的时候，还没有拷贝过来，修改后再拷贝则是覆盖，正确；如果是已经拷贝过来，再修改，也是正确，这里同时会检查是否具有主键或者唯一索引，如果都没有，这一步会报错，提示The new table `videos_t`.`_media_copy1_new` does not have a PRIMARY KEY or a unique index which is required for the DELETE trigger.)
7. 创建更新触发器：`pt_osc_videos_t_media_copy1_upd`
8. 创建插入触发器：`pt_osc_videos_t_media_copy1_ins`
9. 按块拷贝数据到新表，拷贝过程对数据行持有S锁
10. analyze 新表
11. rename 表名，`RENAME TABLE videos_t.media_copy1 TO videos_t._media_copy1_old, videos_t._media_copy1_new TO videos_t.media_copy1`
12. 删除旧表
13. 删除新表上的删除、更新、插入 触发器

**DSN 选项**

- A 字符集设置
- D 需要Alter的表格是在哪个数据库，指定数据库
- F mysql read default file，如果数据源的相关选项存储在文件中，则通过 F 来指定
- h host，数据库主机名或IP
- p password，数据库用户的密码
- P port，数据库实例端口号
- S socket，实例socket文件
- t 表格名
- u 用户名

**从库延迟情况**

- --max-lag：默认1s，检查从库延迟情况，如果超过，则停止copy data，休息--check-interval秒后，再重新开始copy数据
- --check-interval：从库延迟超过指定的--max-lag，中断copy data休息的时间
- --recursion-method：MASTER寻找SLAVE的方式
  - processlist: 使用show processlist查找从库
  - hosts: 不是使用默认端口号3306，那么使用hosts方式来查找从库会更可靠
  - dsn: 手动在需要DDL的数据库内，创建 dsns 表格, pt会从表各种读取从库信息
    - `CREATE TABLE dsns (id int(11) NOT NULL AUTO_INCREMENT,parent_id int(11) DEFAULT NULL,dsn varchar(255) NOT NULL, PRIMARY KEY (id))`
    - 存储从库信息
    - insert into dsns(dsn) values(h=slave_host,u=repl_user,p=repl_password,P=port );
    - 该参数使用的时候，按以下格式（假设 dsns表格建立在数据库 dbosc）
  - none：不查找从库
- --check-slave-lag

**执行选项**

- --execute : 确定执行 alter 操作，如果不指定的话，只会做安全检查操作，类似于`nginx -t`
- --alter : 不包含前面的 `alter table t`

**打印选项**

- --print： 详细打印alter过程，不指定的时候，简略打印
- --statistics： 增加影响行数打印，可以查看copy进度

**服务器负载**

- --max-load： 
  - 默认为Threads_running=25
  - 每个chunk拷贝完后，会检查SHOW GLOBAL STATUS的内容，检查指标是否超过了指定的阈值,超过了就暂停

- --critical-load:
  - 默认为Threads_running=50
  - 类似`--max-load`,如果超过指定值，则工具直接退出，而不是暂停。

# 安全

- 大部分情况下，pt会拒绝给没有主键和唯一键的表做变更
- 如果发现影响主从超时厉害，max-lag参数要配置一下
- 如果发现服务器负载非常高，也会暂停或停止相关操作。`-—max-load`, `--critical-load`要配置一下
- 默认会设置 innodb_lock_wait_timeout=1 和 lock_wait_timeout=60来减少竞争
- 如果有外键约束，那么禁止改表，指定 —alter-foreign-keys-method.

# 使用限制

1. 禁止创建唯一索引，会丢失数据，更加不允许添加 --alter-check=no，--check-unique-key-change=no  
2. 如果原表没有主键，或者也没有唯一索引，这些表是不允许用pt做DDL的  
3. 禁止对外键的表进行pt ddl
4. 禁止对表进行重命名
5. 禁止对列进行重命名，如果一定要做，也必须先print出来检测清楚列名是否正确  
6. 新增字段，NOT NULL必须要指定默认值
7. 不允许删除主键


热表、大表怎么变更表结构？虽然知道pt，但是真正用过吗，有啥限制知道吗？

pt-online-scheme-change使用


今天是2020年1月16号，记录这周发生的一件充值事故，1月12号周一下班后被通知某家代理商出现消耗金额超过充值金额800多万，当时第一反应是计费又出问题了，要帮忙定位问题，在家连zoom，翻看整个代理商从开户到现在每个月的充值数据，然后查询代理商每个月月月初的账户数据快照（实际每天晚上23:59都会快照一份存在hive中），一直到了晚上12点半，一直没有定位到问题出现的原因，然后领导就下线睡觉了，这个问题也出现一段时间不急于这一天了。

1月17号，大家都在吐槽年底了，为啥比平时还忙。针对昨天的bug，领导去支持了，我这边手上有两个大的功能点需要迭代上线。晚上回家后，被通知问题出现平台充值这边，不是计费的问题，头大，通过充值数据和消耗数据对比发现11月之前的正常的，12月开始出现消费大于充值金额；问题出现在11月份，还是完全没有思路，因为还是没有证据确定是充值问题还是计费问题，后续还是在翻看一直到12点半。

1月18号，下午定了一个会议室，专门来查这件事情，从代理商充值开始到12月1号00:00充值金额 - 12月1号00:00代理商下所有广告主的消耗金额 - 12月1号00:00代理商剩余金额 - 12月1号00:00代理商下广告主剩余金额。发现差值有：8486863.50元，这个时候可以错略确定的是充值问题，计费不会出现这么大的问题，而且19年1月份计费没有出现过重大bug。翻看代理商的充值记录有一条:8525163.53, 数值相近。不会是巧合，而且充值一般都是整数，问题出现了。

记得当时代理商是要预充值3000万，而数据库充值记录的金额字段是用的int(11), 单位：分，最多能存2147483647，所以当时后来又给代理商补了8525163.53，按道理这会应该it

也没有问题，问题出现账户表上，充值记录金额是有符号的，而账户余额是unsigned无符号的, 最大值到4294967295，是能存下3000万的。虽然充值记录显示2147483647，但实际账户确实是充值了3000万。

**充值是有事务的，为啥没有回滚？如何避免这种情况的发生**

MySQL默认情况下，当一个数据超出定义列的数据类型的范围时，数据会以数据类型所充许的最大值存储。不会出现报错，事务没有回滚。

在这种情况下，我们希望在插入或更新字段时，如果插入或更新的值超出定义的字段数据类型的范围时，提出报错，禁示修改数据，通过修改全局变量sq_mode   `STRICT_ALL_TABLES` 实现

```
[SQL] insert into t6(`num`) value(2147483648);
[Err] 1264 - Out of range value for column 'num' at row 1
```

**充值没有监控吗？为啥会出现这么重大bug**

功能版本迭代，开始建表是int，后续有种改不动的感觉。大家都开始回避这个棘手问题。直至出现这样的问题，所以监控是非常必要的，代理商自助充值的功能也是在出现问题增加的监控，这是第二次出现充值问题。

**总结**， 经历两次充值事故后了以下几点：

- 充值类型：`big int`, `decimal`，其他类型就不要考虑了，留坑而已
- 充值sql_mod的session连接，一定要设置成为 `STRICT_ALL_TABLES`
- 充值记录要完善，充值记录，账户充值后快照记录，多写一份数据备份记录，意味着可以更快的定位问题
- 监控，对充值逻辑的反向验证，这个根据具体业务实现逻辑来。走社会主义特色道路。
- 数据快照，公司重要数据一定要做每日快照，像这次如果没有代理商账户的每日快照数据备份，即便定位到了问题，也没有证据充分证明这件事，追账打官司复杂多就高了。

最后这两点不管是用在哪里都合适，就是因为用在哪里都合适所以很难重视起来，只有吃过亏的才知道。

最近公司审计发现某家代理商的消耗数据要比充值金额多出来了几百万？

int导致的充值事故报告


家里一台联想笔记本作为爬虫服务器，有一台公网阿里云服务器，目的爬虫跑完之后，公网服务器可以主从同步，家里的服务器和公网服务器通信的问题通过[内网穿透工具(frp)](https://github.com/fatedier/frp)解决, 优秀简单，具体可以看[frp内网穿透_mysql服务_ssh服务_http服务](/linux/frp内网穿透_mysql服务_ssh服务_http服务.md)

MYSQL主从同步是在MySQL主从复制(Master-Slave Replication)基础上实现的，通过设置在Master MySQL上的binlog(使其处于打开状态)，Slave MySQL上通过一个I/O线程从Master MySQL上读取binlog，然后传输到Slave MySQL的中继日志中，然后Slave MySQL的SQL线程从中继日志中读取中继日志，然后应用到Slave MySQL的数据库中。这样实现了主从数据同步功能。

# 配置

## 主库

1. 配置
```conf
# 日志文件名
log-bin = mysql-bin

# 主数据库端ID号
server-id = 1

# 不同步哪些数据库
binlog-ignore-db = mysql
binlog-ignore-db = test
binlog-ignore-db = information_schema

# 只同步哪些数据库，除此之外，其他不同步
binlog-do-db = game

# 日志保留时间
expire_logs_days = 10

# 控制binlog的写入频率。每执行多少次事务写入一次
# 这个参数性能消耗很大，但可减小MySQL崩溃造成的损失
sync_binlog = 5

# 日志格式，建议默认mixed
# statement 保存SQL语句
# row 保存影响记录数据
# mixed 前面两种的结合
binlog_format = mixed
```

2. 重启数据库，创建同步账户
```sql
-- 创建slave帐号slave，密码123456, 这里host 是 127.0.0.1，frp连接的内网，不需要开放，大家可以写成%
grant replication slave on *.* to 'slave'@'127.0.0.1' identified by '123456';


CREATE DATABASE videos DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci;

-- 更新数据库权限
flush privileges;
```
> 可以去这里看[frp内网穿透_mysql服务_ssh服务_http服务](/linux/frp内网穿透_mysql服务_ssh服务_http服务.md)

1. 查询master的状态
```
mysql> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      196 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set
```

## 从库

1. 配置
```conf
log-bin=mysql-bin
server-id=20
```

2. 执行同步命令
```sql
-- 执行同步命令，设置主数据库ip，同步帐号密码，同步位置
change master to master_host='127.0.0.1',master_port=3307, master_user='slave',master_password='123456',master_log_file='mysql-bin.000003',master_log_pos=151459295;

-- 开启同步功能
start slave;
```

3. 检查从库状态, 在执行几条sql看看sql同步情况
```
mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 127.0.0.1
                  Master_User: slave
                  Master_Port: 3307
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 185295
               Relay_Log_File: 00h-relay-bin.000002
                Relay_Log_Pos: 756
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes    -----------> 这里是连接成功
            Slave_SQL_Running: Yes    -----------> 这里sql执行成功
            ......
1 row in set (0.00 sec)
```

4. 常用
```sql
-- 停止主从同步
stop slave;

-- 连接断开时，重新连接超时时间
change master to master_connect_retry=50;

-- 开启主从同步
start slave;
```


# 关于`binlog`和`relaylog`

## 格式化

主库binlog
```
 mysqlbinlog --base64-output=decode-rows -v -v /var/lib/mysql/mysql-bin.000001 > binlog
```

从库relaylog
```
mysqlbinlog --base64-output=decode-rows -v -v mysql-relay-bin.000001 > relaylog
```

##  binlog和relaylog的rotate机制
binlog
- Rotate：每一条binary log写入完成后，都会判断当前文件是否超过 max_binlog_size(默认1g)，如果超过则自动生成一个binlog file
- delete: expire-logs-days 只在 实例启动时 和 flush logs 时以及文件文件是否超过 max_binlog_size时判断是否有过期的binlog文件，如果文件访问时间早于设定值，则purge file

relaylog
- Rotate：每从Master fetch一个events后，判断当前文件是否超过 max_relay_log_size（默认1g) 如果超过则自动生成一个新的relay-log-file
- Delete：purge-relay-log 在SQL Thread每执行完一个events时判断，如果该relay-log 已经不再需要则自动删除


## 配置解析

binlog 配置
```
mysql> show variables like "%bin%";
+--------------------------------------------+--------------------------------+
| Variable_name                              | Value                          |
+--------------------------------------------+--------------------------------+
| bind_address                               | *                              |
| binlog_cache_size                          | 32768                          |
| binlog_checksum                            | CRC32                          |
| binlog_direct_non_transactional_updates    | OFF                            |
| binlog_error_action                        | ABORT_SERVER                   |
| binlog_format                              | ROW                            |
| binlog_group_commit_sync_delay             | 0                              |
| binlog_group_commit_sync_no_delay_count    | 0                              |
| binlog_gtid_simple_recovery                | ON                             |
| binlog_max_flush_queue_time                | 0                              |
| binlog_order_commits                       | ON                             |
| binlog_row_image                           | FULL                           |
| binlog_rows_query_log_events               | OFF                            |
| binlog_stmt_cache_size                     | 32768                          |
| binlog_transaction_dependency_history_size | 25000                          |
| binlog_transaction_dependency_tracking     | COMMIT_ORDER                   |
| innodb_api_enable_binlog                   | OFF                            |
| innodb_locks_unsafe_for_binlog             | OFF                            |
| log_bin                                    | ON                             |
| log_bin_basename                           | /var/lib/mysql/mysql-bin       |
| log_bin_index                              | /var/lib/mysql/mysql-bin.index |
| log_bin_trust_function_creators            | OFF                            |
| log_bin_use_v1_row_events                  | OFF                            |
| log_statements_unsafe_for_binlog           | ON                             |
| max_binlog_cache_size                      | 18446744073709547520           |
| max_binlog_size                            | 1073741824                     |
| max_binlog_stmt_cache_size                 | 18446744073709547520           |
| sql_log_bin                                | ON                             |
| sync_binlog                                | 1                              |
+--------------------------------------------+--------------------------------+
29 rows in set (0.01 sec)
```

- log_bin
设置此参数表示启用binlog功能，并指定路径名称
- log_bin_index
设置此参数是指定二进制索引文件的路径与名称
- binlog_do_db
此参数表示只记录指定数据库的二进制日志
- binlog_ignore_db
此参数表示不记录指定的数据库的二进制日志
- max_binlog_cache_size
此参数表示binlog使用的内存最大的尺寸
- binlog_cache_size
此参数表示binlog使用的内存大小，可以通过状态变量binlog_cache_use和binlog_cache_disk_use来帮助测试。
- binlog_cache_use：使用二进制日志缓存的事务数量
- binlog_cache_disk_use:使用二进制日志缓存但超过binlog_cache_size值并使用临时文件来保存事务中的语句的事务数量
- max_binlog_size
Binlog最大值，最大和默认值是1GB，该设置并不能严格控制Binlog的大小，尤其是Binlog比较靠近最大值而又遇到一个比较大事务时，为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进当前日志，直到事务结束
- sync_binlog”：这个参数是对于MySQL系统来说是至关重要的，他不仅影响到Binlog对MySQL所带来的性能损耗，而且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下：
sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。
sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。
在MySQL中系统默认的设置是sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为1的时候，即使系统Crash，也最多丢失binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。
从以往经验和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多

relaylog 配置
```
mysql> show variables like '%relay%';
+---------------------------+------------------------------------+
| Variable_name             | Value                              |
+---------------------------+------------------------------------+
| max_relay_log_size        | 0                                  |
| relay_log                 |                                    |
| relay_log_basename        | /var/lib/mysql/00h-relay-bin       |
| relay_log_index           | /var/lib/mysql/00h-relay-bin.index |
| relay_log_info_file       | relay-log.info                     |
| relay_log_info_repository | FILE                               |
| relay_log_purge           | ON                                 |
| relay_log_recovery        | OFF                                |
| relay_log_space_limit     | 0                                  |
| sync_relay_log            | 10000                              |
| sync_relay_log_info       | 10000                              |
+---------------------------+------------------------------------+
11 rows in set (0.01 sec)
```

- max_relay_log_size：标记relay log 允许的最大值，如果该值为0，则默认值为max_binlog_size(1G)；如果不为0，则max_relay_log_size则为最大的relay_log文件大小；
- relay_log：定义relay_log的位置和名称，如果值为空，则默认位置在数据文件的目录，文件名为host_name-relay-bin.nnnnnn（By default, relay log file names have the form host_name-relay-bin.nnnnnn in the data directory）；
- relay_log_index：同relay_log，定义relay_log的位置和名称；
- relay_log_info_file：设置relay-log.info的位置和名称（relay-log.info记录MASTER的binary_log的恢复位置和relay_log的位置）
- relay_log_purge：是否自动清空不再需要中继日志时。默认值为1(启用)。
- relay_log_recovery：当slave从库宕机后，假如relay-log损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的relay-log，并且重新从master上获取日志，这样就保证了relay-log的完整性。默认情况下该功能是关闭的，将relay_log_recovery的值设置为 1时，可在slave从库上开启该功能，建议开启。
- relay_log_space_limit：防止中继日志写满磁盘，这里设置中继日志最大限额。但此设置存在主库崩溃，从库中继日志不全的情况，不到万不得已，不推荐使用；
- sync_relay_log：这个参数和sync_binlog是一样的，当设置为1时，slave的I/O线程每次接收到master发送过来的binlog日志都要写入系统缓冲区，然后刷入relay log中继日志里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量I/O。当设置为0时，并不是马上就刷入中继日志里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘I/O操作。这个值默认是0，可动态修改，建议采用默认值。
- sync_relay_log_info：这个参数和sync_relay_log参数一样，当设置为1时，slave的I/O线程每次接收到master发送过来的binlog日志都要写入系统缓冲区，然后刷入relay-log.info里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量I/O。当设置为0时，并不是马上就刷入relay-log.info里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘I/O操作。这个值默认是0，可动态修改，建议采用默认值。


# mysql 主从同步原理
**主从复制原理**

1.  主服务器：binlog线程记录下所有改变了数据库数据的语句，放进master的binlog中
2.  从服务器：在start slave 以后，I/O线程请求主服务器拉去binlog内容，主服务器binlog dump负责响应，存到中继日志(relay log)中. 
3.  从服务器：sql执行线程，执行relay log中的语句

**主从一致性延时，数据恢复**

-   异步复制：mysql复制是异步的，主机将event写入二进制日志，但不知道从库是否或者何时检索并处理了他们，如果主服务器崩溃，则它提交的事务可能不会传输到任何服务器，主服务器到从服务器的故障转移可能会导致未同步事务丢失
-   半同步复制：主库在应答客户端提交的事务前需要保证至少一个从库接受并写到relay log中，半同步服务器通过`rpl_semi_sync_master_wait_point` 控制master在哪个环节接受slave ack, master接收到ack返回状态给客户端
    -   `WAIT_AFTER_COMMIT`: master write binlog -> slave sync binlog -> **master commit** -> **salve ack** -> master return result。
    -   `WAIT_AFTER_SYNC` （默认）:master write binlog -> slave sync binlog -> **salve ack** -> **master commit** -> master return result

# myaql主从同步延时问题

如果主从同步延时比较严重，解决方案：
- 分库，将一个主库拆分为多个主库，每个主库的写压力就小了几倍，此时延迟问题就会小了
- 并行复制，多个库并行复制如果某个库的写入特别高，并行复制还是没
- 重构代码

**主从一致性检测**



-   [MySQL 8 中复制延时的测量与监控分析]([https://dbalife.info/2018/06/12/MySQL-8-%E4%B8%AD%E5%A4%8D%E5%88%B6%E5%BB%B6%E6%97%B6%E7%9A%84%E6%B5%8B%E9%87%8F%E4%B8%8E%E7%9B%91%E6%8E%A7/](https://dbalife.info/2018/06/12/MySQL-8-中复制延时的测量与监控/))

# mysql故障转移

mysql主从同步配置一台内网服务器和一台外网服务器

mysql主从同步




```shell
mysql> explain select * from media where id = 100\G;
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: media
   partitions: NULL
         type: const
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: const
         rows: 1
     filtered: 100.00
        Extra: NULL
1 row in set, 1 warning (0.00 sec)
```

列的含义：

- id: 每个select都会自动分配一个唯一的标识符
- select_type: select 查询的类型
- table：查询的是哪张表
- partitions：匹配哪个区
- type：join类型
- possible_keys: 此次查询中可能选用的索引
- key：此次查询中确认用到的索引
- ref：哪个字段或常数与key一起被使用
- rows：此查询一共扫描了多少行，估计值
- filtered：此查询条件所过滤数据的百分比
- Extra：额外的信息

# select_type

-   SIMPLE: 此查询不包含子查询或者union查询
-   PRIMARY：此查询是最外层查询
-   UNION: 此查询是UNION的第二或随后的查询
-   DEPENDEND UNION, UNION中的第二个或后面的查询语句，取决于外面的查询
-   UNION RESULT: UNION的结果
-   SUBQUERY: 子查询的中第一个SELECT
-   DEPENDEND SUBQUERY: 子查询中的第一个SELECT，取决于外面的的查询
-   MATERIALIZED：物理化，将查询结果作为临时表以便后续需要时直接使用结果，详情见[Optimizing Subqueries with Materialization](https://dev.mysql.com/doc/refman/8.0/en/subquery-materialization.html)

```sql
explain select m.target_id, (
    select d.content_after from m_log d
    where d.target_id = m.target_id
    and d.target_type = 5
    and d.create_time <= "2019-11-13 07:59:30"
    and d.create_time >= "2019-10-01 00:00:00"
    order by d.id desc limit 0,1
) as 变更后金额
from `m_log` m
where m.target_type = 5
  and m.target_id in (select child from `relation` where parent = 1698747)
and m.create_time <= "2019-11-13 07:59:30"
and m.create_time >= "2019-10-01 00:00:00"
group by m.target_id;
```

| id   | select_type        |    table    | type | possible_keys             | key           | key_len | ref               | rows | Extra                           |
| ---- | ------------------ | :---------: | ---- | ------------------------- | ------------- | ------- | ----------------- | ---- | ------------------------------- |
| 1    | PRIMARY            | <subquery3> | ALL  | NULL                      | NULL          | NULL    | NULL              | NULL | Using temporary; Using filesort |
| 1    | PRIMARY            |      m      | ref  | create_time,idx_target_id | idx_target_id | 4       | <subquery3>.child | 2    | Using where                     |
| 3    | **MATERIALIZED**   |  relation   | ref  | child,idx_par_st          | idx_par_st    | 4       | const             | 14   | Using index                     |
| 2    | DEPENDENT SUBQUERY |      d      | ref  | create_time,idx_target_id | idx_target_id | 4       | func              | 2    | Using where; Using filesort     |

# type

-   system：表只有一行，这是一个`const` type 的特殊情况。
-   consts:  最多只有一行匹配。当你使用主键或者唯一索引的时候，就是`const`类型

```SQL
explain SELECT * from foo where id = 1;
```

| id   | select_type | table | type | possible_keys | key     | key_len | ref  | rows  |               Extra               |
| ---- | ----------- | ----- | ---- | ------------- | ------- | ------- | ---- | ----- | :-------------------------------: |
| 1    | SIMPLE      | foo   |      | const         | PRIMARY | PRIMARY | 4    | const | Directly search via Primary Index |

-   eq_ref: 通常出现在join中，表示前一列的结果都只能匹配到后一行的结果，并且查询的匹配的操作通常是 `=`,查询效率较高

```sql
explain select * from u, `u_ocpc` where u.id = u_ocpc.u_id and u.id in (2657099,2657010,2656981)
```

| id   | select_type | table  | type   | possible_keys | key     | key_len | ref                   | rows |    Extra    |
| ---- | ----------- | ------ | ------ | ------------- | ------- | ------- | --------------------- | ---- | :---------: |
| 1    | SIMPLE      | u_ocpc | range  | PRIMARY       | PRIMARY | 4       | NULL                  | 3    | Using where |
| 1    | SIMPLE      | u      | eq_ref | PRIMARY       | PRIMARY | 4       | adv.unit_ocpc.unit_id | 1    |    NULL     |

-   ref: 多表join，触发联合索引最左原则，或者这个索引不是唯一索引/主键索引

```sql
explain select * from `config` C left JOIN `dark` D on D.medias = C.value where C.group_id = 1;
```

| id   | select_type | table | type    | possible_keys       |         key         | key_len | ref   | rows | Extra                                              |
| ---- | ----------- | ----- | ------- | ------------------- | :-----------------: | ------- | ----- | ---- | -------------------------------------------------- |
| 1    | SIMPLE      | C     | **ref** | config_group_id_key | config_group_id_key | 4       | const | 12   | NULL                                               |
| 1    | SIMPLE      | D     | ALL     | NULL                |        NULL         | NULL    | NULL  | 4    | Using where; Using join buffer (Block Nested Loop) |

-   unique_subquery：使用了in的子查询，而且子查询是主键或者唯一索引

- range: 索引范围查询， 这个类型通常出现在 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, IN() 

```sql
explain select * from media where id between 2 and 10;
```

| id   | select_type | table | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
| ---- | :---------: | ----- | ----- | ------------- | ------- | ------- | ---- | ---- | ----------- |
| 1    |   SIMPLE    | idea  | range | PRIMARY       | PRIMARY | 4       | NULL | 2    | Using where |

- ALL 全表扫描,性能最差的查询之一，因为这样的查询在数据量大的情况下, 对数据库的性能是巨大的灾难. 

```sql
explain select * from creative WHERE target_url = 'http://cdn.yuming.com//allsites/1647060/3ea6c76347dd4c7167b9c1c83f069003/index_1738893.html?r=9223'
```

| id   | select_type | table | type | possible_keys | key  | key_len | ref  | rows    |    Extra    |
| ---- | ----------- | ----- | ---- | ------------- | ---- | ------- | ---- | ------- | :---------: |
| 1    | SIMPLE      | idea  | ALL  | NULL          | NULL | NULL    | NULL | 3222483 | Using where |

# possible_key

表示在mysql查询时，能够是用到的索引，即使这些索引在possible_key中出现，但是并不是此索引会真正被MYSQL使用到，具体用到使用了哪些索引，由KEY决定



# key

 MySQL 在当前查询时所真正使用到的索引.



# key_len

索引的字节数，这个字段可以评估组合索引是否完全被使用, 或只有最左部分字段被使用到.



# rows

rows 也是一个重要的字段. MySQL 查询优化器根据统计信息, 估算 SQL 要查找到结果集需要扫描读取的数据行数

sql最重要的评价字段



# Extra

- using filesort: mysql需要额外的排序操作，不能通过索引达到排序的效果，一半有using filesort都建议优化掉
- using index: 覆盖索引扫描，说明所需数据在索引中即可取到，性能不错
- using temporary：使用了临时表，一般出现于排序, 分组和多表 join 的情况, 查询效率不高, 建议优化.

详细了解explain参数含义，后续还有trace的用法

explain详解


[TOC]

# gRPC权限认证

系统设计要满足最低安全标准，尽管平时我们设计的系统不是专门为了高安全性应用而设计的，但必须要用最低标准的加密和身份验证。例如：web服务要加密密码和身份证信息。同样分布式系统也要能加密二进制数据和节点通信数据，进行身份和权限认证。虽然这些事有开销的，但是这些开销相比安全风险来说是值得的。

gRPC本身支持几种授权验证机制：

- SSL/TLS: 
  - SSL/TLS 两端授权认证
  - 加密通信
- Token Authentication

## 创建证书

通过证书加密数据，使用openssl生成

server.key: 私钥

server.crt: 公钥

```shell
$ openssl genrsa -out server.key 2048
$ openssl req -new -x509 -days 3650 \
    -subj "/CN=douyacun.com" \
    -key server.key -out server.crt
```

`-subj` 内的值等价于：

```shell
$ openssl req -new -x509 -sha256 -key server.key -out server.crt -days 3650
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:CH
State or Province Name (full name) []:shandong
Locality Name (eg, city) []:laiwu
Organization Name (eg, company) []:douyacun
Organizational Unit Name (eg, section) []:douyacun
Common Name (eg, fully qualified host name) []:douyacun.com
Email Address []:douyacun@gmail.com
```

## 服务端加密

[【源码阅读】](https://github.com/douyacun/foo_go/tree/master/cmd/rpc/tls-auth)

使用gRPC加密通信最简单方式就是服务端加密，服务端需要初始化密钥对(server.key/server.crt)，客户端只需要公钥

```go
// 初始化tcp通道
lis, err := net.Listen("tcp", Port)
if err != nil {
  log.Fatal(err)
}
// 初始化TLS证书
creds, err := credentials.NewServerTLSFromFile("../cert/server.crt", "../cert/server.key")
if err != nil {
  log.Fatal(err)
}
// 创建 gRPC 服务，并配置证书
s := grpc.NewServer(grpc.Creds(creds))
// 注册函数
greeter.RegisterGreeterServer(s, new(server))
// 启动服务
if err := s.Serve(lis); err != nil {
  log.Fatalf("failed to serve: %v", err)
}
```

客户端为了能创建连接，需要获取server.crt(公钥)。

```go
// 初始化TLS证书
creds, err := credentials.NewClientTLSFromFile("../cert/server.crt", "server.douyacun.com")
if err != nil {
  log.Fatal(err)
}
// 拨号通信
conn, err := grpc.Dial("localhost:4000", grpc.WithTransportCredentials(creds))
if err != nil {
  log.Fatal(err)
}
defer conn.Close()
// 初始化客户端接口
client := greeter.NewGreeterClient(conn)
reply, err := client.SayHello(context.Background(), &greeter.HelloRequest{Name: "world"})
if err != nil {
  log.Fatal(err)
}

fmt.Println(reply.GetMessage())
```

## 双向证书验证

[【源码阅读】](https://github.com/douyacun/foo_go/tree/master/cmd/rpc/mutual-tls-auth)

上面的方式需要提前将证书给到客户端，每次变更都需要维护证书，为了避免这种麻烦。可以通过一个安全可靠的根证书分别对服务器和客户端的证书进行签名，这样客户端或服务端在收到对方证书后可以通过根证书验证证书的有效性

生成客户端证书

```shell
$ openssl genrsa -out client.key 2048
$ openssl req -new -x509 -days 3650 \
    -subj "/CN=douyacun.com" \
    -key client.key -out client.crt
```

生成根证书ca

```shell
$ openssl genrsa -out ca.key 2048
$ openssl req -new -x509 -days 3650 \
    -subj "/CN=douyacun.com" \
    -key ca.key -out ca.crt
```

对服务端证书签名

```shell
$ openssl req -new \
    -subj "/CN=douyacun.com" \
    -key server.key \
    -out server.csr
$ openssl x509 -req -sha256 \
    -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650 \
    -in server.csr \
    -out server.crt
```

对客户端证书签名

```shell
$ openssl req -new \
    -subj "/CN=douyacun.com" \
    -key client.key \
    -out client.csr
$ openssl x509 -req -sha256 \
    -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650 \
    -in client.csr \
    -out client.crt
```

服务端

```go
// 从磁盘加载证书
cert, err := tls.LoadX509KeyPair("../cert/server.crt", "../cert/server.key")
if err != nil {
  log.Fatalf("tls load key pair failed, %v",err)
}
certPool := x509.NewCertPool()
ca, err := ioutil.ReadFile("../cert/ca.crt")
if err != nil {
  log.Fatalf("ca.crt read filed %v", err)
}
if ok := certPool.AppendCertsFromPEM(ca); !ok {
  log.Fatal("failed to append client certs")
}
// 初始化tcp通道
lis, err := net.Listen("tcp", Port)
if err != nil {
  log.Fatal(err)
}
// 初始化TLS证书
creds := credentials.NewTLS(&tls.Config{
  ClientAuth:   tls.RequireAndVerifyClientCert,
  Certificates: []tls.Certificate{cert},
  ClientCAs:    certPool,
})
// 创建 gRPC 服务，并配置证书
s := grpc.NewServer(grpc.Creds(creds))
// 注册函数
greeter.RegisterGreeterServer(s, new(server))
// 启动服务
if err := s.Serve(lis); err != nil {
  log.Fatalf("failed to serve: %v", err)
}
```

客户端

```go
// 从磁盘加载证书
certificate, err := tls.LoadX509KeyPair("../cert/client.crt", "../cert/client.key")
if err != nil {
  log.Fatalf("tls load key pair failed, %v", err)
}
certPool := x509.NewCertPool()
ca, err := ioutil.ReadFile("../cert/ca.crt")
if err != nil {
  log.Fatalf("ca read failed, %v", err)
}
if ok := certPool.AppendCertsFromPEM(ca); !ok {
  log.Fatal("cert append pool failed")
}
// 初始化TLS证书
creds := credentials.NewTLS(&tls.Config{
  ServerName:   "douyacun.com", // 对服务端证书签名的配置(/CN = ?)
  Certificates: []tls.Certificate{certificate},
  RootCAs:      certPool,
})
// 拨号通信
conn, err := grpc.Dial("localhost:4000", grpc.WithTransportCredentials(creds))
if err != nil {
  log.Fatal(err)
}
defer conn.Close()
client := greeter.NewGreeterClient(conn)

reply, err := client.SayHello(context.Background(), &greeter.HelloRequest{Name: "world"})
if err != nil {
  log.Fatal(err)
}

fmt.Println(reply.GetMessage())
```

# token认证

[【源码阅读】](https://github.com/douyacun/foo_go/tree/master/cmd/rpc/token)

token认证主要是需要实现credentials.PerRPCCredentials接口

```go
// PerRPCCredentials defines the common interface for the credentials which need to
// attach security information to every RPC (e.g., oauth2).
type PerRPCCredentials interface {
	// GetRequestMetadata gets the current request metadata, refreshing
	// tokens if required. This should be called by the transport layer on
	// each request, and the data should be populated in headers or other
	// context. If a status code is returned, it will be used as the status
	// for the RPC. uri is the URI of the entry point for the request.
	// When supported by the underlying implementation, ctx can be used for
	// timeout and cancellation.
	// TODO(zhaoq): Define the set of the qualified keys instead of leaving
	// it as an arbitrary string.
	GetRequestMetadata(ctx context.Context, uri ...string) (map[string]string, error)
	// RequireTransportSecurity indicates whether the credentials requires
	// transport security.
	RequireTransportSecurity() bool
}
```

实现PerRPCCredentials interface

```go
type Auth struct {
	Account     string
	Password string
}
func (a *Auth) GetRequestMetadata(ctx context.Context, uri ...string) (map[string]string, error) {
	return map[string]string{"account": a.Account, "password": a.Password}, nil
}
func (a *Auth) RequireTransportSecurity() bool  {
	return false
}
```

服务端使用中间件验证,这里集成[go-grpc-middleware](https://github.com/grpc-ecosystem/go-grpc-middleware)

```go
func main() {
	s := grpc.NewServer(grpc.UnaryInterceptor(grpc_middleware.ChainUnaryServer(
		grpc_auth.UnaryServerInterceptor(check),
		grpc_recovery.UnaryServerInterceptor(),
	)))
	greeter.RegisterGreeterServer(s, &server{})
	lis, err := net.Listen("tcp", Port)
	if err != nil {
		log.Fatal(err)
	}
	if err := s.Serve(lis); err != nil {
		log.Fatalf("failed to server: %v", err)
	}
}
func check(ctx context.Context) (context.Context, error){
  // FromIncomingContext 可以获取到 GetRequestMetadata 返回到数据
	md, ok := metadata.FromIncomingContext(ctx)
	if !ok {
		return nil, fmt.Errorf("missing credentials")
	}
	var (
		account, password string
	)
	if val, ok := md["account"]; ok {
		account = val[0]
	}
	if val, ok := md["password"]; !ok {
		password = val[0]
	}
	fmt.Println(account, password)
	return nil, nil
}
```

# gRPC扩展

## 默认值

需要引入扩展选项`import "google/protobuf/descriptor.proto";` 实现默认值

```protobuf
// 这里声明协议版本，默认是proto2, 3和2并不向下兼容
syntax = "proto3";

import "google/protobuf/descriptor.proto";

// 这里指定 go 包名
package greeter;

// 定义默认类型
extend google.protobuf.FieldOptions {
    string default_name = 5000;
}

// 定义要序列化的信息的结构
message HelloRequest {
    // string 字段类型， 也可以自定义字段类型
    string name = 1 [(default_name) = "world"]; // 注意这里1是唯一的， 1-15 占用1个字节， 16 - 2047 占用2个字节
}

// 同一个proto文件中可以定义多个message type
message HelloReply {
    string message = 1;
}

// 定义接口
service Greeter {
    rpc SayHello (HelloRequest) returns (HelloReply);
}
```

##grpc-gateway

安装， 这里最好将GO111MODULE设为auto, `GO111MODULE=auto`,否则下面的安装会安装到`$GOPATH/pkg/mod`下面，不是安装到`$GOPATH/src`下

```go
go get -u github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway
go get -u github.com/grpc-ecosystem/grpc-gateway/protoc-gen-swagger
go get -u github.com/golang/protobuf/protoc-gen-go
```

创建protobuf文件，生成gRPC使用的pb文件，grpc-gateway使用的gw文件

```shell
$ protoc -I/usr/local/include -I. \
  -I$GOPATH/src \
  -I$GOPATH/src/github.com/grpc-ecosystem/grpc-gateway/third_party/googleapis \
  --grpc-gateway_out=. \
  --go_out=plugins=grpc:. \
  hello.proto
```

```protobuf
// 这里声明协议版本，默认是proto2, 3和2并不向下兼容
syntax = "proto3";

// 我的goland这里会提示 file not found
import "google/api/annotations.proto";

// 这里指定 go 包名
package greeter;

// 定义要序列化的信息的结构
message HelloRequest {
    // string 字段类型， 也可以自定义字段类型
    string name = 1; // 注意这里1是唯一的， 1-15 占用1个字节， 16 - 2047 占用2个字节
}

// 同一个proto文件中可以定义多个message type
message HelloReply {
    string message = 1;
}

// 定义接口
service Greeter {
    //    rpc SayHello (HelloRequest) returns (HelloReply);
    rpc Echo (HelloRequest) returns (HelloReply) {
        option (google.api.http) = {
            get : "/echo/{name}"
        };
    }
}
```

创建httpserver文件

```go
ctx := context.Background()
ctx, cancel := context.WithCancel(ctx)
defer cancel()

// Register gRPC server endpoint
// Note: Make sure the gRPC server is running properly and accessible
mux := runtime.NewServeMux()
err := greeter.RegisterGreeterHandlerFromEndpoint(ctx, mux,  "localhost:4000", []grpc.DialOption{grpc.WithInsecure()})
if err != nil {
  log.Fatal(err)
}

// Start HTTP server (and proxy calls to gRPC server endpoint)
err = http.ListenAndServe(":8081", mux)
if err != nil {
  log.Fatal(err)
}
```

创建rpcserver文件，这里还是和上面的rpc server启动方式一样

```go
s := grpc.NewServer()
greeter.RegisterGreeterServer(s, new(server))
lis, err := net.Listen("tcp", Port)
if err != nil {
  log.Fatal(err)
}
if err := s.Serve(lis); err != nil {
  log.Fatalf("failed to serve: %v", err)
}
```

先启动rpcserver，然后启动httpserver，通过curl请求

```shell
$ curl -X GET "http://localhost:8081/echo/douyacun"
{"message":"hello "}%
```

# 推荐阅读

- [https://bbengfort.github.io/programmer/2017/03/03/secure-grpc.html](https://bbengfort.github.io/programmer/2017/03/03/secure-grpc.html)

扫码关注获得更多关于深入理解redis、go、mysql源码的文章

gRPC是基于http2.0，这里实现证书认证、rpc和RESTful HTTP API共存

gRPC进阶


# 系统

- uname -a               - 查看内核/操作系统/CPU信息
- head -n 1 /etc/issue   - 查看操作系统版本
- cat /proc/cpuinfo      - 查看CPU信息
- hostname               - 查看计算机名
- lspci -tv              - 列出所有PCI设备
- lsusb -tv              - 列出所有USB设备
- lsmod                  - 列出加载的内核模块
- env                    - 查看环境变量

# 资源

- free -m                - 查看内存使用量和交换区使用量
- df -h                  - 查看各分区使用情况
- du -sh <目录名>        - 查看指定目录的大小
- grep MemTotal /proc/meminfo   - 查看内存总量
- grep MemFree /proc/meminfo    - 查看空闲内存量
- uptime                 - 查看系统运行时间、用户数、负载
- cat /proc/loadavg      - 查看系统负载

# 磁盘和分区

- mount | column -t      - 查看挂接的分区状态
- fdisk -l               - 查看所有分区
- swapon -s              - 查看所有交换分区
- hdparm -i /dev/hda     - 查看磁盘参数(仅适用于IDE设备)
- dmesg | grep IDE       - 查看启动时IDE设备检测状况

# 网络

- ifconfig               - 查看所有网络接口的属性
- iptables -L            - 查看防火墙设置
- route -n               - 查看路由表
- netstat -lntp          - 查看所有监听端口
- netstat -antp          - 查看所有已经建立的连接
- netstat -s             - 查看网络统计信息

# 进程

- ps -ef                 - 查看所有进程
- top                    - 实时显示进程状态

# 用户

- w                      - 查看活动用户
- id <用户名>            - 查看指定用户信息
- last                   - 查看用户登录日志
- cut -d: -f1 /etc/passwd   - 查看系统所有用户
- cut -d: -f1 /etc/group    - 查看系统所有组
- crontab -l             - 查看当前用户的计划任务

# 服务

- chkconfig --list       - 列出所有系统服务
- chkconfig --list | grep on    - 列出所有启动的系统服务

# 程序

- rpm -qa                - 查看所有安装的软件包

linux常用命令_磁盘_进程_网络_内存_负载

# 电脑重装成centos系统

## 下载iso镜像

[镜像下载](http://centos.01link.hk/)

```
[DIR] Parent Directory                                             -   
[TXT] 0_README.txt                            10-May-2018 04:16  2.4K  
[   ] CentOS-7-x86_64-DVD-1804.iso            04-May-2018 05:07  4.2G  
[   ] CentOS-7-x86_64-DVD-1804.torrent        11-May-2018 23:43   84K  
[   ] CentOS-7-x86_64-Everything-1804.iso     07-May-2018 20:55  8.8G  
[   ] CentOS-7-x86_64-Everything-1804.torrent 11-May-2018 23:43  176K  
[   ] CentOS-7-x86_64-LiveGNOME-1804.iso      03-May-2018 02:21  1.3G  
[   ] CentOS-7-x86_64-LiveGNOME-1804.torrent  11-May-2018 23:43   52K  
[   ] CentOS-7-x86_64-LiveKDE-1804.iso        03-May-2018 02:28  1.8G  
[   ] CentOS-7-x86_64-LiveKDE-1804.torrent    11-May-2018 23:43   71K  
[   ] CentOS-7-x86_64-Minimal-1804.iso        04-May-2018 05:07  906M  
[   ] CentOS-7-x86_64-Minimal-1804.torrent    11-May-2018 23:43   36K  
[   ] CentOS-7-x86_64-NetInstall-1804.iso     04-May-2018 04:34  495M  
[   ] CentOS-7-x86_64-NetInstall-1804.torrent 11-May-2018 23:43   20K     >>>>>>>>>
[TXT] sha1sum.txt                             10-May-2018 04:02  454   
[TXT] sha1sum.txt.asc                         11-May-2018 23:12  1.3K  
[TXT] sha256sum.txt                           10-May-2018 03:59  598   
[TXT] sha256sum.txt.asc                       11-May-2018 23:12  1.4K  
```
> 选择的是 上面标记的 网络安装版本 >>>>>>>>> ,一些基础软件没有, 需要联网下载

## 制作centos系统盘 (mac os)

----

1. 把ISO转成DMG，命令中的-o后面的linux是目标文件名，按自己需求改

    ```
    # hdiutil convert -format UDRW -o 输出 输入文件.iso
    # hdiutil convert /Users/os/Downloads/ylmf.iso -format UDRW -o ylmf.img    // windows
    ```


2. .把U盘插上，查看盘符

    ```
    # diskutil list
    ```

3. 卸载U盘，把命令里的disk2改成你自己的盘符，还要注意卸载不是弹出！

    ```
    # diskutil unmountDisk /dev/disk2
    ```

4. 开始把光盘写入到u盘

    ```
    # sudo dd if=linux.dmg of=/dev/disk2 bs=1m

    之后终端里就不动了，看着没反应了，其实正在后台运行呢，等着就行，写入完成以后终端有提示，然后再弹出U盘就可以正常使用了。

    408+0 records in
    408+0 records out
    427819008 bytes transferred in 3.608223 secs (118567786 bytes/sec)
    ```

## 装机 安装选择

- f12 进入bios
```
Boot Mode  : Legacy Support
Boot Priority : Legacy First
```
- 重启 f12 选 use 启动

- 设置启动盘, 配置目录google或baidu搜吧!

- 上面的关键点来了, 因为选择的netinstall, 需要设置安装源, 下面的源可能会失效 (https://opsx.alibaba.com/mirror) 自己选吧

- https://mirrors.aliyun.com/centos/7.5.1804/os/x86_64/

- 选择最小化安装就行


# 扩展
- linux 挂载FAT32系统
    ```
    # mount -t vfat /dev/sdb1 /package
    ```

制作centos7系统盘

# gdb 调试工具

调试redis设置:
```c
// 相当于 gcc -g
make CFLAGS="-g -O0"

gdb src/redis-server
```

> gdb 支持tab补全

# 运行程序
- `run` 可指定运行参数
  - `set args` 指定运行是参数
- 运行环境
  - `path` 设定程序的运行路径
  - `set environment varname[=value]` 设置环境变量 ：`set env USER=hchen`

# 设置断点: breakpointer

- 函数断点: `break <function>`
- 行号断点：`break <linenum>`
- 在程序运行内存地址处停止：`break *address`

# 查看断点: info
`info break[n]`

# 设置捕捉点：catchpoint

`cactch event`, event如下:
1. throw 一个 C++抛出的异常(throw 为关键字) ，
2. catch 一个 C++捕捉到的异常(catch 为关键字) ，
3. exec 调用系统调用 exec 时(exec 为关键字， 目前此功能只在HP-UX 下有用) 
4. fork 调用系统调用 fork 时。 (fork 为关键字， 目前此功能只在HP-UX 下有用)
5. vfork 调用系统调用vfork时。(vfork为关键字，目前此功能只在HP-UX下有用)
6. load 或 load <libname> 载入共享库(动态链接库)时。 (load 为关键字，目前此功能只在 HP-UX 下有用)
7. unload 或 unload<libname> 卸载共享库(动态链接库)时。 (unload为关键字，目前此功能只在 HP-UX 下有用)

只设置一次断点，程序停住后，断点自动删除

# 维护断点

- `clear` 清除所有的断点
- `clear <function>` 清除函数断点
- `clear <linenum>` 清除指定行上的断点
- `delete [<breakpointe>][range]` 清除指定断点，范围断点

# 恢复程序运行
- `continue`
- `c`
- `fg`
以上3个是同一个意思

# 单步跟踪
- `step<count>`: 如果有函数会进入函数，count：每次运行几条指令,不加每次运行一条
- `next<count>`: 如果有函数不会进入函数，count：每次运行几条指令,不加每次运行一条
- `finish`: 运行程序，知道函数完成，并打印函数返回时的堆栈地址和返回值及参数值信息
- `until`|`u`:推出循环体

打开单步跟踪模式: `set step-mode [on][off]` 在进行单步跟踪时，程序不会因为没有debug而停住

# 信号
unix定义了很多信号，比如SIGINT表示中断字符信号，可以要求GDB收到你锁指定的信号时，马上挺住正在运行的程序，以供进行调试

`handle <single> <keywords...>`

- single: 信号，all表明要处理的所有信号
- keywords:
  - nostop: 不会停住程序的运行
  - stop: 停住
  - print: 回显示出一条信息
  - noprint: 不会显示信息
  - pass/noignore: GDB不处理信号，交给调试程序处理
  - nopass/ignore: GDB不会让调试程序处理这个信号
  - info singles/info handle: 哪些信号被GDB检测中

# 线程
可以定义断点是否在所有线程上还是某个特定的线程
```gdb
break <linespec> thread <threadno>
break <linespec> thread <threadno> if...

break frik.c:13 thread 28 if bartab>lim
```
- linespec 行号
- threadno 线程id，`info threads`可以查看正在运行中的线程

不指定`threadno`表示断点设在所有的线程上面

# 查看栈信息
当程序被停住了，需要做的第一件事就是查看程序是在哪里停住了，当程序调用了一个函数：函数的地址、参数、局部变量都会被压入“栈中”
- `backtrace<n>`
- `bt<n>`
> n 只打栈顶上n层的信息
> -n 栈底n层的栈信息
打印当前函数调用栈的所有信息

切换当前栈
- `f<n>` | `frame<n>` 打印某一层的栈: 栈的层编号、当前函数名、函数参数值，函数所在的文件及行号
- `up<n>` 向上移动n层
- `down<n>` 移动n层

# 打印函数栈信息

- `info f` 打印更详细的栈层信息，大多是运行内存地址：函数地址、调用函数地址、被调用函数的地址、程序语言、函数参数地址及值、局部变量的地址
- `info args` 打印当前函数的参数名、值
- `info locals` 当前函数中所有局部变量、值
- `info catch` 当前函数中异常处理信息


# 显示源代码
`set listsize <count>` 一次显示源代码的行数

- `list<linenum>` 显示程序第`linenum`行周围的源程序
- `list<function>` 显示函数名为function的函数的源程序
- `list` 当前行后面的源程序
- `list -` 当前行前面的源程序
- `list <first>,<last>` 从first到last行之间的源代码
- `list <last>` 从当前行到last行之间的源代码
- `list +`往后显示源代码

list 后面可以跟的参数:
- `<linenum>`行号。 
- `<+offset>`当前行号的正偏移量。 
- `<-offset>`当前行号的负偏移量。 
- `<filename:linenum>`那个文件的那一行。 
- `<funtion>`函数名 
- `<filename:funtion>`那个文件中的那个函数。 
- `<*address>`程序运行时的语句在内存中的地址。

# 搜索源代码
- 向前搜索
  - `forward-search <regexp>`
  - `search <regexp>` 
- 全部搜索
  - `reverse-search<regexp>`

# 指定源文件的路径
- `directory<dirname...>`加一个源文件路径到当前路径的前面，指定多个路径“:”
- `directory`清除所有的自定义的源文件搜索路径信息
- `show directories`显示定义了的源文件搜索路径

# 打印数据
`print/<f><expr>`

- `@` 一个数组有关的操作符，在后面会有更详细的说明
- `::`指定一个文件中或是一个函数中的变量
- `{<type>}<addr>` 表示一个指向内存地址`<addr>`的类型为type的一个对象

gdb中可以随时查看一下三种变量的值：
- 全局变量（所有文件可见）
- 静态全局变量（当前文件可见）
- 局部变量（当前scope可见的）

数组：
```c
int *array = (int*)malloc(len*sizeof(int))

// 动态数组
(gdb) p *array@len
$1 = {2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40}

// 静态数组就可以查看
print array
```

# 输出格式
- x 按十六进制格式显示变量。
- d 按十进制格式显示变量。
- u 按十六进制格式显示无符号整型。 o 按八进制格式显示变量。
- t 按二进制格式显示变量。
- a 按十六进制格式显示变量。
- c 按字符格式显示变量。
- f 按浮点数格式显示变量。

# 查看内存
`examine`(简写 x), 查看内存地址中的值

`x<n/f/u><addr>`

n、f、u 是可选参数。
- n 是一个正整数，表示显示内存的长度，也就是说从当前地址向后显示几个地址的内容。 
- f 表示显示格式，参加上面。如果地址所指的是字符串，那么格式是 s，如果地址是指令
地址，那么格式也可以是 i。
- u 表示从当前的地址往后请求的字节数，如果不指定的话，GDB 默认是 4 个 bytes。u 参数可以用下面的字符来代替：
  - b 表示单字节
  - h 表示双字节
  - w 表示四字节
  - g 表示八字节

`x/3uh 0x54320` 表示，从内存地址`0x54320`读取内容

# 自动显示
可以设置一些自动显示的变量，当程序停住时，或是在单步跟踪时，这些变量回自动显示：
- `display<expr>`
- `display<fmt><expr>`
- `display/<fmt><expr>`

> expr: 表达式
> fmt: 显示的格式
> addr: 内存地址

删除自动显示，dnums设置好了的自动显示的编号，同时删除多个，用空格分隔，范围删除，用`-`分隔
- `undisplay<dnums...>`
- `delete display<dnums...>`

`info display` 查看display自动显示的信息

# 设置选项
- `set print address <on/off>` 打开地址输出,系统默认打开，等同于`frame/f`显示地址信息
- `set print array <on/off>` 打开数组显示，每个元素栈占一行，不打开每个以逗号分隔
- `set print elements <on/off>` print elemets的选项信息
- `set print null-stop<on/off>` 显示字符串时，遇到`\0`就停止显示
- `set print pretty <on/off>` gdb显示结构体就比较漂亮
- `set print union <on/off>` 显示结构体时，是否显示其内的联合体数据
- `set listsize <n>` 一次显示源代码的行数
- `set step-mode [on][off]` 在进行单步跟踪时，程序不会因为没有debug而停住
- `set print array-indexes on` 打印数组索引下标


# 修改变量值
`print x=4`

# 跳转执行
`jump<linespect>`执行下一条语句运行点，`file:line`

# 查生信号量
`single 命令`

# 强制函数返回
`return`

# 强制调用函数
`call`

- https://www.kancloud.cn/wizardforcel/gdb-tips-100/146752

# gdb 启动脚本
gdb启动时，会读取HOME目录和当前目录下的的配置文件，执行里面的命令。这个文件通常为“.gdbinit”。

```
# 保存历史命令
set history filename ~/.gdb_history
set history save on

# 退出时不显示提示信息
set confirm off

# 按照派生类型打印对象
set print object on

# 打印数组的索引下标
set print array-indexes on

# 每行打印一个结构体成员
set print pretty on

set step-mode on
```


gdb文档

使用的[frp](https://github.com/fatedier/frp),详情可以去github看，那里有中文文档，可以使用[supervisor管理frp连接进程](/linux/supervisor_安装_进程管理_配置_frp|spiderkeeper|jobs配置.md),以下介绍的是我的使用场景和一些个人理解

需要两台服务器
- 内网服务器(家里或者公司没有公网ip的服务器)
- 有公网ip的服务器，阿里云服务器/腾讯云服务器

# 安装

从[frp github realeas](https://github.com/fatedier/frp/releases)下载最新版，解压安装最新版本, 具体下载哪个文件没搞清，centos7.4,用的是下面的
- centos: frp_*_linux_amd64.tar.gz

# 配置

内网部署 `frpc.ini`
```conf
[common]
# 公网
server_addr = *.*.*.* # 这里是公网ip
server_port = 7000

[mysql]
local_port = 3306
local_ip = 127.0.0.1
local_port = 3306
# 公网服务器： mysql -u root -H 127.0.0.1 -P 3307 -p123456
# 公网服务器的 3307 端口，代理到内网的3306端口
remote_port = 3307

[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22
# 如果需要在任何地方可以连接需要暴露公网的6000端口
# 公网服务器的 6000 端口，代理到内网的22端口
# ssh -p 6000 root@【公网ip地址】
remote_port = 6000

[http]
type = tcp
local_ip = 127.0.0.1
local_port = 80
# 需要暴露公网的80端口
# 公网服务器的 80 端口，代理到内网的80端口
remote_port = 80
```

公网部署 `frps.ini`
```conf
[common]
bind_port = 7000
```


# 启动连接

内网
```
./frpc -c frpc.ini
```
```log
2019/01/30 21:53:07 [I] [service.go:124] frps tcp listen on 0.0.0.0:7000
2019/01/30 21:53:07 [I] [root.go:204] Start frps success
2019/01/30 21:53:36 [I] [service.go:317] client login info: ip [139.227.1.5:39536] version [0.23.2] hostname [] os [linux] arch [amd64]
2019/01/30 21:53:36 [I] [tcp.go:66] [604c65b49901ac56] [ssh] tcp proxy listen port [6000]
2019/01/30 21:53:36 [I] [control.go:397] [604c65b49901ac56] new proxy [ssh] success
2019/01/30 21:56:50 [I] [proxy.go:80] [604c65b49901ac56] [ssh] get a new work connection: [139.227.1.5:39536]
```

公网
```
./frps -c frps.ini
```

```log
2019/01/30 21:53:36 [I] [service.go:206] login to server success, get run id [604c65b49901ac56], server udp port [0]
2019/01/30 21:53:36 [I] [proxy_manager.go:137] [604c65b49901ac56] proxy added: [ssh]
2019/01/30 21:53:36 [I] [control.go:143] [ssh] start proxy success
2019/02/01 00:45:53 [I] [service.go:206] login to server success, get run id [c387c847febafa3c], server udp port [0]
2019/02/01 00:45:53 [I] [proxy_manager.go:137] [c387c847febafa3c] proxy added: [mysql ssh]
2019/02/01 00:45:53 [I] [control.go:143] [mysql] start proxy success
2019/02/01 00:45:53 [I] [control.go:143] [ssh] start proxy success
```

[supervisor frp管理配置](/linux/supervisor_安装_进程管理_配置_frp|spiderkeeper|jobs配置.md#frp配置)

通过frp加公网服务器提供mysql，ssh，http服务

frp内网穿透


# 安装
```
yum install sysstat
```

# 实例1：显示所有设备负载情况
```
iostat

Linux 2.6.32-754.2.1.el6.x86_64 (iZ2zej76z8h545jaqmtldsZ) 	2019年01月20日 	_x86_64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          16.00    0.00    4.59    0.03    0.00   79.37

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
vda              13.70         0.66       241.78    5414754 1984862152
vdb               0.00         0.00         0.00       1440          0
```

cpu属性值说明：
- %user：CPU处在用户模式下的时间百分比。
- %nice：CPU处在带NICE值的用户模式下的时间百分比。
- %system：CPU处在系统模式下的时间百分比。
- %iowait：CPU等待输入输出完成时间的百分比。
- %steal：管理程序维护另一个虚拟处理器时，虚拟CPU的无意识等待时间百分比。
- %idle：CPU空闲时间百分比。
> 注：如果%iowait的值过高，表示硬盘存在I/O瓶颈，%idle值高，表示CPU较空闲，如果%idle值高但系统响应慢时，有可能是CPU等待分配内存，此时应加大内存容量。%idle值如果持续低于10，那么系统的CPU处理能力相对较低，表明系统中最需要解决的资源是CPU。

disk属性值说明：
rrqm/s: 每秒进行 merge 的读操作数目。即 rmerge/s
wrqm/s: 每秒进行 merge 的写操作数目。即 wmerge/s
r/s: 每秒完成的读 I/O 设备次数。即 rio/s
w/s: 每秒完成的写 I/O 设备次数。即 wio/s
rsec/s: 每秒读扇区数。即 rsect/s
wsec/s: 每秒写扇区数。即 wsect/s
rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。
wkB/s: 每秒写K字节数。是 wsect/s 的一半。
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。
avgqu-sz: 平均I/O队列长度。
await: 平均每次设备I/O操作的等待时间 (毫秒)。
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。
%util: 一秒中有百分之多少的时间用于 I/O 操作，即被io消耗的cpu百分比
备注：如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明I/O 队列太长，io响应太慢，则需要进行必要优化。如果avgqu-sz比较大，也表示有当量io在等待。

# 实例2：定时显示所有信息
```
iostat 2 3
Linux 2.6.32-279.el6.x86_64 (colin)   07/16/2014      _x86_64_        (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
10.81    0.00   14.11    0.18    0.00   74.90

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               1.95         1.48        70.88    9145160  437106156
dm-0              3.08         0.55        24.34    3392770  150088376
dm-1              5.83         0.93        46.49    5714522  286728384
dm-2              0.01         0.00         0.05      23930     289288

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
22.62    0.00   19.67    0.26    0.00   57.46

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               2.50         0.00        28.00          0         56
dm-0              0.00         0.00         0.00          0          0
dm-1              3.50         0.00        28.00          0         56
dm-2              0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
22.69    0.00   19.62    0.00    0.00   57.69

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               0.00         0.00         0.00          0          0
dm-0              0.00         0.00         0.00          0          0
dm-1              0.00         0.00         0.00          0          0
dm-2              0.00         0.00         0.00          0          0
说明：每隔 2秒刷新显示，且显示3次
```

# 实例3：查看TPS和吞吐量
```
iostat -d -k 1 1
Linux 2.6.32-279.el6.x86_64 (colin)   07/16/2014      _x86_64_        (4 CPU)

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               1.95         0.74        35.44    4572712  218559410
dm-0              3.08         0.28        12.17    1696513   75045968
dm-1              5.83         0.46        23.25    2857265  143368744
dm-2              0.01         0.00         0.02      11965     144644
```
- tps：该设备每秒的传输次数（Indicate the number of transfers per second that were issued to the device.）。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。“一次传输”请求的大小是未知的。
- kB_read/s：每秒从设备（drive expressed）读取的数据量；
- kB_wrtn/s：每秒向设备（drive expressed）写入的数据量；
- kB_read：读取的总数据量；kB_wrtn：写入的总数量数据量；
这些单位都为Kilobytes。

上面的例子中，我们可以看到磁盘sda以及它的各个分区的统计数据，当时统计的磁盘总TPS是1.95，下面是各个分区的TPS。（因为是瞬间值，所以总TPS并不严格等于各个分区TPS的总和）

## 实例4：查看设备使用率（%util）和响应时间（await）
```
iostat -dx 5 
Linux 2.6.32-279.el6.x86_64 (colin)   07/16/2014      _x86_64_        (4 CPU)

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.02     7.25    0.04    1.90     0.74    35.47    37.15     0.04   19.13   5.58   1.09
dm-0              0.00     0.00    0.04    3.05     0.28    12.18     8.07     0.65  209.01   1.11   0.34
dm-1              0.00     0.00    0.02    5.82     0.46    23.26     8.13     0.43   74.33   1.30   0.76
dm-2              0.00     0.00    0.00    0.01     0.00     0.02     8.00     0.00    5.41   3.28   0.00
```
- rrqm/s： 每秒进行 merge 的读操作数目.即 delta(rmerge)/s
- wrqm/s： 每秒进行 merge 的写操作数目.即 delta(wmerge)/s
- r/s： 每秒完成的读 I/O 设备次数.即 delta(rio)/s
- w/s： 每秒完成的写 I/O 设备次数.即 delta(wio)/s
- rsec/s： 每秒读扇区数.即 delta(rsect)/s
- wsec/s： 每秒写扇区数.即 delta(wsect)/s
- rkB/s： 每秒读K字节数.是 rsect/s 的一半,因为每扇区大小为512字节.(需要计算)
- wkB/s： 每秒写K字节数.是 wsect/s 的一半.(需要计算)
- avgrq-sz：平均每次设备I/O操作的数据大小 (扇区).delta(rsect+wsect)/delta(rio+wio)
- avgqu-sz：平均I/O队列长度.即 delta(aveq)/s/1000 (因为aveq的单位为毫秒).
- await： 平均每次设备I/O操作的等待时间 (毫秒).即 delta(ruse+wuse)/delta(rio+wio)
- svctm： 平均每次设备I/O操作的服务时间 (毫秒).即 delta(use)/delta(rio+wio)
- %util： 一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间 I/O 队列是非空的，即 delta(use)/s/1000 (因为use的单位为毫秒)
> 如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。 idle小于70% IO压力就较大了，一般读取速度有较多的wait。 同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比，高过30%时IO压力高)。

另外 await 的参数也要多和 svctm 来参考。差的过高就一定有 IO 的问题。

avgqu-sz 也是个做 IO 调优时需要注意的地方，这个就是直接每次操作的数据的大小，如果次数多，但数据拿的小的话，其实 IO 也会很小。如果数据拿的大，才IO 的数据会高。也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s。也就是讲，读定速度是这个来决定的。

svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了)，svctm 的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多也会间接导致 svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘，调整内核 elevator 算法，优化应用，或者升级 CPU。

队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标，但由于 avgqu-sz 是按照单位时间的平均值，所以不能反映瞬间的 I/O 洪水。

形象的比喻：
- r/s+w/s 类似于交款人的总数
- 平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数
- 平均服务时间(svctm)类似于收银员的收款速度
- 平均等待时间(await)类似于平均每人的等待时间
- 平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少
- I/O 操作率 (%util)类似于收款台前有人排队的时间比例
- 设备IO操作:总IO(io)/s = r/s(读) +w/s(写)

平均等待时间=单个I/O服务器时间*(1+2+...+请求总数-1)/请求总数

每秒发出的I/0请求很多,但是平均队列就4,表示这些请求比较均匀,大部分处理还是比较及时。