我们经常使用 docker exec 命令进入到一个容器里进行一些操作，那么这个命令是如果进入到容器里的呢？想必大家都知道用到了Namespace来实现，但至于底层实现原理是什么，想必都不是特别清楚吧。

我们知道容器的本质其实就是一个进程，每个进程都有一个Pid，至于容器的Pid值可以通过 docker inspect container_id 来查看，我们这里是一个Python应用容器，我们看一下他的 Pid值

docker inspect --format '{{ .State.Pid }}'  4ddf4638572d
25686

而每个进程都有自己的Namespace，你可以通过查看宿主机的 proc 文件，看到这个 25686 进程的所有 Namespace 对应的文件

ls -l  /proc/25686/ns
total 0
lrwxrwxrwx 1 root root 0 Aug 13 14:05 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 ipc -> ipc:[4026532278]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 mnt -> mnt:[4026532276]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 net -> net:[4026532281]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 pid -> pid:[4026532279]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 pid_for_children -> pid:[4026532279]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Aug 13 14:05 uts -> uts:[4026532277]

可以看到，一个进程的每种 Linux Namespace，都在它对应的 /proc/[进程号]/ns 下有一个对应的虚拟文件，并且链接到一个真实的 Namespace 文件上。可以看到这个容器对应的Net Namespace Id为 4026532281

Namespace 的作用是“隔离”，它让应用进程只能看到该Namespace 内的“世界”；而 Cgroups 的作用是“限制”，它给这个“世界”围上了一圈看不见的墙。

命名空间是 Linux 内核一个强大的特性。每个容器都有自己单独的命名空间，运行在其中的应用都像是在独立的操作系统中运行一样。命名空间保证了容器之间彼此互不影响。

在docker中一共有以下几个命名空间，每个Namespace的发挥着不同的作用。

pid 命名空间

不同用户的进程就是通过 pid 命名空间隔离开的，且不同命名空间中可以有相同 pid。在同一个Namespace中只能看到当前命名空间的进程。所有的 LXC 进程在 Docker 中的父进程为Docker进程，每个 LXC 进程具有不同的命名空间。同时由于允许嵌套，因此可以很方便的实现嵌套的 Docker 容器。

net 命名空间

有了 pid 命名空间, 每个命名空间中的 pid 能够相互隔离，但是网络端口还是共享 host 的端口。网络隔离是通过 net 命名空间实现的， 每个 net 命名空间有独立的 网络设备, IP 地址, 路由表, /proc/net 目录。这样每个容器的网络就能隔离开来。Docker 默认采用 veth 的方式，将容器中的虚拟网卡同 host 上的一 个Docker 网桥 docker0 连接在一起。

ipc 命名空间

容器中进程交互还是采用了 Linux 常见的进程间交互方法(interprocess communication – IPC), 包括信号量、消息队列和共享内存等。然而同 VM 不同的是，容器的进程间交互实际上还是 host 上具有相同 pid 命名空间中的进程间交互，因此需要在 IPC 资源申请时加入命名空间信息，每个 IPC 资源有一个唯一的 32 位 id。

背景

在日常工作中，我们一般会将容器进行精简，将其大小压缩到最小，以此来提高容器部署效率，参考小米云技术 – Docker最佳实践：5个方法精简镜像。但有一个比较尴尬的问题就是对容器排障，由于容器里没有了我们日常工作中用到许多排障命令，如top、ps、netstat等，所以想排除故障的话，常用的做法是安装对应的命令，如果容器过多的话，再这样搞就有些麻烦了，特别是在一些安装包源速度很慢的情况。

解决方案

今天发现一篇文章（简化 Pod 故障诊断：kubectl-debug 介绍）介绍针对此类问题的解决方案的，这里介绍的是一个叫做 kubectl-debug 的命令，由国内知名的PingCAP公司出品的，主要用在k8s环境中的。我们知道容器里主要两大技术，一个是用cgroup来实现容器资源的限制，一个是用Namespace来实现容器的资源隔离的）。（kubectl-debug 命令是基于一个工具包（） 来实现的，其原理是利用将一个工具包容器添加到目标容器所在的Pod里，实现和目标容器的Network Namespace一致，从而达到对新旧容器进程的相互可见性，这样我们就可以直接在目标容器里操作这些命令。所以在平时开发环境中，可以很方便的利用此原理直接使用这个工具包来实现对容器的排障。

在 Kubernetes 项目中，这些容器则会被划分为一个“Pod”，Pod 里的容器共享同一个 Network Namespace、同一组数据卷，从而达到高效率交换信息的目的。这些容器应用就可以通过 Localhost 通信，通过本地磁盘目录交换文件。

netshoot包含一组强大的工具，如图所示

工具包清单

apache2-utils
bash
bind-tools
bird
bridge-utils
busybox-extras
calicoctl
conntrack-tools
ctop
curl
dhcping
drill
ethtool
file
fping
iftop
iperf
iproute2
iptables
iptraf-ng
iputils
ipvsadm
libc6-compat
liboping
mtr
net-snmp-tools
netcat-openbsd
netgen
nftables
ngrep
nmap
nmap-nping
openssl
py-crypto
py2-virtualenv
python2
scapy
socat
strace
tcpdump
tcptraceroute
util-linux
vim

看了上图不得不说几乎包含了所有的调度命令。

使用也很方便，只需要一条命令即可

$ docker run -it --net container: nicolaka/netshoot

参数 --net 是 --network 的缩写，有四种值，用法参考： https://docs.docker.com/engine/reference/run/#network-settings

最近搭建了es集群的时候，现在需要测试添加一个新的数据节点，项目是使用docker-compose命令来搭建的。

以下基于最新版本 es7.2.0进行, 配置文件目录为 es, 所以docker 在创建网络的时候，网络名称会以 es_ 前缀开始，如本例中我们在docker-composer.yaml文件中指定了网络名称为esnet,但docker生成的实例名称为 es_esnet，至于网络相关的信息可以通过 docker network --help 查看。

搭建es集群

// docker-compose.yaml 集群配置文件

version: '2.2'
services:
  es01:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.2.0
    container_name: es01
    environment:
      - node.name=es01
      - node.master=true
      - node.data=true
      - discovery.seed_hosts=es02
      - cluster.initial_master_nodes=es01,es02
      - cluster.name=docker-cluster
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - esdata01:/usr/share/elasticsearch/data
    ports:
      - 9200:9200
    networks:
      - esnet
  es02:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.2.0
    container_name: es02
    environment:
      - node.name=es02
      - discovery.seed_hosts=es01
      - cluster.initial_master_nodes=es01,es02
      - cluster.name=docker-cluster
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - esdata02:/usr/share/elasticsearch/data
    networks:
      - esnet
  es03:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.2.0
    container_name: es03
    environment:
      - node.name=es03
      - discovery.seed_hosts=es01
      - cluster.initial_master_nodes=es01,es02
      - cluster.name=docker-cluster
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - esdata03:/usr/share/elasticsearch/data
    networks:
      - esnet
volumes:
  esdata01:
    driver: local
  esdata02:
    driver: local
  esdata03:
    driver: local

networks:
  esnet:

集群配置了3个master节点，并同时作为数据节点使用，当节点未指定 node.master和node.data的时候，默认值为 true 。执行命令

先看一个结构体

// 写法一
type T1 struct {
	a int8
	b int64
	c int16
}

// 写法二
type T2 struct {
	a int8
	c int16
	b int64
}

对于这两个结构体，都有a、b、c三个定义完全一样的字段，只是在定义结构体的时候字段顺序不一样而已，那么两种写法有什么影响吗？

对于新手来说，感觉着没有什么区别的，只是一个书写顺序不同而已，但对于go编译器来说，则有着很大的区别，特别是在不同架构上(32位/64位）的编译器，在一定程度上对内存的使用大小和执行效率有着一定的不同。这里的主要知识点就是golang语言中的内存对齐概念（alignment guarantee），

类型的尺寸和结构体字节填充（structure padding）

Go白皮书只对以下种类的类型的尺寸进行了明确规定。

类型种类                  尺寸（字节数）
------                   ------
byte, uint8, int8        1
uint16, int16            2
uint32, int32, float32   4
uint64, int64            8
float64, complex64       8
complex128               16
uint, int                取决于编译器实现。通常在
                         32位架构上为4，在64位
                         架构上为8。
uintptr                  取决于编译器实现。但必须
                         能够存下任一个内存地址。

Go白皮书没有对其它种类的类型的尺寸最初明确规定。 请阅读值复制成本一文来获取标准编译器使用的各种其它类型的尺寸。

标准编译器（和gccgo编译器）将确保一个类型的尺寸为此类型的对齐保证的倍数。

为了满足上一节中规定的地址对齐保证要求，Go编译器可能会在结构体的相邻字段之间填充一些字节。 这使得一个结构体类型的尺寸并非等于它的各个字段类型尺寸的简单相加之和。

下面是一个展示了一些字节是如何填充到一个结构体中的例子。 首先，从上面的描述中，我们已得知（对于标准编译器来说）：

• 内置类型int8的对齐保证和尺寸均为1个字节； 内置类型int16的对齐保证和尺寸均为2个字节； 内置类型int64的尺寸为8个字节，但它的对齐保证在32位架构上为4个字节，在64位架构上为8个字节。
• 下例中的类型T1和T2的对齐保证均为它们的各个字段的最大对齐保证。 所以它们的对齐保证和内置类型int64相同，即在32位架构上为4个字节，在64位架构上为8个字节。
• 类型T1和T2尺寸需为它们的对齐保证的倍数，即在32位架构上为4n个字节，在64位架构上为8n个字节。

type T1 struct {
	a int8

	// 在64位架构上，为了让下一个字段b的地址为8字节对齐，
	// 需在在字段a这里填充7个字节。在32位架构上，为了让
	// 字段b的地址为4字节对齐，需在这里填充3个字节。

	b int64
	c int16

	// 为了让类型T1的尺寸为T1的对齐保证的倍数，
	// 在64位架构上需在这里填充6个字节，在32架构
	// 上需在这里填充2个字节。
}
// 类型T1的尺寸在64位架构上位24个字节（1+7+8+2+6），
// 在32位架构上为16个字节（1+3+8+2+2）。
// 以保存每个字段都是8（64位架构）或者4(32位架构)的的整数倍

type T2 struct {
	a int8

	// 为了让下一个字段c的地址为2字节对齐，
	// 需在字段a这里填充1个字节。

	c int16

	// 在64位架构上，为了让下一个字段b的地址为8字节对齐，
	// 需在字段c这里填充4个字节。在32位架构上，不需填充
	// 字节即可保证字段b的地址为4字节对齐的。

	b int64
}
// 类型T2的尺寸在64位架构上位16个字节（1+1+2+4+8），
// 在32位架构上为12个字节（1+1+2+8）。

从这个例子可以看出，尽管类型T1和T2拥有相同的字段集，但是它们的尺寸并不相等。**每个字段的大小都要受下一个字段大小的影响，以方便下个字段对齐。**所以建议在开发中，字段占用空间小的放在前面。T1的内存对齐T2的内存对齐

官方网站：，中文: http://kafka.apachecn.org/

注意它和其它消息系统(消息队列)在定义上的区别，以便更好的理解它的应用场景。Apache Kafka 是一款分布式流处理平台（Distributed Streaming Platform）。

术语

消息：Record。消息实体，是通信的基本单位。 主题：Topic。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务。 分区：Partition。一个有序不变的消息序列。每个主题Topic下可以有多个分区。 消息位移：Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值。 缓存代理，Broker。Kafka集群中的一台或多台服务器统称broker。 副本：Replica。Kafka 中同一条消息能够被拷贝到多个地方以提供数据冗余，这些地方就是所谓的副本。副本还分为领导者副本和追随者副本，各自有不同的角色划分。副本是在分区层级下的，即每个分区可配置多个副本实现高可用。 生产者：Producer。向主题发布新消息的应用程序。 消费者：Consumer。从主题订阅新消息的应用程序。 消费者位移：Consumer Offset。表示消费者消费进度，每个消费者都有自己的消费者位移。 消费者组：Consumer Group。_多个消费者实例共同组成的一个组，同时消费多个分区_以实现高吞吐。 重平衡：Rebalance。消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。

为什么kafka比其它消息系统有着很高的吞吐量? “零拷贝“:

rabbitMQ、activeMQ、zeroMQ、Kafka、Redis 比较: https://www.cnblogs.com/valor-xh/p/6348009.html

为了防止ES集群中单点问题，一般都需要对集群节点做高可用性，当发生单点问题时，也可以向外正常提供服务。这里主要记录一下节点的加入、离开和主节点选举。

集群安装教程请参考：

节点角色

集群是由多个节点组成的，每个节点都扮演着不同的角色，一般常用的有 Master、Data 和 client。节点角色介绍：

节点角色配置参数： node.master: true node.data: false node.ingest: false

在一个集群中，可以通过 查看到每个节点在集群中扮演的角色，一个节点可同时拥有多个角色，如值MDI，同时也是每个节点的默认值，其中的 Ingest 节点也称作预处理节点，不过在生产环境中一般将master 和 data节点分开的。所有节点默认都是支持 Ingest 操作的。节点组合参考：

新节点的加入

随着数量大的增加，有时候我们不得进行机器的扩容，这时间就需要加入一些新的机器节点，用来提高访问速度。

当一个新节点加入的时候，它通过读取 discovery.zen.ping.unicast.hosts 配置的节点获取集群状态，然后找到 master 节点，并向其发送一个join request(discovery.zen.join_timeout)。主节点接收到请求后，同步集群状态到新节点。

节点离开

这里指非 mastr 节点。 当master主节点定期ping（ping_interval 默认为1s）一个节点出现3次ping不通的情况时（ping_timeout 默认为30s），主节点会认为该节点已宕机，将该节点踢出集群。

主节点的选举

我们知道集群中master节点角色的重要性，如果此节点出现问题的话，服务基本处于不可用状态了，所以保证master节点的高可用性至关重要。

当主节点发生故障时，集群中的其他节点将会ping当前的 master eligible 节点，并从中选出一个新的主节点。 节点可以通过设置 node.master=true 来设置自己的角色为主节点。 通过配置discovery.zen.minimum_master_nodes防止集群出现脑裂。该配置通过检查集群中 master eligible 的个数来判断是否选举出一个主节点。其个数最好设置为**(number_master eligible/2)+1**，防止当主节点出问题时，一个集群分裂为两个集群。 具有最小编号的active master eligible node将会被选举为master节点。参考：

脑裂的概念：

如果你有2个Master候选节点，并设置最小Master节点数为1，当网络抖动或偶然断开时，2个Master都会认为另一个Master挂掉了，他们都被选举为主Master，则此时集群中存在两个主Master，即物理上1个集群变成了逻辑上的2个集群，而当其中一个Master再次挂掉时，即便它恢复后回到了原有的集群，在它作为主Master期间写入的数据都会丢失，因为它上面维护了Index信息。类似我们平时的投票选举一下，10个人如果赞成与返对的比例为5:5就不太好了，所以必须保证双方的票数无法完全一样才可以。

为了防止脑裂，常常设置参数为discovery.zen.minimum_master_nodes=N/2+1，其中N为集群中Master节点的个数。建议集群中Master节点的个数为奇数个，如3个或者5个。

在版本 6 和更早的版本中，还有一些其他以 discovery.zen.* 开头的选项，允许你配置 Zen Discovery 的行为。其中一些设置不再有效，已被删除。其他的已经改名。如果一个参数已经被改名，那么它的旧名称在版本 7 中就被弃用，你需要调整配置来使用新名称。

新的集群协调子系统包括一个新的故障检测机制。这意味着 discovery.zen.fd.* 开头的 Zen Discovery 错误检测设置不再有效。大多数用户应该在版本 7 或更高版本中使用默认的故障检测配置，如果需要进行任何更改，可以使用cluster.fault_detection.*

最近要搭建es集群，由于刚接触es不久，直接使用的docker构建，发现当用两个容器搭建好集群时，再添加新的es容器节点时，总是出现其它容器被kill的现象，查看容器日志未发现任何错误信息，导致一段时间非常的迷茫。

起始认为是配置不当引起了，于是一直在配置这方面找问题，网上的有些教程是直接在物理机器上或者虚拟机上进行部署，而自己的环境是docker, 通过 docker-compose 来部署的，环境有些差异。

有网友提醒有可能是由 OOM 引起的问题，因为代码是137, 使用命令 “docker inspect 容器ID” 查看了一下容器, status列显示”OOMKilled": false” ，所以从这里查看的话，并非是 OOM 引起的，起初个人分析容器的启动过程，是在启动一个容器时，dockerd应该先检查内存是否足够，如果不足够的话，则启动新窗口失败才对，而不是先将已存在的窗口killed，再去启动新容器，所以仍将OOM的原因排除掉了。

后来发现一篇文章 介绍到这个和 docker for mac 分配的内存大小有关系，试着将给 docker 分配的内存调整为4G，重新 docker-compose up 竟然解决了。

由此可见docker软件对容器启动时处理逻辑与自己分析的还是有些差异的。 可惜浪费了好几天的时间，很值的好好反思一下！

总结一下，还是基础不牢固，解决思路，分析问题不清晰，一直在配置这一块的周旋，虽然首次怀疑是OOM引起的，但在容器日志里并没有OOM的日志信息，再加上集群编排时有“ – “ES_JAVA_OPTS=-Xms512m -Xmx512m” 配置项,给es分配512M的内存大小，也忽略掉物理机器给docker分配内存大小这个因素了，所以直接将OOM的原因排除了，而未想到OOM发生时，并不保证一定在容器日志里记录的。

由于要安装一个docker服务，对外提供端口用的是9000, 和php-fpm的监听端口冲突，所以需要先停止一下php-fpm服务。

多次执行

sudo killall php-fpm

发现过一会php-fpm会自动启动，就算一个一个的进程kill -9 也一样的效果。经过分析这个应该是和php-fpm配置文件 ~/Library/LaunchAgents/[email protected] 有关。

我们知道 ~/Library/LaunchAgents 针对当前用户的启动项目录，针对这个项目里的一些配置服务有一个 launchctl 命令可以操作，其中有几个命令我们需要知道他的意思

launchctl load 启动plist运行
launchctl unload  卸载
launchctl list 查看所有启动任务

默认当用户登录后，mac系统会对当前目录 ~/Library/LaunchAgents 里的每个配置服务文件自动执行launchctl load 命令。如果我们想停止一个服务的话，则需要执行 launchctl unload 命令即可。

`$ LaunchAgents launchctl list | grep php

66054 0 [email protected]

$ LaunchAgents launchctl unload ~/Library/LaunchAgents/[email protected]

$ LaunchAgents launchctl list | grep php`

然后再用ps 查看确认php-fpm已停止。

新特新解读 | MySQL 8.0 对 count(*)的优化 新特性解读 | MySQL 8.0 正则替换 新特性解读 | MySQL 8.0 资源组 新特性解读 | MySQL 8.0 Temptable 引擎介绍

新特性解读 | MySQL 8.0 窗口函数详解

新特性解读 | MySQL 8.0 json到表的转换

新特性解读 | MySQL 8.0.16 在组复制中启用成员自动重新加入

新特性解读 | MySQL 8.0 直方图

新特性解读 | MySQL 8.0 索引特性1-函数索引

新特性解读 | MySQL 8.0 索引特性2-索引跳跃扫描

新特性解读 | MySQL 8.0 索引特性3 -倒序索引

新特性解读 | MySQL 8.0 索引特性4-不可见索引

新特性解读 | MySQL 8.0.16 组复制通讯协议的设置

新特性解读 | MySQL 8.0.16 组复制新功能：消息碎片化

MySQL 中的隔离四种隔离级别与锁的关系一直挺模糊的，看了好多文章感觉着都不是很好理解，今天在“爱可生开源社区”看到一篇文章，感觉着挺容易理解的。

READ UNCOMMITTED 未提交读，可以读取未提交的数据。

READ COMMITTED 已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句， InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。 Gap locking 仅用于外键约束检查和重复键检查。

REPEATABLE READ 可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。

SERIALIZABLE 序列化

文中主要对 RR 和 RC 两种常用的隔离级别做了不同情况的说明，对于 SERIALIZABLE 序列化 和 READ UNCOMMITTED 未提交读，由于很好理解所以未在文中体现。**对于 RR 和 RC 主要区别是 RR 存在 Gap Lock间隙锁，而RC则没有Gap Lock间隙锁，**所以在互联网中绝大部分是采用了RC 隔离级别，而未使用MySQL中默认的RR级别。对于锁的介绍请参考： https://blog.haohtml.com/archives/17758

在MySQL5.7以前，ibdata1文件会逐渐增大（ ibdata1文件包含哪些信息?），非常占用系统空间，特别是一些云数据来说，磁盘非常的贵，想要回收空间，只能进行一次导出和导入操作，来重新生成undo 表空间，从MySQL5.7开始，有了在线回收undo表空间的功能，主要由以下几个参数设置。

innodb_undo_directory = . 为undo文件存储路径。如果没有指定默认值(NULL)，则undo表空间则存放到mysql的data目录里(datadir选项)。配置此项可以用undo从ibdata文件里分离出来。单独存储。

innodb_undo_logs = 128 (默认值 128）undo rollback segment 回滚段个数，为 innodb_rollback_segments 参数选项的别名，最大值为128，其中32个为使用临时表空间 ibtmp1 保留，1个为系统表空间使用，剩余的95个为 undo tablespaces 使用。 当 innodb_rollback_segments<=32的时候，系统将自动分配1个rollback segment给系统表空间，32个分给临时表空间。 此选项以后版本将移除！

innodb_undo_tablespaces = 0 (MySQL5.7默认值为0，MySQL8默认值为2)undo文件个数，此值需要在MySQL Server 初始化的时候指定，一经设定，以后将无法修改，否则重启后会提示部分Undo 文件找不到。默认值为0, 此时无法进行Undo回收操作，回收undo表空间至少需要为2个才可以， 需保证其中一个进行回收收缩时，另一个为可用状态。保存路径为 innodb_undo_directory选项设置，undo文件名规则为 undoN。文件大小受innodb_page_size选项影响。 此选项以后版本将移除！

innodb_undo_log_truncate = OFF （默认值NO)参数设置为ON，即开启在线回收undo日志文件，支持动态设置，当超过 innodb_max_undo_log_size 时被进行收缩，至少需要两个undo文件，即innodb_undo_tablespace>=2

innodb_max_undo_log_size = 1073741824 (默认1GB)当超过阈值时，会触发truncate回收动作，truncate后空间缩小到10MB

innodb_purge_rseg_truncate_frequency = 128 (默认值128), 控制回收undo log的频率。 指定purge操作被唤起多少次之后才释放rollback segments。当undo表空间里面的rollback segments被释放时，undo表空间才会被truncate。由此可见，该参数越小，undo表空间被尝试truncate的频率越高。 。

联想思考： ibdata文件包含哪些信息? undo logs、change buffer、doublewrite buffer、表数据、索引数据，如果启用了 innodb_file_per_table 选项的话，则表数据和索引数据则存储到相应表的.ibd 文件里)，参考： https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_ibdata_file

ibdata文件爆增原因有哪些? 事务未提交、大事务、启用了共享表空间、磁盘io过慢导致check point远远落后。等等

如何避免ibdata文件一直爆增的问题? 尽量短事务、增加 purge 线程、加速purge频率(innodb_purge_truncate_frequency)、监控 information_schema.Innodb_trx 表，设置长事务阈值，超过就报警 / 或者 kill

从调度上看，goroutine的调度开销远远小于线程调度开销。

OS的线程由OS内核调度，每隔几毫秒，一个硬件时钟中断发到CPU，CPU调用一个调度器内核函数。这个函数暂停当前正在运行的线程，把他的寄存器信息保存到内存中(暂时保存线程状态），查看线程列表并决定接下来运行哪一个线程，再从内存中恢复线程的注册表信息，最后继续执行选中的线程。这种线程切换需要一个完整的上下文切换：即保存一个线程的状态到内存，再恢复另外一个线程的状态，最后更新调度器的数据结构。某种意义上，这种操作还是很慢的。OS 线程调度器

Go运行的时候包涵一个自己的调度器，这个调度器使用一个称为一个M:N调度技术，m个goroutine到n个os线程（可以用GOMAXPROCS来控制n的数量），Go的调度器不是由硬件时钟来定期触发的，而是由特定的go语言结构来触发的，他不需要切换到内核语境，所以调度一个goroutine比调度一个线程的成本低很多。

从栈空间上，goroutine的栈空间更加动态灵活。

每个OS的线程都有一个固定大小的栈内存，通常是2MB，栈内存用于保存在其他函数调用期间哪些正在执行或者临时暂停的函数的局部变量。这个固定的栈大小，如果对于goroutine来说，可能是一种巨大的浪费。作为对比，goroutine在生命周期开始只有一个很小的栈，典型情况是2KB, 在go程序中，一次创建十万左右的goroutine也不罕见（2KB*100,000=200MB）。而且goroutine的栈不是固定大小，它可以按需增大和缩小，最大限制可以到1GB。

参考： https://time.geekbang.org/course/detail/160-86799

goroutine没有一个特定的标识。

在大部分支持多线程的操作系统和编程语言中，线程有一个独特的标识，通常是一个整数或者指针，这个特性可以让我们构建一个线程的局部存储，本质是一个全局的map，以线程的标识作为键，这样每个线程可以独立使用这个map存储和获取值，不受其他线程干扰。

goroutine中没有可供程序员访问的标识，原因是一种纯函数的理念，不希望滥用线程局部存储导致一个不健康的超距作用，即函数的行为不仅取决于它的参数，还取决于运行它的线程标识。

• https://cloud.tencent.com/developer/article/1006514
• https://yq.aliyun.com/articles/27667

今天利用docker容器创建mysql8.0的时候(window系统），指定了本地宿主机器的一个目录为容器mysql的datadir目录，发现创建失败了。

创建命令：

$ docker run -d --name mysql81 -v /e/container/mysql/mysql81/datadir:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123456 -p 33081:3306 mysql

错误提示：

$ docker logs mysql81
2019-01-26T03:05:42.567230Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
2019-01-26T03:05:42.567618Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.13) starting as process 1
2019-01-26T03:05:42.572006Z 0 [Warning] [MY-010159] [Server] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
2019-01-26T03:05:42.832344Z 1 [ERROR] [MY-012592] [InnoDB] Operating system error number 22 in a file operation.
2019-01-26T03:05:42.832473Z 1 [ERROR] [MY-012596] [InnoDB] Error number 22 means 'Invalid argument'
2019-01-26T03:05:42.832556Z 1 [ERROR] [MY-012646] [InnoDB] File ./#innodb_temp/temp_1.ibt: 'aio write' returned OS error 122. Cannot continue operation
2019-01-26T03:05:42.832609Z 1 [ERROR] [MY-012981] [InnoDB] Cannot continue operation.

解决办法：