Slave_IO_Running: No

找不到初始日志

• 报错信息

1
2
3
4

Slave_IO_Running: No
Slave_SQL_Running: Yes
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

• 原因分析

该错误发生在从库 io 进程从主库拉取日志时，发现主库的 mysql_bin.index 文件中第一个文件不存在，出现此类报错可能有两个原因：

1）Slave 由于某种原因停了好长一段是时间，当你重启 Slave 复制的时候，在主库上找不到相应的 binlog 。

2）由于某些设置主库上的 binlog 被删除了，导致从库获取不到对应的 binlog。

1
2
3
4
5
6
7
8
9
10
11
12

[root@hop02 mzjh]# ll | grep mysql-bin
-rw-rw----. 1 mysql mysql  1073742013 Sep 12 14:55 mysql-bin.001948
-rw-rw----. 1 mysql mysql  1073742073 Sep 13 11:53 mysql-bin.001949
-rw-rw----. 1 mysql mysql  1073742120 Sep 14 08:39 mysql-bin.001950
-rw-rw----. 1 mysql mysql  1073859355 Sep 15 06:21 mysql-bin.001951
-rw-rw----. 1 mysql mysql  1074054892 Sep 16 06:18 mysql-bin.001952
-rw-rw----. 1 mysql mysql  1075243641 Sep 17 06:18 mysql-bin.001953
-rw-rw----. 1 mysql mysql  1074801420 Sep 18 06:16 mysql-bin.001954
-rw-rw----. 1 mysql mysql  1075257243 Sep 19 06:16 mysql-bin.001955
-rw-rw----. 1 mysql mysql   619405162 Sep 19 13:32 mysql-bin.001956
-rw-rw----. 1 mysql mysql  1072898197 Sep 20 09:44 mysql-bin.001957
-rw-r-----. 1 mysql mysql         190 Sep 19 13:32 mysql-bin.index

• 解决方法

为了避免数据丢失，需要重新搭建 Slave

磁盘空间不足，日志被截断

• 报错信息

1
2
3
4

Slave_IO_Running: No
Slave_SQL_Running: Yes
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'binlog truncated in the middle of event; consider out of disk space on master; the first event 'mysql-bin.006130' at 733347710, the last event read from './mysql-bin.006130' at 733347710, the last byte read from './mysql-bin.006130' at 733347840.'

• 原因分析

该错误和主库的空间和 sync_binlog 配置有关，当主库 sync_binlog = N 不等于 1 且磁盘空间满时，MySQL 每写 N 次 binlog，系统才会同步到磁盘，但是由于存储日志的磁盘空间满而导致 MySQL 没有将日志完全写入磁盘，binlog event 被截断，从库读取该 binlog 时就会报错 binlog truncated in the middle of event。

• 解决方法

在从库重新指向到主库下一个可用的 binlog 并且从初始化的位置开始：

1
2
3

stop slave;
change master to master_log_file = 'mysql-bin.006131', master_log_pos = 4;
start slave;

Slave_SQL_Running: No

1026：HA_ERR_RBR_LOGGING_FAILED

• 报错信息

1
2
3
4

Slave_IO_Running: Yes
Slave_SQL_Running: No
Error_code: 1026
Last_Error: Could not execute Update_rows event on table cosmo-aps.bns_aps_versiontolineinfo; Error writing file '/data/mysql/tmp/MLpTCcJu' (Errcode: 28 - No space left on device), Error_code: 3; Error writing file 'mysql-bin' (errno: 28 - No space left on device), Error_code: 1026; handler error HA_ERR_RBR_LOGGING_FAILED; the event's master log mysql-bin.000528, end_log_pos 674303230

• 原因分析

  • Master 和 Slave 数据不一致导致
  • Slave 服务器重启，事务回滚造成

• 解决方法

  • 手动跳过

  1 2 3

  stop slave ; set global sql_slave_skip_counter=1; start slave ;

  • pt-slave-restart

1205：HA_ERR_LOCK_WAIT_TIMEOUT

报错信息：

1

Last_Error: Could not execute Update_rows event on table haier.haier_weixin_user; Lock wait timeout exceeded; try restarting transaction, Error_code: 1205; handler error HA_ERR_LOCK_WAIT_TIMEOUT; the event's master log mysql-bin.000001, end_log_pos 629671840

1032：HA_ERR_END_OF_FILE

• 报错信息

1
2
3
4

Slave_IO_Running: Yes
Slave_SQL_Running: No
Last_Errno: 1032
Last_Error: Could not execute Update_rows event on table haier.haier_yonghuzhongxin_shebei; Can't find record in 'haier_yonghuzhongxin_shebei', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log mysql-bin.000030, end_log_pos 130643848

• 原因分析

1
2
3

191208 23:06:33 [ERROR] Slave SQL: Could not execute Update_rows event on table haier.haier_yonghuzhongxin_shebei; Can't find record in 'haier_yonghuzhongxin_shebei', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log mysql-bin.000030, end_log_pos 130643848, Error_code: 1032
191208 23:06:33 [Warning] Slave: Can't find record in 'haier_yonghuzhongxin_shebei' Error_code: 1032
191208 23:06:33 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000030' position 130643274

• 解决方法

1
2
3

stop slave;
set global sql_slave_skip_counter=1;
start slave;

1032：HA_ERR_KEY_NOT_FOUND

Last_SQL_Errno: 1032

Last_SQL_Error: Could not execute Delete_rows event on table hce.dim_r_cei_general; Can’t find record in ‘dim_r_cei_general’, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event’s master log mysql-bin.000273, end_log_pos 139807561

背景

数据是企业的生命线，PSI 线上系统数据基本都存储在青岛本地机房，缺少异地容灾能力，当出现机房级灾难场景下（如：地震、海啸、火灾等），业务连续性受到极大的影响，损失不可估量。如下图所示，目前 PSI 已具备前两类故障场景的覆盖能力，需要构建覆盖第三类故障场景能力，全方位保障业务数据安全，有备无患。

目标

• 保证极端场景下业务数据可恢复
• RPO < 2 小时，RTO < 24 小时

方案

设计方案：如下图所示，重要系统生产数据（青岛本地机房：电信机房、联通机房、移动机房…）同步至红岛灾备数据中心，特别重要系统数据压缩存储上传至阿里云 OSS。

实施方案：从库实例再搭建一个从实例形成级联结构，对数据进行实时同步，主要为避免增加主库负载。

实例拓扑：

系统监控：

• 主实例：TDDS_M

• 从实例：TDDS_S

• 灾备实例：TDDS_D

什么是 Docker ？

Docker 使用 Google 公司推出的 Go 语言 进行开发实现，基于 Linux 内核的 cgroup，namespace，以及 AUFS 类的 Union FS 等技术，对进程进行封装隔离，属于 操作系统层面的虚拟化技术。由于隔离的进程独立于宿主和其它的隔离的进程，因此也称其为容器。

Docker 架构图

虚拟机 vs 容器

基本概念

镜像

Docker 镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。镜像文件可以看作是容器的模板，只有通过这个文件，才能生成 Docker 容器。

容器

镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的 类 和 实例 一样，镜像是静态的定义，容器是镜像运行时的实体，容器可以被创建、启动、停止、删除、暂停等。容器的实质是进程，但与直接在宿主执行的进程不同，容器进程运行于属于自己的独立的 命名空间。

仓库

镜像构建完成后，可以很容易的在当前宿主机上运行，但是，如果需要在其它服务器上使用这个镜像，我们就需要一个集中的存储、分发镜像的服务，Docker Registry 就是这样的服务。

一个 Docker Registry 中可以包含多个 仓库（Repository）；每个仓库可以包含多个 标签（Tag）；每个标签对应一个镜像，我们可以通过 <仓库名>:<标签> 的格式来指定具体是这个软件哪个版本的镜像。

Docker 官方仓库，由于某些原因，在国内访问这些服务可能会比较慢，国内的一些云服务商提供了针对 Docker Hub 的镜像服务（Registry Mirror），这些镜像服务被称为加速器，例如 阿里云加速器。国内也有一些云服务商提供类似于 Docker Hub 的公开服务。比如 时速云镜像仓库、网易云镜像服务、DaoCloud 镜像市场、阿里云镜像库 等。

Dockerfile

Docker 根据该文件生成二进制的镜像文件。

1
2
3

FROM java:8
ADD /mall-admin-1.0-SNAPSHOT.jar //
ENTRYPOINT ["java", "-jar", "-Dspring.profiles.active=prod","/mall-admin-1.0-SNAPSHOT.jar"]

常用命令

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

$ systemctl start docker  // 启动docker
$ systemctl stop docker   // 关闭docker
$ docker restart xx       // 重启一个容器
$ docker stop xx          // 停止一个容器
$ docker rm xx            // 删除一个容器
$ docker rm -f xx         // 强制删除一个容器
$ docker log xx           // 查看容器日志

# 镜像相关
docker images：列出已经下载的镜像
docker rmi java：删除本地镜像
docker build：构建镜像
docker search java：在Docker Hub（或阿里镜像）仓库中搜索关键字（如java）的镜像
docker pull java:8：从仓库中下载镜像，若要指定版本，则要在冒号后指定

# 容器相关
docker ps：列出运行中的容器
docker ps -a ：列出所有的容器
docker stop 容器id：停止容器
docker kill 容器id：强制停止容器
docker start 容器id：启动已停止的容器
docker inspect 容器id：查看容器的所有信息
docker container logs 容器id：查看容器日志
docker top 容器id：查看容器里的进程
docker exec -it 容器id /bin/bash：进入容器
exit：退出容器
docker rm 容器id：删除已停止的容器
docker rm -f 容器id：删除正在运行的容器

docker run -d -p 91:80 nginx ：在后台运行nginx，若没有镜像则先下载，并将容器的80端口映射为宿主机的91端口。
-d：后台运行
-P：随机端口映射
-p：指定端口映射
-net：网络模式

学习资源

深入剖析 Kubernetes

Docker 从入门到实践

问题

• 索引是什么？
• 为什么选择用 B+ 树索引？
• 聚集索引和非聚集索引的区别？
• 为什么建议使用整型自增做主键？

简介

索引：是帮助 MySQL 高效获取数据的排好序的数据结构。

索引是应用程序设计和开发的一个重要方面，若索引太多，应用程序的性能可能会受到影响。而索引太少，对查询性能又会产生影响。需要找到一个合适的平衡点，这对应用程序的性能至关重要。

InnoDB 存储引擎支持 3 种常见的索引：

• B+ 树索引
• 全文索引
• 哈希索引

InnoDB 存储引擎索引

B+ 树索引

注意：B+ 树中的 B 不是代表二叉（binary），而是代表平衡（balance），因为 B+ 树是从最早的平衡二叉树演化而来，但是 B+ 树不是一个二叉树。

B+ 树索引并不能找到一个给定键值的具体行，B+ 树索引能找到的只是被查找数据行所在的页，然后数据库通过把页读入到内存，再在内存中进行查找，最后得到要查找的数据。

MyISAM：索引文件和数据文件是分离的，非聚集索引。

InnoDB

1
2
3
4
5
6
7
8

// MyISAM存储引擎，存储在*.MYI
-rw-r----- 1 mysql mysql   10816 3月  30 13:52 user.frm
-rw-r----- 1 mysql mysql     616 3月  30 13:54 user.MYD
-rw-r----- 1 mysql mysql    4096 4月  17 17:32 user.MYI

// InnoDB存储引擎，存储在*.ibd
-rw-r----- 1 mysql mysql    8838 3月  30 13:52 servers.frm
-rw-r----- 1 mysql mysql   98304 3月  30 13:52 servers.ibd

聚集索引：叶子节点包含了完整的数据记录。

非聚集索引：索引文件和数据文件没有聚集在一起。

主键索引

二级索引

全文索引

哈希索引

数据库的索引一般在磁盘上，数据量大的情况可能无法一次装入内存，B+ 树的设计可以允许数据分批加载，同时树的高度较低，提高查询效率。

为什么 MySQL 选择用 B+ 树索引？

当数据在磁盘中时，磁盘 IO 会成为最大的性能瓶颈，设计的目标应该是尽量减少 IO 次数；而树的高度越高，增删改查所需要的 IO 次数也越多，会严重影响性能。树的查找性能取决于树的高度，让树尽量平衡，就是为了降低树的高度。

二叉树

二叉查找树

• 对于树中的任意一个节点，左子树节点比根节点小，右子树节点比根节点大。
• 时间复杂度：O(logn)
• 缺点：不平衡，极端情况如有序序列，二叉排序树退化成链表，时间复杂度变为 O(n)。

平衡二叉树（AVL）

• AVL 树是严格的平衡二叉树，所有节点的左右子树高度差不能超过 1。
• AVL 树查找、插入和删除在平均和最坏情况下都是 O(logn)。
• 缺点：旋转耗时，AVL 树在删除数据时效率很低，量级为 O(logn)。

红黑树

• 与 AVL 树相比，红黑树并不追求严格的平衡，而是大致的平衡。
• 红黑树引入了颜色，当插入或删除数据时，只需要进行 O(1) 次数的旋转以及变色就能保证基本的平衡。
• 缺点：树的高度太高。

B 树

B 树是一种多路搜索树，它的每个节点可以拥有多于两个孩子节点，M 路的 B 树最多能拥有 M 个孩子节点。

• 不再是二叉查找，而是 M 叉查找，树的高度能够大大降低。
• 叶子节点，非叶子节点，都存储数据。
• 中序遍历，可以获得所有节点。

B+ 树

B+ 树是在 B 树的基础上进行改造：

• 非叶子节点不再存储数据，数据只存储在同一层的叶子节点上。
• 叶子之间，增加了链表，获取所有节点，不再需要中序遍历。
• 优点：在查询多条数据或范围查询时，B 树可能要跨层访问，而 B+ 树数据都在叶子节点，不用跨层，同时由于有链表结构，只需要找到首尾，就能把所有数据取出来。

局部性原理与磁盘预读

• 磁盘预读：磁盘读写并不是按需读取，而是按页预读，一次会读一页的数据，每次加载更多的数据，如果未来要读取的数据就在这一页中，可以避免未来的磁盘 IO，提高效率（通常，一页数据是 4K）。
• 局部性原理：软件设计要尽量遵循“数据读取集中”与使用到一个数据，大概率会使用其附近的数据，这样磁盘预读能充分提高磁盘 IO。

总结

1) 二叉查找树 (BST)：解决了排序的基本问题，但是由于无法保证平衡，可能退化为链表。

2) 平衡二叉树 (AVL)：通过旋转解决了平衡的问题，但是旋转操作效率太低。

3) 红黑树：通过舍弃严格的平衡和引入红黑节点，解决了 AVL 旋转效率过低的问题，但是在磁盘等场景下，树仍然太高，IO 次数太多。

4) B 树：通过将二叉树改为多路平衡查找树，解决了树过高的问题。

5) B+ 树：在 B 树的基础上，将非叶节点改造为不存储数据的纯索引节点，进一步降低了树的高度，此外将叶节点使用指针连接成链表，范围查询更加高效。

MySQL 索引实现

MyISAM

InnoDB

简介

锁：是计算机协调多个进程或线程并发访问某一资源的机制。

MySQL锁机制：相对其他数据库而言，MySQL 的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。MyISAM 和 MEMORY 存储引擎采用的是表级锁（table-level locking）；InnoDB 存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。

① 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。

② 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。

从上述特点可见，很难笼统地说哪种锁更好，只能就具体应用的特点来说哪种锁更合适！仅从锁的角度来说：表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如 Web 应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（OLTP）系统。由于 BDB 已经被 InnoDB 取代，即将成为历史（所以现在基本都在使用 InnoDB 存储引擎）。

如何查看表锁情况？可查看两个变量：

Table_locks_immediate：立刻获得表锁的次数

Table_locks_waited：需要等待表锁的次数，如果等待表锁的次数占比较大，说明表锁可能是潜在瓶颈。

1
2
3
4
5
6
7
8

mysql> show status like 'Table_locks%';
+-----------------------+---------+
| Variable_name         | Value   |
+-----------------------+---------+
| Table_locks_immediate | 1789993 |
| Table_locks_waited    | 0       |
+-----------------------+---------+
2 rows in set (0.00 sec)

表级锁的两种模式：

• 表共享读锁（Table Read Lock）

• 表独占写锁（Table Write Lock）

InnoDB

如果 InnoDB_row_lock_waits 和 InnoDB_row_lock_time_avg 的值比较高，表示锁争用情况比较严重。

1
2
3
4
5
6
7
8
9
10
11

mysql> show status like 'InnoDB_row_lock%';
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| Innodb_row_lock_current_waits | 0     |
| Innodb_row_lock_time          | 0     |
| Innodb_row_lock_time_avg      | 0     |
| Innodb_row_lock_time_max      | 0     |
| Innodb_row_lock_waits         | 0     |
+-------------------------------+-------+
5 rows in set (0.00 sec)

InnoDB 实现了一下两种类型的行锁：

• 共享锁(S)：允许一个事务去多一行，阻止其它事务获得相同数据集的排他锁。
• 排他锁(X): 允许获得排他锁的事务更新数据，阻止其它事务获得相同数据集的共享锁和排他写锁。

另外，为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB 还有两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁。（感觉与MyISAM 的表锁机制类似）

• 意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的 IS 锁。
• 意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的 IX 锁。

InnoDB行锁模式兼容性列表：

死锁（DeadLock)

避免死锁的方法

1. 在应用中，如果不同的程序会并发存取多个表，应尽量约定以相同的顺序来访问表，这样可以大大降低产生死锁的机会。在下面的例子中，由于两个 session 访问两个表的顺序不同，发生死锁的机会就非常高！但如果以相同的顺序来访问，死锁就可以避免。
2. 在程序以批量方式处理数据的时候，如果事先对数据排序，保证每个线程按固定的顺序来处理记录，也可以大大降低出现死锁的可能。
3. 在事务中，如果要更新记录，应该直接申请足够级别的锁，即排他锁，而不应先申请共享锁，更新时再申请排他锁，因为当用户申请排他锁时，其他事务可能又已经获得了相同记录的共享锁，从而造成锁冲突，甚至死锁。
4. 在 REPEATABLE-READ 隔离级别下，如果两个线程同时对相同条件记录用 SELECT…FOR UPDATE 加排他锁，在没有符合该条件记录情况下，两个线程都会加锁成功。程序发现记录尚不存在，就试图插入一条新记录，如果两个线程都这么做，就会出现死锁。这种情况下，将隔离级别改成 READ COMMITTED，就可避免问题。
5. 当隔离级别为 READ COMMITTED 时，如果两个线程都先执行 SELECT…FOR UPDATE，判断是否存在符合条件的记录，如果没有，就插入记录。此时，只有一个线程能插入成功，另一个线程会出现锁等待，当第 1 个线程提交后，第 2 个线程会因主键重出错，但虽然这个线程出错了，却会获得一个排他锁！这时如果有第 3 个线程又来申请排他锁，也会出现死锁。

介绍

意义：

作用：

基本概念

数据中心

• DB：数据来源，可以为MySQL、SQLserver、文件日志等。

• ETL：将数据从来源迁移到目标的几个过程，抽取、转换、加载三个过程。

• ODS：操作性数据，作为数据库到数据仓库的一种过渡。

• DW ：数据仓库，数据的归宿，这些数据一般不会被修改。

• DM：数据集市，从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据，面向应用。

数据库 vs 数据仓库

• 数据库：任何结构化数据集合，允许用户访问和管理数据库。
• 数据仓库：面向主题的，集成的，相对稳定的，反映历史变化的数据集合，用于支持管理决策。

百度数据仓库服务 Palo

主流数据仓库

• Teradata：连续 15 年 Gartner 领导者象限

• Hive：

确切地说，Hive 是基于 Hadoop 的数据仓库工具，可以对存储在 HDFS 上的文件数据集进行查询和分析处理。Hive 对外提供了类似于 SQL 语言的查询语言 HiveQL，在做查询时将 HQL 语句转换成 MapReduce 任务，在Hadoop 层进行执行。

• HDFS：Hadoop 的分布式文件系统，在这里作为数据仓库的存储层。图中的 Data Node 就是 HDFS 的众多工作节点。

• MapReduce：一种针对海量数据的并行计算模型，可以简单理解为对多个数据分片的数据转换和合并。

特点

1. 主题性：不同于传统数据库对应于某一个或多个项目，数据仓库根据使用者实际需求，将不同数据源的数据在一个较高的抽象层次上做整合，所有数据都围绕某一主题来组织

2. 集成性：数据仓库中存储的数据是来源于多个数据源的集成，原始数据来自不同的数据源，存储方式各不相同。要整合成为最终的数据集合，需要从数据源经过一系列抽取、清洗、转换的过程。

3. 稳定性：数据仓库中保存的数据是一系列历史快照，不允许被修改。用户只能通过分析工具进行查询和分析。

4. 时变性：数据仓库会定期接收新的集成数据，反应出最新的数据变化。这和特点并不矛盾。

数据仓库架构图

网易猛犸

数据仓库建设

• 数据仓库简述
• 为什么建设数据仓库？
• 如何搭建企业数据仓库？
• 宜人贷实践

MySQL

• 《MySQL 必知必会》

• 《MySQL 官方手册》

• 《MySQL 8 Cookbook（中文版）》

• 《高性能MySQL（第3版）》

• 《MySQL技术内幕：InnoDB存储引擎（第2版）》

编程

• 《程序员的自我修养》

• 《程序员的修炼之道》

• 《代码大全》

• 《编程之美》

• 《编程珠玑》

• 《重构》

计算机基础

• 《深入理解计算机系统》
• 《图解TCP/IP》

其它

• 《影响力》
• 《暗时间》

修炼

工程师 - 高级工程师 - 技术专家 - 初级架构师 - 中级架构师 - 高级架构师

工程师阶段：基础技能积累阶段（基础知识、编程语言、编程工具）

高级工程师：积累方案设计经验并能独立完成开发（需求设计、方案设计、编码实现）

技术专家：拓展技术宽度

初级架构师：能够独立完成一个系统的架构设计

中级架构师：能够完成复杂系统的架构设计

高级架构师：创造新的架构模式

软件发布全流程

• 需求分析（需求梳理 => 产品定义）
• 系统设计（子系统划分 => 模块定义）
• 模块设计（模块详细设计）
• 编码实现
• 单元测试
• 代码评审
• 集成测试
• 灰度发布
• 正式发布

客户端

HeidiSQL

Navicat

Sequel Pro

MySQL Workbench

运维

Percona-Toolkit

XtraBackup

压测

sysbench

tpcc-mysql

中间件

MySQL Proxy

Atlas

Mycat

可视化

Redash