因为设备无法直接连接到互联网，希望通过http代理的通道pull镜像
sudo mkdir -p /etc/systemd/system/docker.service.d
sudo touch /etc/systemd/system/docker.service.d/proxy.conf
sudo vim /etc/systemd/system/docker.service.d/proxy.conf
[Service]
Environment="HTTP_PROXY=http://127.0.0.1:7890/"
Environment="HTTPS_PROXY=http://127.0.0.1:7890/"
Environment="NO_PROXY=localhost,127.0.0.1,192.168.*.*"
sudo systemctl daemon-reload
sudo systemctl restart docker
分布式
节点 & 集群
主分片及副本
一、Elasticsearch 分布式
Elasticsearch 分布式特性包括如下几个点：
1.1 高可用
什么是高可用？CAP 定理是分布式系统的基础，也是分布式系统的 3 个指标：
Consistency（一致性）
Availability（可用性）
Partition tolerance（分区容错性）
那高可用（High Availability）是什么？高可用，简称 HA，是系统一种特征或者指标，通常是指，提供一定性能上的服务运行时间，高于平均正常时间段。反之，消除系统服务不可用的时间。
衡量系统是否满足高可用，就是当一台或者多台服务器宕机的时候，q系统整体和服务依然正常可用。举个例子，一些知名的网站保证 4 个 9 以上的可用性，也就是可用性超过 99.99%。那 0.01% 就是所谓故障时间的百分比。
Elasticsearch 在高可用性上，体现如下两点：
服务可用性：允许部分节点停止服务，整体服务没有影响
数据可用性：允许部分节点丢失，最终不会丢失数据
1.2 可扩展
随着公司业务发展，Elasticsearch 也面临两个挑战：
搜索数据量从百万到亿量级
搜索请求 QPS 也猛增
那么需要将原来节点和增量数据重新从 10 个节点分布到 100 个节点。Elasticsearch 可以横向扩展至数百（甚至数千）的服务器节点，同时可以处理PB级数据。Elasticsearch 为了可扩展性而生，由小规模集群增长为大规模集群的过程几乎完全自动化，这是水平扩展的体现。
1.3 Elasticsearch 分布式特性
上面通过可扩展性，可以看出 Elasticsearch 分布式的好处明显：
存储可以水平扩容，水平空间换时间
部分节点停止服务，整个集群服务不受影响，照样正常提供服务
Elasticsearch 在后台自动完成了分布式相关工作，如下：
自动分配文档到不同分片或者多节点上
均衡分配分片到集群节点上，index 和 search 操作时进行负载均衡
复制每个分片，支持数据冗余，防止硬件故障数据丢失
集群扩容时，无缝整合新节点，并且重新分配分片
等等
Elasticsearch 集群知识点如下：
不同集群通过名字区分，默认集群名称为 "elasticsearch"
集群名 cluster name ，可以通过配置文件修改或者命令行 -E cluster.name=user-es-cluster 进行设置
一个集群由多个节点组成
二、Elasticsearch 节点 & 集群
Elasticsearch 集群有多个节点组成，形成分布式集群。那么，什么是节点呢？
节点（Node），就是一个 Elasticsearch 应用实例。大家都知道 Elasticsearch 源代码是 Java 写的，那么节点就是一个 Java 进程。所以类似 Spring 应用一样，一台服务器或者本机可以运行多个节点，只要对应的端口不同即可。但生产服务器中，一般一台服务器运行一个 Elasticsearch 节点。还有需要注意：
Elasticsearch 都会有 name ，通过 -E node.name=node01 指定或者配置文件中配置
每个节点启动成功，都会分配对应得一个 UID ，保存在 data 目录
可以通过命令 _cluster/health 查看集群的健康状态，如下：
Green 主分片与副本分片都正常
Yellow 主分片正常，副本分片不正常
Red 有主分片不正常，可能某个分片容量超过了磁盘大小等
如图，有主（Master）节点和其他节点。那么节点有多少类型呢？
2.1 Master-eligible Node 和 Master Node
Elasticsearch 被启动后，默认就是 Master-eligible Node。然后通过参与选主过程，可以成为 Master Node。具体选主原理，后续单独写一篇文章。Master Node 有什么作用呢？
Master Node 负责同步集群状态信息：
所有节点信息
所有索引即其 Mapping 和 Setting 信息
所有分片路由信息
只能 Master 节点可以修改信息，是因为这样就能保证数据得一致性
2.2 Data Node 和 Coordinating Node
Data Node，又称数据节点。用于保存数据，其在数据扩展上起至关重要的作用。
Coordinating Node，是负责接收任何 Client 的请求，包括 REST Client 等。该节点将请求分发到合适的节点，最终把结果汇集到一起。一般来说，每个节点默认起到了 Coordinating Node 的职责。
2.3 其他节点类型
还有其他节点类型，虽然不常见，但需要知道：
Hot & Warm Node：不同硬件配置的 Data Node，用来实现冷热数据节点架构，降低运维部署的成本
Machine Learning Node：负责机器学习的节点
Tribe Node：负责连接不同的集群。支持跨集群搜索 Cross Cluster Search
一般在开发环境中，设置单一的角色节点：
master node：通过 node.master 配置，默认 true
data node：通过 node.data 配置，默认 true
ingest node：通过 node.ingest 配置，默认 true
coordinating node：默认每个节点都是 coordinating 节点，设置其他类型全部为 false。
machine learning：通过 node.ml 配置，默认 true，需要通过 x-pack 开启。
三、主分片及副本
同样看这个图，3 个节点分别为 Node1、Node2、Node3。并且 Node3 上面有一个主分片 P0 和一个副本 R2。那什么是主分片呢？
主分片，用来解决数据水平扩展的问题。比如上图这个解决可以将数据分布到所有节点上：
节点上可以有主分片，也可以没有主分片
主分片在索引创建的时候确定，后续不允许修改。除非 Reindex 操作进行修改
副本，用来备份数据，提高数据的高可用性。副本分片是主分片的拷贝
副本分片数，可以动态调整
增加副本数，可以一定程度上提高服务读取的吞吐和可用性
如何查看 Elasticsearch 集群的分片配置呢？可以从 settings 从看出：
number_of_shards 主分片数
number_of_replicas 副本分片数
{
"my_index": {
"settings": {
"index": {
"number_of_shards": "8",
"number_of_replicas": "1"
}
}
}
}
复制
实战建议：对生产环境中，分片设置很重要，需要最好容量评估与规划
根据数据容量评估分配数，设置过小，后续无法水平扩展；单分片数据量太大，也容易导致数据分片耗时严重
分片数设置如果太大，会导致资源浪费，性能降低；同时也会影响搜索结果打分和搜索准确性
索引评估，每个索引下面的单分片数不用太大。如何评估呢？比如这个索引 100 G 数据量，那设置 10 个分片，平均每个分片数据量就是 10G 。每个分片 10 G 数据量这么大，耗时肯定严重。所以根据评估的数据量合理安排分片数即可。如果需要调整主分片数，那么需要进行 reindex 等迁索引操作。
小结
从上一篇到这一篇：
一个节点，对应一个实例
一个节点，可以多个索引
一个索引，可以多个分片
一个分片，对应底层一个 lucene 分片
比如知道了搜索性能场景，例如多少数据量，多大的写入，是写为主还是查询为主等等，才可以确定：
磁盘，推荐 SSD，JVM最大 Xmx 不要超过30G。副本分片至少设置为1。主分片，单个存储不要超过 30 GB，按照这个你推算出分片数，进行设定。
集群中磁盘快满的时候，你再增加机器，确实可能导致新建的索引全部分配到新节点上去的可能性。最终导致数据分配不均。所以要记得监控集群，到70%就需要考虑删除数据或是增加节点
可以设置最大分片数缓解这个问题。
分片的尺寸如果过大，确实也没有快速恢复的办法，所以尽量保证分片的size在40G以下
GET _cluster/health?pretty
GET _cluster/pending_tasks?pretty
GET _cluster/allocation/explain?prettyq
PUT _cluster/settings
{
"transient": {
"cluster.routing.allocation.exclude._ip": "10.1.22.129"
}
}
1.查询分片状态
GET /_cat/shards
2.查看节点信息
GET /_nodes/节点名称/stats/indices?pretty
PUT _cluster/settings
{
"transient": {
"cluster.routing.allocation.exclude._ip": null
}
}
PUT my_index/_settings
{
"index": {
"number_of_replicas": 1
}
}
cluster.routing.allocation.node_concurrent_recoveries
单节点分片恢复的并发数
indices.recovery.max_bytes_per_sec
单节点分片恢复的速率，适用于 peer recoveries 和 snapshot recoveries
peer recoveries 对等恢复，增加副本数就是对等恢复
GET _cluster/settings?flat_settings&include_defaults
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.node_concurrent_recoveries": "4",
"indices.recovery.max_bytes_per_sec": "100mb"
}
}
GET _cat/recovery?v=true&h=i,s,t,ty,st,shost,thost,f,fp,b,bp
快照的速度
indices.recovery.max_bytes_per_sec 仍然有效
HDFS 与 S3
max_snapshot_bytes_per_sec 指定创建快照时的速度，默认为 40mb/s
max_restore_bytes_per_sec 指定数据恢复速度，默认无限制
快照恢复的进度
GET _cat/recovery?v=true&h=i,s,t,ty,st,rep,snap,f,fp,b,bp
查看分片未分配原因
GET _cat/shards?v&h=index,docs,shard,prirep,state,unassigned.reason
查看进度
# 示例
GET _cat/recovery?v=true&h=index,shard,time,type,stage,files_percent,bytes_percent
# 示例（简写）
GET _cat/recovery?v=true&h=i,s,t,ty,st,fp,bp
今天有同学反应有个golang的服务内存占用比较大需要扩下容，监控看了下内存占用超过1G，觉得挺有意思的可以分析分析，在我写过的golang服务里面很少有内存占用比较大的，另外这个服务在我看来应该是比较简单的不至于用到这么多的内存。那就分析分析怎么对golang的程序内存进行分析
velero是vmware推出的一款开源的针对Kubernetes的集群资源备份还原的工具。一般而言可以有以下的作用
频繁偶发API接口请求返回 ERR_CONTENT_LENGTH_MISMATCH
nginx(orange) 所在磁盘满了
ng开启客户端缓存，磁盘不足时候写临时文件失败
Syntax: client_body_buffer_size size;
Default:
client_body_buffer_size 8k|16k;
Context: http, server, location
Sets buffer size for reading client request body. In case the request body is larger than the buffer, the whole body or only its part is written to a temporary file. By default, buffer size is equal to two memory pages. This is 8K on x86, other 32-bit platforms, and x86-64. It is usually 16K on other 64-bit platforms.
https://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_buffer_size