Git 是分布式的，而 Svn 不是分布的;

Git 把内容按元数据方式存储，而 SVN 是按文件;

Git 没有一个全局版本号，而 SVN 有：目前为止这是跟 SVN 相比 Git 缺少的最大的一个特征;
Git 的内容的完整性要优于 SVN: GIT 的内容存储使用的是 SHA-1 哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏;

Git 下载下来后，在 OffLine 状态下可以看到所有的 Log,SVN 不可以; SVN 必须先 Update 才能 Commit,忘记了合并时就会出现一些错误，git 还是比较少的出现这种情况。
克隆一份全新的目录以同样拥有五个分支来说，SVN 是同时复製 5 个版本的文件,也就是说重复五次同样的动作。而 Git 只是获取文件的每个版本的 元素，然后只载入主要的分支(master)在我的经验,克隆一个拥有将近一万个提交(commit),五个分支,每个分支有大约 1500 个文件的 SVN,耗了将近一个小时！而 Git 只用了区区的 1 分钟！

版本库（repository):SVN 只能有一个指定中央版本库。当这个中央版本库有问题时，所有工作成员都一起瘫痪直到版本库维修完毕或者新的版本库设立完成。而 Git 可以有无限个版本库。或者，更正确的说法，每一个 Git 都是一个版本库，区别是它们是否拥有活跃目录（Git Working Tree）。如果主要版本库（例如：置於 GitHub 的版本库）发生了什麼事，工作成员仍然可以在自己的本地版本库（local repository）提交，等待主要版本库恢复即可。工作成员也可以提交到其他的版本库！

分支（Branch）在 SVN，分支是一个完整的目录。且这个目录拥有完整的实际文件。如果工作成员想要开啟新的分支，那将会影响“全世界”！每个人都会拥有和你一样的分支。如果你的分支是用来进行破坏工作（安检测试），那将会像传染病一样,你改一个分支，还得让其他人重新切分支重新下载，十分狗血。而 Git，每个工作成员可以任意在自己的本地版本库开啟无限个分支。
Git 的分支名是可以使用不同名字的。例如：我的本地分支名为 OK，而在主要版本库的名字其实是 master。

提交（Commit）在 SVN，当你提交你的完成品时，它将直接记录到中央版本库。当你发现你的完成品存在严重问题时，你已经无法阻止事情的发生了。如果网路中断，你根本没办法提交！而 Git 的提交完全属於本地版本库的活动。而你只需“推”（git push）到主要版本库即可。Git 的“推”其实是在执行“同步”（Sync）。

总结：SVN 的特点是简单，只是需要一个放代码的地方时用是 OK 的。

Git 的特点版本控制可以不依赖网络做任何事情，对分支和合并有更好的支持(当然这是开发者最关心的地方)，不过想各位能更好使用它，需要花点时间尝试一下。

因为在不同公司有不同选用，特找到一个大佬做出的总结。非本人所写

收起阅读 »

ActiveMQ是老牌的消息中间件，国内很多公司过去运用的还是非常广泛的，功能很强大。
存在问题：没法确认ActiveMQ可以支撑互联网公司的高并发、高负载以及高吞吐的复杂场景，在国内互联网公司落地较少。而且使用较多的是一些传统企业，用ActiveMQ做异步调用和系统解耦。

RabbitMQ，他的好处在于可以支撑高并发、高吞吐、性能很高，同时有非常完善便捷的后台管理界面可以使用。另外，他还支持集群化、高可用部署架构、消息高可靠支持，功能较为完善。而且经过调研，国内各大互联网公司落地大规模RabbitMQ集群支撑自身业务的case较多，国内各种中小型互联网公司使用RabbitMQ的实践也比较多。除此之外，RabbitMQ的开源社区很活跃，较高频率的迭代版本，来修复发现的bug以及进行各种优化，因此综合考虑过后，公司采取了RabbitMQ。
存在问题：RabbitMQ自身是基于erlang语言开发的，所以导致较为难以分析里面的源码，也较难进行深层次的源码定制和改造，毕竟需要较为扎实的erlang语言功底才可以。

RocketMQ，是阿里开源的，经过阿里的生产环境的超高并发、高吞吐的考验，性能卓越，同时还支持分布式事务等特殊场景，而且RocketMQ是基于Java语言开发的，适合深入阅读源码，有需要可以站在源码层面解决线上生产问题，包括源码的二次开发和改造。

Kafka提供的消息中间件的功能明显较少一些，相对上述几款MQ中间件要少很多。
但是Kafka的优势在于专为超高吞吐量的实时日志采集、实时数据同步、实时数据计算等场景来设计。
因此Kafka在大数据领域中配合实时计算技术（比如Spark Streaming、Storm、Flink）使用的较多。但是在传统的MQ中间件使用场景中较少采用。（某大型央企核心业务系统日志采集分析ELK,部署过程中，我便选用Kafka，当然只是通过file beat采集到Kafaka）

收起阅读 »

关于秘猿
---
杭州秘猿科技有限公司（Cryptape Co.,Ltd.）的使命是用技术创造信任，为未来数字世界构建新的基础设施和服务。秘猿科技成立于 2016 年 ，2017 年获得招银国际战略投资，是一家以纯研究与工程为导向的技术公司，在区块链领域实力深厚。

我们具有丰富的区块链生态实践经验。从 2011 年开始参与或主导各种区块链项目，包括世界第一个开源的数字资产交易平台貔貅 Peatio；星火矿池 Spark pool； 以太坊 Ethereum；以太坊爱好者社区 Ethfans； 开源区块链底层内核 CITA ；与招商银行等主流金融机构进行的金融+区块链合作；以及现在正在开发的 Nervos CKB 和 Muta 等等，涵盖了区块链生态的各个方面。

我们具有深厚的区块链技术研发和工程实力。首席架构师谢晗剑曾是由 Vitalik Buterin 所领导的以太坊 (Ethereum) 研究团队中唯一的中国成员，参与设计了包括 Casper 在内的以太坊下一代核心算法，后带领团队设计并实现了中国第一个开源高性能区块链 CITA 及新一代公有链 Nervos CKB，撰写了多篇区块链研究及技术文章并提出了“公有许可链”（又称“开放联盟链”）的概念。首席科学家张韧博士毕业于鲁汶大学 COSIC 实验室，长期专注于区块链共识协议、安全和隐私研究，在国际顶级密码学及区块链会议上发表过多篇论文，曾在 Blockstream 与 Pieter Wuillie 和 Gregory Maxwell 共同工作。首席产品官王博为原中钞区块链研究院产品总监，曾设计参与多个重大区块链项目。

我们一直奉行开放和开源的精神，坚信透明是信任的基础，开源是区块链的基石，所有项目代码均在 Github 开源。我们与国内外多家研究机构及团队建立了长期的合作关系和良好的交流通道，无条件的与合作伙伴分享研究成果。

* 公司官网：https://www.cryptape.com
* 招聘地址：https://www.cryptape.com/join
* 我们的代码：https://www.cryptape.com/code

岗位信息
---
### 高级运维开发工程师
#### 工作内容
* 负责开发及维护区块链系统的 CI/CD、部署等自动化运维体系
* 负责开发及维护区块链的监控报警、日志、追踪等系统
* 探索区块链/分布式系统如何结合 devops 提高可观察性, 使得 Debug、性能调优更加高效便利
#### 任职要求
* 熟悉 Ubuntu/CentOS/Gentoo 等 Linux 发行版
* 熟悉 Python/Go/Javascript/Rust 等任意一门开发语言，可以开发相关自动化工具，热衷自动化运维
* 熟悉 Git/Github，参与过开源项目或了解开源项目的 CI/CD
* 有云原生开发经验，具备 Kubernetes 二次开发能力, 熟悉常用的云原生组件如: Prometheus, Jaeger
* 对 DevOps、GitOps 有所实践，能打通研发过程中的自动化运维流程
* 有较好的系统分析设计能力、文档撰写能力、流程意识与标准化思维
* 有 Aliyun/AWS 等云平台服务运维经验
#### 加分项
* 熟悉区块链系统
* 了解分布式测试

**简历投递邮箱 join@cryptape.com，也可联系 HR 小姐姐 zhangjinyu@cryptape.com 了解更多信息 投递简历请备注来自 新运维** 收起阅读 »

前言：全文中一共有常用的（事实上你如果花1-2周阅读、理解、自己动手设一下后是需要这么多参数的）76个参数，笔者把近10年里3个亿万级项目的数据库调优用此篇浓缩到了可能读者只需要2周时间就可以掌握，同时我是按照：

每一个参数干吗？
在某些典型硬件配置下的db上参数该设多少？
设会怎么样？
不设会怎么样？
有什么坑如何填坑？
有些参数怎么算、算法又如何

这种style来写的，相信此篇会对一些使用mysql的尤其是正在或者将要面临万级并发的项目、网站有所帮助。具体请看文档！

一千个DBA就有一千种配置方式!

大家一定记得不要轻易去看网上，要看只看官网！网上很多博客都是错的，连参数都列错了，5.7很多参数和5.6是完全不一样的。

可能你从未看到过这样的一篇集中火力式的把mysql参数列了这么全的文章，很有兴曾参与过超3万并发的18～19年的数轮520、618、双11、双12保卫战。因此这一篇是汇集了最精华和实战的内容把mysql所有的参数列在这边供大家参考。并且以（64c cpu，128gb内存）的mysql cpu和内存来进行了一轮配置。而此文的内存相关参数部分可以延展至256gb～512gb。

另外有一点，建议在mysql的服务器上使用ssd。除非并发数永远控制在500-1000内那就没必要使用ssd，普通高速磁盘就可以了。

你会发觉这篇文章是一篇宝藏，这些参数都能够自己动手试验一篇基本在外面是可以吊打mysql面试官了。

client域：

1.character_set_client

推荐设置：

utf8mb4

作用：

字符集设定，如果前台有连social mobile application一类包括wechat，并且允许有使用emoji表情的，请开启成utf8mb4

如果不配的后果：

mysql不支持前端app存表情等字符

配置实例：

character_set_client=utf8mb4

mysqld域：

1)server-id

推荐设置：

如果没有做任何主从复制，此值可以不设。

作用：

遇有主从复制，必设该值，每个参与主从复制的mysql实例的server-id不能重复，必须为阿拉伯数字。

如果不配的后果：

如果你用的是主从复制，这个id不设那么整个mysql的主从复制会失几。

配置实例：

server-id=1

2)port

推荐设置：

3306

作用：

mysql实例端口

如果不配的后果：

默认为3306

配置实例：

port=3306

3)bind_address

推荐设置：

0.0.0.0

作用：

除非有特殊需要，我们会限制只允许mysql实例被某一个ip方问，不支持多个，生产上都为：0.0.0.0然后使用防火墙策略来控制。

如果不配的后果：

默认不允许远程登录

配置实例：

bind_address=0.0.0.0

4)autocommit

推荐设置：

1

作用：

生产上开启成1，如果你开启的是0会有一个这样的情况：

a运行一条insert语句，并未作commit;b去做查询此时b是查询不到的。这种操作一般用于在写store procedure时用到。

如果不配的后果：

如果在系统的my.cnf层面把它设成了0，如果在使用时（99%情况是用的1）时，你想要用root在生产运行时把它设成set autocommit = 1都开启不了。而如果你在一开始就没它设置成1，那么当碰到某些特殊场景特别是写store procedure时需要把它设成0时，你是可以手动临时把某一个session给开在0的。

配置实例：

autocommit = 1

5)character_set_server

推荐设置：

utf8mb4

作用：

字符集设定，如果前台有连social mobile application一类包括wechat，并且允许有使用emoji表情的，请开启成utf8mb4

如果不配的后果：

mysql不支持前端app存表情等字符

配置实例：

character_set_server=utf8mb4

6)skip_name_resolve

推荐设置：

1

作用：

生产上建议开启成1，这样mysql server不会对客户端连接使用反向dns解析，否则客户端连上后有时在遇有生产高速运行时直接timeout，如果设成了1带来的问题就是你不能在mysql中使用主机名来对客户端权限进行划分，而是需要使用ip。

如果要做成即允许mysql里允许使用主机名来分配客户端连接权限，又要做到不要让mysql去做dns解析，可以在mysql所在主机端的/etc/hosts文件中写上客户端的主机名，因为当客户端连接连上来时，mysql反向查找客户端连接时的域名解析的步骤是：首先查找 /etc/hosts 文件，搜索域名和IP的对应关系。但是这样做也有一个问题，那就是如果你有多个客户端多个mysql主从关系，哪到你要把mysql做成一个dns解析器吗？因此推荐设成1

如果不配的后果：

mysql server每一次会对客户端连接使用反向dns解析，经常会出现客户端连上后有timeout现象。

配置实例：

skip_name_resolve=1

7)max_connections

推荐设置：

20,000

作用：

最大连接数，以微品会：前端3万的tps并发，假设redis命中失效50%（这是灾难），那么后端mysql单个主或从开启连接数为：20,000，我们公司在前端并发曾达到过6万，80%被waf、vanish、缓存挡掉，落在db上的qps最高一次为20,000连接，再按照mysql官方，max_connections值受系统os最大打开连接数限制，因此我们需要做以下2步操作：

1）在 /etc/security/limits.conf 底部增加2行

mysql hard nofile 65535
mysql soft nofile 65535
2）在/usr/lib/systemd/system/mysqld.service（视如何安装mysql所决定，用编译安装和yum安装会产生path路径不同。）文件最后添加：

LimitNOFILE=65535
LimitNPROC=65535
$ systemctl daemon-reload
$ systemctl restart mysqld.service
如不生效重服务器。

如果不配的后果：

默认只有150

配置实例：

max_connections = 20,000

8)max_connect_errors

推荐设置：

生产上设10

开发测试上使用默认-100

作用：

生产上开启成10次，开发测试上使用默认即不设。

max_connect_errors是一个MySQL中与安全有关的计数器值，它负责阻止过多尝试失败的客户端以防止暴力破解密码的情况。如果需要设置此数值，手动添加。当此值设置为10时，意味着如果某一客户端尝试连接此MySQL服务器，但是失败（如密码错误等等）10次，则MySQL会无条件强制阻止此客户端连接。相关的登录错误信息会记录到performance_schema.host_cache表中。如果希望重置此计数器的值，则必须重启MySQL服务器或者执行

Mysql> FLUSH HOSTS;

1 Mysql> FLUSH HOSTS;

当这一客户端成功连接一次MySQL服务器后，针对此客户端的max_connect_errors会清零。可以在防火墙上做策略限制某些ip的远程连接。

如果不配的后果：

默认为100

配置实例：

max_connect_errors =10

9)innodb_flush_log_at_trx_commit

推荐设置：

2

作用：

(核心交易系统设置为1，默认为1，其他2或者0)，

0代表：log buffer将每秒一次地写入log file中，并且log file的flush(刷到磁盘)操作同时进行。该模式下在事务提交的时候，不会主动触发写入磁盘的操作。

1代表：每次事务提交时MySQL都会把log buffer的数据写入log file，并且flush(刷到磁盘)中去，该模式为系统默认（因此会保留每一份redo日志）

2代表：每次事务提交时MySQL都会把log buffer的数据写入log file，但是flush(刷到磁盘)操作并不会同时进行。该模式下，MySQL会每秒执行一次 flush(刷到磁盘)操作。该模式速度较快，也比0安全，只有在操作系统崩溃或者系统断电的情况下，上一秒钟所有事务数据才可能丢失。

除非你用的是小型机或者是超大规模mysql集群一类如：游戏行业，那么需要保留每一秒的事务，否则请设成2，要不然会严重影响系统性能。这个参数是5.6所没有的。

如果不配的后果：

默认为1，影响系统写性能。

配置实例：

innodb_flush_log_at_trx_commit=2

10)transaction_isolation

推荐设置：

READ-COMMITTED

作用：

此参数直接决定了mysql的性能，oracle中的事务默认级别就是read-commited，而mysql的默认级别是:repeatable-read，它利用自身独有的Gap Lock解决了"幻读"。但也因为Gap Lock的缘故，相比于READ-COMMITTED级别的Record Lock，REPEATABLE-READ的事务并发插入性能受到很大的限制。离级别的选择取决于实际的业务需求（安全与性能的权衡），如果不是金融、电信等事务级别要求很高的业务，完全可以设置成transaction_isolation=READ-COMMITTED。
Repeatable-read: 这是MySQL的InnoDB引擎默认的隔离级别，它阻止查询的任何行被其他事务更改。因此，阻塞不可重复读，而不是幻读。也就是说在可重复读中，可能会出现幻读。重复读使用一种中等严格的锁定策略，以便事务中的所有查询都能看到来自相同快照(即事务启动时的数据)的数据。当拥有该级别的事务执行 UPDATE ... WHERE, DELETE ... WHERE, SELECT ... FOR UPDATE和LOCK IN SHARE MODE操作时，其他事务可能需要等待。
Read-Committed-推荐: 事务无法看到来自其他事务的未提交数据，但可以看到当前事务启动后另一个事务提交的数据。当拥有这种级别的事务执行 UPDATE ... WHERE or DELETE ... WHERE操作时，其他事务可能需要等待。但是该事务可以执行 SELECT ... FOR UPDATE, and LOCK IN SHARE MODE操作，其他事务不需要等待。
串行化（SERIALIZABLE）-极力不推荐，串行化隔离级别是最高的隔离级别，它使用了最保守的锁策略。它阻止任何其他事务插入或更改此事务读取的数据，直到该事务完成。简单的来说，就是一个事务一个事务的来执行，显然性能会很低。在这种隔离级别下，一个事务中的相同查询可以反复执行，每次查询结果是一样的。从当前事务开始执行，任何更改另一个事务提交的数据的尝试都会导致当前事务等待（阻塞）。这是SQL标准指定的默认隔离级别（注意不是MySQL）。在实践中，这种严格程度是很少需要的。
读未提交（READ-UNCOMMITTED）-它是最低的隔离级别，虽然性能最高，但也不推荐
它会读取到其他事务修改尚未提交的数据，使用此隔离级别就需要非常小心，认识到这种级别下的查询结果可能不一致或不可复制，这取决于其他事务同时在做什么。通常，具有此隔离级别的事务只执行查询，而不执行插入、更新或删除操作。
在实际环境中，应当根据是否允许出现脏读（dirty reads），不可重复读（non-repeatable reads）和幻读（phantom reads ）现象而选择相应的隔离级别。例如在大数据中，少量的数据不一致不会影响到最后的决策，这种情况下可以使用较低的隔离级别以提交性能和并发性。
如果不配的后果：

默认就是repeatable-read

配置实例：

transaction_isolation = READ-COMMITTED

11)explicit_defaults_for_timestamp

推荐设置：

1

作用：

mysql5.7默认对于timestamp字段会显示“系统当前日期”，就算你在插表时这个timestamp字段留空，它在select出来时也会显示系统日期。因此，这个值的影响范围是你在建表时导致的。
系统默认这个值是0，在0的情况下，你要让该表的timestamp字段在为null时不显示系统默认时间，你的建表必须为：create table order(o_id int ,updateed_time timestamp null default null) ;
explicit_defaults_for_timestamp 变量会直接影响表结构，也就是说explicit_defaults_for_timestamp的作用时间是在表定义的时候；你的update | insert 想通过它去改变行为已经太晚了！
因此，我推荐把这个值设为1.
如果不配的后果：

默认为0

配置实例：

explicit_defaults_for_timestamp = 1

12)join_buffer_size

推荐设置：

16M

作用：

系统默认大小为：512k，mac下默认大小为：256k，针对128GB，1万并发的mysql我推荐给到的值为：8~16M
对于JOIN KEY 有索引和二级索引，JOIN KEY 无索引mysql会使用到join_buffer_size，一般建议设置一个很小的 GLOBAL 值，完了在 SESSION 或者 QUERY 的基础上来做一个合适的调整。如果你拍脑袋给也个4g，我们有1000个并发，就是用掉了4T的内存。。。4T啊。。。你以为你是小型机。适当的去改变它确实可以带来一定的提速，但并不是说很多值越大越好，为什么我们设置成4m呢？我们假设我们的mysql所在的vm是128gb，一根这样的join（如果被用到）是4M，1万个也不过用掉40G,而根据官方说法，total加在一起产生的join_buffer_size不要超过你所在系统的50%.默认512k肯定是小了点，我们可以适当放宽，比如说：2M，在实际使用场景时我们发觉有这样的高频操作（要看高频出现的有意义的sql的执行计划，并确认该计划的：执行cost如："query_cost": "1003179606.87"，它产生的cost为：0.93个G,如果它真的很高频出现在调优sql到无法调优的程度，我们会去做set session join_buffer_size = 1024 * 1024 * 1024;这样的操作。而不是在一开始的my.cnf中去分配一个暴大的值，我们这边基于128gb，1万connection的并发来说，你给个16M不算小也不算多，我推荐给到8~16M间（这是指在一开始）。
如果不配的后果：

默认的为256k

配置实例：

join_buffer_size = 16M

13)tmp_table_size

推荐设置：

67108864

作用：

如果是128gb内存的服务器，我建议是在my.cnf中设成64M
通过设置tmp_table_size选项来增加一张临时表的大小，例如做高级GROUP BY操作生成的临时表。默认系统为32M，如果当你的临时表越来越多加在一起超过了这个值，那么mysql会在系统磁盘上创建，这个值不是越多越好，也没有一个合适的值。一开始的建议为>64M，然后在运行时我们通过以下公式来做临时调优，
show global status like 'created_tmp%';
把得到的结果中的：(Created_tmp_disk_tables / Created_tmp_tables) * 100% 如果<=25%为最佳值。注意了，在生产时热设定时一定要用类似以下算法：
set global tmp_table_size=64*1024*1024而不是set global tmp_table_size=64M。
如果不配的后果：

默认为32M

配置实例：

tmp_table_size = 67108864

14)tmpdir

这块参数可以让运维给到，放到大空间里就行了，没什么太敏感的。

15)max_allowed_packet

推荐设置：

134217728

作用：

如果你经常在应用层碰到了：Got a packet bigger than'max_allowed_packet' bytes，这时你可以使用
show variables like '%max_allowed_packet%';来查看这个值，这个值没有合适，一般如：用客户端导入数据的时候，遇到 错误代码: 1153 - Got a packet bigger than 'max_allowed_packet' bytes 终止了数据导入。这样的场景下，当MySQL客户端或mysqld服务器收到大于max_allowed_packet字节的信息包时，将发出“信息包过大”错误，并关闭连接。对于某些客户端，如果通信信息包过大，在执行查询期间，可能会遇到“丢失与MySQL服务器的连接”错误。
客户端和服务器均有自己的max_allowed_packet变量，因此，如你打算处理大的信息包，必须增加客户端和服务器上的该变量。一般情况下，服务器默认max-allowed-packet为1MB,可以通过在交换机上抓包或者是图形化分析来抓返回结果判断。一般推荐在128gb内存下设置的置为128M.也可以在运行时动态调整：set global max_allowed_packet = 128*1024*1024
如果不配的后果：

1M

配置实例：

max_allowed_packet = 134217728

16)sql_mode

不需要去设置，使用默认的，这块和性能无关。我们的中台中的sql如果碰到有sql报错，因该是在测试环境上就已经报了，它的作用是用来约束你sql的写法的，如果是一个从头开始开发的应用，我们比如说约束好都是ansi sql写法，对于一个产品，不要去做这种画蛇添足的做法。

17)interactive_timeout

推荐设置：

600

作用：

单位为s，系统默认为：28800s即8小时。如果这2个值太大，你会发觉在mysql中有大量sleep的连接，这些连接又被称为：僵尸连接，僵尸连接一多你真正要用的时候就会抛：too many connection这样的错，因此对于长久不用的连接，我们一般要使用“踢出机制”，多久对于一个活动累的sql进行踢呢？我们说如果有一个长事务，它要执行1小时，我不知道这是不是属于正常？当然如果你设了太短，说1分钟就把它踢了，还真不一定踢的对，按照我们在oracle中设置的best practice我们都会把它放到10分钟。你有一条sql连着，10分钟不用，我就把它踢了，这也算正常。但是在高并发的场景下这个timeout会缩短至3-5分钟，这就是为什么我提倡我们的非报表即时类查询需要优化到sql的运行时间不超过300ms的原因，因为在高并发场景下，超过500ms的sql都已经很夸张了。保守点我觉得可以设成10分钏，在应用端由其通过jdbc连接数据库的，做的好的应用都会在jdbc里有一个autoconnect参数，这个autoconnect参数就要和mysql中的wait_timeout来做匹配了。同时在应用端要有相应的validate sql一类的操作来keep alived。不过我更推荐使用”连接池内连接的生存周期（idleConnectionTestPeriod）”来做设置，把这个置设成 interactive_timeout：交互式连接超时时间(mysql工具、mysqldump等)
wait_timeout：非交互式连接超时时间，默认的连接mysql api程序,jdbc连接数据库等
interactive_timeout针对交互式连接，wait_timeout针对非交互式连接。所谓的交互式连接，即在mysql_real_connect()函数中使用了CLIENT_INTERACTIVE选项。
show global variables like 'wait_timeout';
1 timeout 只是针对空闲会话有影响。

2 session级别的wait_timeout继承global级别的interactive_timeout的值。而global级别的session则不受interactive_timeout的影响。

3 交互式会话的timeout时间受global级别的interactive_timeout影响。因此要修改非交互模式下的timeout，必须同时修改interactive_timeout的值。

4 非交互模式下，wait_timeout参数继承global级别的wait_timeout。

如果不配的后果：

系统默认为28800

配置实例：

interactive_timeout = 600

18)wait_timeout

同interactive_timeout，两个值都设成一样。

19)read_buffer_size

推荐设置：

4194304

作用：

这个值其实轻易是用不到的，因为，它只对2种场景的full table scan产生影响而不是所有的full table scan，同时从mysql5.6以后开始没有数据块多块读的功能,与是否设置 read_buffer_size参数无关。应用场景：

1）SELECT INTO … OUTFILE ‘fileName‘

2）When filesort is used, during merge buffers and when merged results are written to a temporary file, then writes are buffered

一般保留默认:64k，保守作法是设置在1～4M，不过它的应用场景很有限，对于互联网场景真的不太用，我推荐设成4M

如果不配的后果：

默认为64k

配置实例：

read_buffer_size = 4194304

20)read_rnd_buffer_size

推荐设置：

8388608

作用：

就是当数据块的读取需要满足一定的顺序的情况下，MySQL 就需要产生随机读取，进而使用到 read_rnd_buffer_size 参数所设置的内存缓冲区。它的默认为256k，最大可以设到2G，它会对order by关键字起作用，当order by的计划成本超出了sort_buffer_size后，mysql会产用随机读取并消耗额外的内容，很多外面的博客说它是只对myisam引擎起作用，但其实不是，该参数还真的覆盖到所有引擎，一般它的推荐设置在8-16M，我推荐8M，根据sql分析计划如果碰到高频的查询且order by的返回包体都很大，那么再在session级别去放。

如果不配的后果：

默认为256k

配置实例：

read_rnd_buffer_size = 8388608

21)sort_buffer_size

推荐设置：

4194304

作用：

每个会话执行排序操作所分配的内存大小。想要增大max_sort_length参数，需要增大sort_buffer_size参数。如果在SHOW GLOBAL STATUS输出结果中看到每秒输出的Sort_merge_passes状态参数很大，可以考虑增大sort_buffer_size这个值来提高ORDER BY 和 GROUP BY的处理速度。建议设置为1~4MB。当个别会话需要执行大的排序操作时，在会话级别增大这个参数。所谓会话级别，我举个例子，你拍脑袋一下，说我设个32M,你所它乘10,000请求，这得多大内存。另外，千万要注意，在mysql内存，当你的sort_buffer_size在超过2K时在底层使用的是mmap()的c函数去做内存分配的，而不是malloc()，做过c的都知道mmap()是一个矢量单位，因此它会付出性能的影响，能影响多少呢？单条sql影响值在30%。

如果不配的后果：

默认值为1M

配置实例：

sort_buffer_size =4194304

22)innodb_page_size

推荐设置：

8192

作用：

这个值可要小心，一般它在设置后就不能轻易改了，一般来说我们都认为，值越大越好，不是的， 这个值它的原理是这样的：size越小，内存划分粒度越大，使用率越高，但是会有其他问题，就是限制了索引字段还有整行的大小。innodb引擎读取内存还有更新都是一页一页更新的，这个innodb_page_size决定了，一个基本页的大小。常用B+Tree索引，B+树是为磁盘及其他存储辅助设备而设计一种平衡查找树（不是二叉树）。B+树中，所有记录的节点按大小顺序存放在同一层的叶子节点中，各叶子节点用指针进行连接。MySQL将每个叶子节点的大小设置为一个页的整数倍，利用磁盘的预读机制，能有效减少磁盘I/O次数，提高查询效率。如果一个行数据，超过了一页的一半，那么一个页只能容纳一条记录，这样B+Tree在不理想的情况下就变成了双向链表。我们拿白话来说就是：你越大，空间利用率更高，但是越小呢越有助于性能但是这边一定一定有一个“但是”，但是小到一定的量反而性能不好，为什么呢？太大上面我已经举例了，太小。。。mysql的页间的check point太频繁。怎么样做才能达到一个合理值呢？
这个我们是在全真生产环境、全数据量下用测试工具去对4k,8k,16k三种场景压测得到的吞吐量即tps来做观察的，我这边可以给出一个推荐值，以单表超1000w条数据基于中台1.1的数据库结果（每个表都超1000w），我们在设置该值为：8K时，它的吞吐达到最优。
如果不配的后果：

32位下默认为8192

64位下默认为16384

配置实例：

innodb_page_size = 8192

23)innodb_buffer_pool_size

推荐设置：

72G

作用：

这个值和innodb_buffer_pool_instances相辅相成。在32位机器下，innodb_buffer_pool_instances一般为1，在64位机器上，这个值为8-64.

pool_instances其实为cpu核数，它的作用是：

1）对于缓冲池在数千兆字节范围内的系统，通过减少争用不同线程对缓存页面进行读写的争用，将缓冲池划分为多个单独的实例可以提高并发性。

2）使用散列函数将存储在缓冲池中或从缓冲池读取的每个页面随机分配给其中一个缓冲池实例。每个缓冲池管理自己的空闲列表， 刷新列表， LRU和连接到缓冲池的所有其他数据结构，并受其自己的缓冲池互斥量保护。

innodb_buffer_pool_size的设置需要为pool_instance的整数倍。

网上很多说innodb_buffer_pool_size为系统的70%，这是错的！因为你真的设了70%你的swap空间会被挤压，你不要忘了你还有os，上面还可能有监控agent端。一旦swap空间被挤压后你的mysql反面严重拖慢读写。

此处强烈建议设成内存的20%-65%间（独立的mysql服务器），为什么有一个20%呢？对于<4gb的mysql用服务器来说按照20%系统内存来设置。由于我们是128gb的内存，此处我建议使用72G,如果内存超过128gb，一般我们会把pool instance设成16个，每个开启10g左右的buffer_pool_size，对于256gb内存的服务器来说我们可以这样设。

如果不配的后果：

默认为64

配置实例：

innodb_buffer_pool_size = 72G

24)innodb_buffer_pool_instances = 8

这个参数同innodb_buffer_pool_size一起讲解了。

25)innodb_buffer_pool_load_at_startup

推荐设置：

0

作用：

这两个参数几乎没人用一般dba也不曾听说过，它是什么意思呢？Mysql在第一次（重启）时，它的buffer_pool_size中是空的，随着mysql运行时间1-2小时后，它的buffer_pool_size里开始被塞入东西，它分为old block与new block，而此时mysql性能开始一点点读写效率上去了，那是因为在buffer_pool_size没有放入东西时，mysql很多读写发生在硬盘上，从硬盘到内存的加载过程是一个比较漫长和耗时的过程，因此我们往往会设一个startup=1以加快这个“预热”过程，它与参数shutdown配合使用，即相当于把上次使用的innot_db_buffer_pool里的东西在启动时先做一次加载，以加快mysql的性能。它会在innodb的数据目录中生成一个文件：ib_buffer_pool。高度注意：加入了startup和shutdown=1时，mysql的启动过程会比较慢，如果你上次的dump出的buffer_pool里的东西有50多g那么mysql启动时的加载过程会变得比较慢。这个值很多人使用默认的0（不开启），它的影响就是你在mysql重启后，一开始你的系统读写性能不如在你系统运行了2-4小时（视db读写而定）反而它的读写性能变好了。不设使用默认值（0）。

如果不配的后果：

不配的话系统默认为0

配置实例：

innodb_buffer_pool_load_at_startup = 0

26)innodb_buffer_pool_dump_at_shutdown

同上面的startup参数以及解说

27)innodb_lru_scan_depth

推荐设置：

2000

作用：

innodb_io_capactiy 在sas 15000转的下配置800就可以了，在ssd下面配置2000以上。

可使用默认配置。即不设。

如果不配的后果：

默认为200，db吞吐量上不去。

配置实例：

innodb_lru_scan_depth = 2000

28)innodb_lock_wait_timeout

推荐设置：

60

作用：

我们一般会碰到，mysql innodb_lock_wait_timeout这个错，这个错是慢sql导致，它代表的是慢sql的事务锁超过了mysql锁超时的设置了。默认这个值为：50s，这个值是可以动态改变的，我不建议去改这个值，因为一个sql能达50s这得多夸张？

动态改变命令如下：

SHOW GLOBAL VARIABLES LIKE 'innodb_lock_wait_timeout';

SET GLOBAL innodb_lock_wait_timeout=500;

SHOW GLOBAL VARIABLES LIKE 'innodb_lock_wait_timeout';

把它设成60s足够了。

如果不配的后果：

默认为50s

配置实例：

innodb_lock_wait_timeout = 60

29)innodb_io_capacity_max

推荐设置：

8000

作用：

这个值很重要，它对读无效，对写很有决定意义。
它会直接决定mysql的tps（吞吐性能），这边给出参考：sata/sas硬盘这个值在200. sas raid10: 2000，ssd硬盘：8000， fusion-io（闪存卡）：25,000-50,000
本调优基于的是ssd，此值设置为8000，笔者上一家公司互联网金融是把一整个mysql扔到了闪存卡里的，因此设置的值为：50,000.
需要根据paas或者是ias的vm的硬盘性号来定
如果不配的后果：

默认为200，系统吞吐上不去。

配置实例：

innodb_io_capacity_max = 8000

30)innodb_io_capacity

它是io_capacity_max的一半，同样，它对读无效对写有决定意义。

配置实例：

innodb_io_capacity_max = 4000

31)innodb_flush_method

推荐设置：

O_DIRECT

作用：

推荐使用O_DIRECT。让我们一起来理解一下，它有3种模式：

1）fdatasync，上面最常提到的fsync(int fd)函数，该函数作用是flush时将与fd文件描述符所指文件有关的buffer刷写到磁盘，并且flush完元数据信息(比如修改日期、创建日期等)才算flush成功。它对磁盘的io读写会很频繁

2）O_DIRECT则表示我们的write操作是从mysql innodb buffer里直接向磁盘上写，它会充分利用缓存

3）_DIRECT模式的free内存下降比较慢，因为它是据文件的写入操作是直接从mysql innodb buffer到磁盘的，并不用通过操作系统的缓冲，而真正的完成也是在flush这步,日志还是要经过OS缓冲，O_DIRECT在SQL吞吐能力上较好。

如果不配的后果：

它的默认值为fdatasync。

配置实例：

innodb_flush_method = O_DIRECT

32)innodb_file_format

推荐设置：

Barracuda

作用：

推荐使用Barracuda模式

它是启用表压缩用的，如：

CREATE TABLE `test_1` (
`x` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;
建完后可以通过：show table status like 'test_1';来查看是否已经启用了表压缩了。

innodb_file_format有这么几种模式：

Antelope-羚羊模式，支持Redundant（冗余）、Compact（紧凑）模式

Barracuda-梭子鱼,是InnoDB Plugin支持的文件格式，在原来的基础上新增了两种数据表格式的支持：Dynamic 和 Compressed

因此我推荐使用：Barracude模式，因为它可以兼容其它数据模式。

它也可以在运行时动态改变：SET GLOBAL innodb_file_format_max = barracuda;

如果不配的后果：

它默认使用的是叫“联合模式”，即不是棱子鱼也不是羚羊。

配置实例：

innodb_file_format = Barracuda

33)innodb_file_format_max

这个参数必须和innodb_file_format参数一致，一定记住，要不然不生效。

34)innodb_log_group_home_dir = /redolog/

这个就不用解释了，太傻瓜了。这种路径的都可由运维决定，记得挂在大磁盘下。

35)innodb_undo_directory = /undolog/

这个就不用解释了，太傻瓜了。这种路径的都可由运维决定，记得挂在大磁盘下。

36)innodb_undo_logs = 128

推荐设置：

128

作用：

指定回滚段的个数（早期版本该参数名字是innodb_rollback_segments），默认128个。每个回滚段可同时支持1024个在线事务。这些回滚段会平均分布到各个undo表空间中。该变量可以动态调整，但是物理上的回滚段不会减少，只是会控制用到的回滚段的个数。现在SSD非常普及。innodb_undo_logs可以默认为128不变。

如果不配的后果：

默认就是128

配置实例：

innodb_undo_logs = 128

37)innodb_undo_tablespaces

推荐设置：

3

作用：

推荐：3，默认为3

定单独存放的undo表空间个数，例如如果设置为3，则undo表空间为undo001、undo002、undo003，每个文件初始大小默认为10M。该参数我们推荐设置为大于等于3，更多的碎片文件会影响磁盘的io性能，而不够碎片同样影响mysql的吞吐率，在ssd上一般最佳的配置在3.如果只有1个undo表空间，那么整个系统在此过程中将处于不可用状态。为了尽可能降低truncate对系统的影响，建议将该参数最少设置为3；

如果不配的后果：

默认为：3

配置实例：

innodb_undo_tablespaces = 3

38)innodb_flush_neighbors

推荐设置：

推荐为：0

作用：

这个参数很要紧，目前在ssd盛行的情况下我们都把它设为0（不开启），如果你设置成了1即开启（默认状态）InnoDB就会刷新一个extent中的所有页面，因为SSD在随机IO上没有额外负载，所以不需要启用该特性，开启了反而多此一句。下面给出一段mysql5.7源码编译前程序员看的readme里的一句话：

This new default changes MySQL to cater for SSDs and fast storage devices by default. We expect that for the majority of users, this will result in a small performance gain. Users who are using slower hard drives may see a performance loss, and are encouraged to revert to the previous defaults by setting innodb_flush_neighbors=1.

如果不配的后果：

它的默认是1，不是0.这个参数对机性硬盘来说很有效，可以减少随机io，增加性能。如果是ssd类磁盘，建议设置为0，可以更快的刷新脏页。如果你把它设为1同时又是ssd那就显得没必要了。这边普及一下小知识，如果你装过8.0，你可以去看一下，8.0已经把这个默认值设为0了。

配置实例：

innodb_flush_neighbors = 0

39)innodb_log_file_size

推荐设置：

第1步：show engine innodb status;

得到：

Log sequence number 2944118284

Log flushed up to 2944118283

Last checkpoint at 2724318261

第2步：设innodb_log_file_size$=log Log sequence number-last checkpoint at=select (2944118284-2724318261)/1024/1024;=209M

第3步：设真正的innodb_log_file_size<=(innodb_log_files_in_group*innodb_log_file_size)*0.75,innodb_log_files_in_group为2（默认），得：

第4步：select 209/(2*0.75);=139.33即：139m，此时可把这个值设为140M

作用：

这个值的默认为5M，是远远不够的，在安装完mysql时需要尽快的修改这个值。

如果对 Innodb 数据表有大量的写入操作，那么选择合适的 innodb_log_file_size 值对提升MySQL性能很重要。然而设置太大了，就会增加恢复的时间，因此在MySQL崩溃或者突然断电等情况会令MySQL服务器花很长时间来恢复。

而这个值是没有一个绝对的概念的，MySQL的InnoDB 存储引擎使用一个指定大小的Redo log空间（一个环形的数据结构）。Redo log的空间通过innodb_log_file_size和innodb_log_files_in_group（默认2）参数来调节。将这俩参数相乘即可得到总的可用Redo log 空间。尽管技术上并不关心你是通过innodb_log_file_size还是innodb_log_files_in_group来调整Redo log空间，不过多数情况下还是通过innodb_log_file_size 来调节。为InnoDB引擎设置合适的Redo log空间对于写敏感的工作负载来说是非常重要的。然而，这项工作是要做出权衡的。你配置的Redo空间越大，InnoDB就能更好的优化写操作；然而，增大Redo空间也意味着更长的恢复时间当出现崩溃或掉电等意外时。我们是通过“测试”得到，怎么测试下面给出方法论：一般情况下我们可以按照每1GB的Redo log的恢复时间大约在5分钟左右来估算。如果恢复时间对于你的使用环境来说很重要，我建议你做一些模拟测试，在正常工作负载下（预热完毕后）模拟系统崩溃，来评估更准确的恢复时间。你可以安装 Percona Monitoring and Management，在该pmm的percona monitoring and management图表中，主要看：

1）Uncheckpointed Bytes ，如果它已经非常接近 Max Checkpoint Age，那么你几乎可以确定当前的 innodb_log_file_size 值因为太小已经某种程度上限制了系统性能。增加该值可以较为显著的提升系统性能。

2）Uncheckpointed Bytes 远小于 Max Checkpoint Age，这种情况下再增加 innodb_log_file_size 就不会有明显性能提升。

在调整完log_file_size后我们再到pmm中去看：Redo Log空间指标，比如说我们看到了1小时内有60g数据被写入日志文件，差不多就是每10分钟会有10g数据在进行“写日志“，我们需要牢牢记得，这个”写日日土已“的时间拖得越久、出现的频次越少就越有助于mysql的innodb的性能。因此这个值没有绝对推荐。如果你没有pmm，那么我们来人肉算，在上面我已经给出了人肉算的详细例子！

如果不配的后果：

默认是5M，这是肯定不够的。

配置实例：

innodb_log_file_size = 140M

40)innodb_log_buffer_size

推荐设置：

16777216

作用：

对于较小的innodb_buffer_pool_size，我们会把它设成和innodb_buffer_pool_size一样。
而当超过4gb的innodb_buffer_pool_size时，我们的建议是把它切的够碎，这是mysql5.7里新带的特性，它的默认在8m，但是对于大量有事务操作的mysql我们推荐在写操作库上设置：16m
此参数确定些日志文件所用的内存大小，以M为单位。缓冲区更大能提高性能，但意外的故障将会丢失数据.官方的方档建议设置为1－8M之间！
如果不配的后果：

默认是8M

配置实例：

innodb_log_buffer_size = 16777216

41)innodb_purge_threads

推荐设置：

0

作用：

这个参数轻易不用的，我推荐它设为：0，为什么呢？这个参数是和innodb_force_recovery关联起来的，只有当数据库崩溃后重启时才会临时去设的。它的使用场景如下：

mysql断电，重启后无效，起不来。所以我们根据innodb_force_recovery的参数：

1. (SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。

2. (SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。

3. (SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。

4. (SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。

5. (SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。

6. (SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。

我们在my.cnf中如下设置：

innodb_force_recovery = 6

innodb_purge_threads = 0

记住，一旦当innodb_force_recovery>2时，要把innodb_purge_threads设成0.

如果不配的后果：

默认不要去设，可以不配，出现了问题在recover需要时再去改。

配置实例：

innodb_purge_threads = 0

42)innodb_large_prefix

推荐设置：

1

作用：

如果你的客户端和服务端的字符集设成了utf8mb4，那么我们需要把这个开关开启，为什么呢？mysql在5.6之前一直都是单列索引限制767，起因是256×3-1。这个3是字符最大占用空间（utf8）。但是在5.6以后，开始支持4个字节的uutf8。255×4>767, 于是增加了这个参数。这个参数默认值是OFF。当改为ON时，允许列索引最大达到3072.

在mysql5.6中这个开关叫on, off。而在5.7中叫0和1，由于我们前面设置了utf8mb4，因此这边我们必须把这个参数开启。

如果不配的后果：

不配会有问题，特别是索引会无效、或者不是走最优计划，如果你的字符集是utf8mb4，那么这个值必开启。

配置实例：

innodb_large_prefix = 1

43)innodb_thread_concurrency

推荐设置：

装mysql的服务器的cpu的核数

作用：

如：64核cpu，那么推荐：64（<=cpu核数）

如果一个工作负载中，并发用户线程的数量小于等于64，建议设置innodb_thread_concurrency=0;而事实上我们的系统是处于大并发大事务的情况下的，怎么来算这个值？建议是先设置为128，然后我们不断的降这个值，直到发现能够提供最佳性能的线程数。为了安全起间我们会把它设成和cpu一样大小。

如果不配的后果：

默认在64位下会是8

配置实例：

innodb_thread_concurrency = 64

44)innodb_print_all_deadlocks

推荐设置：

1

作用：

推荐：1

当mysql 数据库发生死锁时， innodb status 里面会记录最后一次死锁的相关信息，但mysql 错误日志里面不会记录死锁相关信息，要想记录，启动 innodb_print_all_deadlocks 参数 。

如果不配的后果：

不会记录该信息。

配置实例：

innodb_print_all_deadlocks = 1

45)innodb_strict_mode

推荐设置：

1

作用：

必须开启，没得选择，1，为什么？

从MySQL5.5.X版本开始，你可以开启InnoDB严格检查模式，尤其采用了页数据压缩功能后，最好是开启该功能。开启此功能后，当创建表（CREATE TABLE）、更改表（ALTER TABLE）和创建索引（CREATE INDEX）语句时，如果写法有错误，不会有警告信息，而是直接抛出错误，这样就可直接将问题扼杀在摇篮里。

如果不配的后果：

如果不配碰到开发或者非专业的dba会把旧ddl语句生效在5.7内，另外一个问题就是ddl语句出错时报错不明显，这会影响到“主从复制”，至于dll为什么会影响到主从复制，我们后面会在“slave_skip_errors = ddl_exist_errors”中详细解说。

配置实例：

innodb_strict_mode = 1

46)log_error

error log所在位置，这个不用多讲，可以和mysql log放在同一路径下，文件名能够和其它log区分开来。

47)slow_query_log

建议开启

48)slow_query_log_file

慢sql所在位置，这个不用多讲，可以和mysql log放在同一路径下，文件名能够和其它log区分开来。

49)log_queries_not_using_indexes=1

强烈建议开启成1.

50)log_slow_admin_statements = 1

强烈建议开启成1.

51)log_slow_slave_statements = 1

强烈建议开启成1.

52)log_throttle_queries_not_using_indexes

推荐设置：

在一开始上线后的初期我们会开成30～50条。随着性能逐渐优化我们会把这个数量开成10.

作用：

上线前一段时间会不太稳定，我们发生过近几十条sql没有走index

如果不配的后果：

不配不开启，建议开启。

配置实例：

log_throttle_queries_not_using_indexes = 50

53)expire_logs_days

推荐设置：

30

作用：

这个值不能太大，因为你不是土豪，不能让binlog无限占用你的磁盘空间，记得这个值一旦设小，你需要做好binlog备份策略，30这个值就是30天，前提是你的binlog的备份做的有效且不占用mysql的磁盘空间。

如果不配的后果：

默认是0，即永不过期。

配置实例：

expire_logs_days = 30

54)long_query_time

推荐设置：

10

作用：

默认为10秒种，即一切>=10s的sql都会被记录。我建议在开始刚上线期设成10（用默认值），越着慢sql调优越来越好，可以把这个值设成1.因为秒数越低，记录的sql越多，记录越多，也会造成mysql过慢。另外不能完全依赖于mysql的慢sql log，而是应该布署druid sql实时查看器或者是apm或者是专业的慢sql实时查询器。

如果不配的后果：

默认为10

配置实例：

long_query_time = 10

55)min_examined_row_limit

推荐设置：

100

作用：

这个值配合着慢查询sql记录用，指定为少于该值的行的查询就算慢sql不被记录成”慢sql日志“。

如果不配的后果：

不开启的话以慢sql的long_query_time为优先规则。

配置实例：

min_examined_row_limit = 100

56)master_info_repository

推荐设置：

TABLE

作用：

主从复制时用，推荐TABLE.
从机保存主节点信息方式，设成file时 会生成master.info 和 relay-log.info2个文件，设成table，信息就会存在mysql.master_slave_info表中。不管是设置的哪种值，都不要移动或者编辑相关的文件和表。
如果不配的后果：

不配的话默认存成file格式。

配置实例：

master_info_repository = TABLE

57)relay_log_info_repository

推荐设置：

TABLE

作用：

主从复制时用，推荐TABLE.

这个参数和上面的master_info_repository必须保持一致，要不然mysql实例启不起来。

不过需要注意的是，这几个table默认用的是myIsAM引擎，要开启成TABLE模式的话一定记得把这两个表的引擎改成innodb

alter table slave_master_info engine=innodb;
alter table slave_relay_log_info engine=innodb;
alter table slave_worker_info engine=innodb;
如果不配的后果：

这个参数和上面的master_info_repository必须保持一致，要不然mysql实例启不起来

配置实例：

relay_log_info_repository = TABLE

58)log_bin = bin.log

主从复制时用，主从复制下的bin.log日志所在文件夹。

59)sync_binlog

推荐设置：

1

作用：

主从复制时用，这个值是要看业务的，它可以有0，1，非零共3种设置方式。

1）0-代表mysql不控制写binlog的时间，由file system自由去控制，此时的mysql的并发性达到最好，但是一旦系统崩溃你会丢失很多还会写入binlog的数据（比如说你正在删数据和更新数据）

2）1-最安全，你最多丢掉一个事务或者是一条语句，但是此时它的性能很差，此参数设为0或者是1之间的性能能差4～5倍。

3）如果你用的是万兆光纤高速磁盘像或者是ssd同时data和binlog都放在一个目录下的同时你要为了安全可以开启成1.

如果不配的后果：

默认为0

配置实例：

sync_binlog = 1

60)gtid_mode

推荐设置：

on

作用：

主从复制时用，推荐开启成on，它的用处就是允许你在从库上进行”备份“，从库上在进行备份时它能够获取主库的binlog位点。

该参数也可以动态在线设定。如果你要在线运行时设定，在my.cnf文件中必须把它设成on。在开启该参数时，log-bin和log-slave-updates也必须开启，否则MySQL Server拒绝启动，当开启GTID模式时，集群中的全部MySQL Server必须同时配置gtid_mod = ON，否则无法同步。

如果不配的后果：

默认为off

配置实例：

gtid_mode = on

61)enforce_gtid_consistency

推荐设置：

1

作用：

主从复制时用，见gtid_mode，这是牵连参数，随着gtid_mode的开启一起开启。

如果不配的后果：

必须跟着gtid_mode一起开启，要不然mysql实例起不来。

配置实例：

enforce_gtid_consistency = 1

62)log_slave_updates

推荐设置：

它只要标注在my.cnf里就代表起作用了。

作用：

主从复制时用，见gtid_mode，这是牵连参数，随着gtid_mode的开启一起开启。它只要标注在这就可以了，代表开启，否则也就不要有这一行了。

如果不配的后果：

它是牵连参数，随着gtid_mode的开启一起开启。

配置实例：

log_slave_updates

63)binlog_format

推荐设置：

row

作用：

主从复制时用，mysql5.7有3种bin log模式：

1. STATEMENT：历史悠久，技术成熟,binlog文件较小,binlog中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况。binlog可以用于实时的还原，而不仅仅用于复制主从版本可以不一样，从服务器版本可以比主服务器版本高。缺点是：不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候。调用具有不确定因素的 UDF 时复制也可能出问题，使用以下函数的语句也无法被复制：

* LOAD_FILE()

* UUID()

* USER()

* FOUND_ROWS()

* SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)

2.同时，INSERT ... SELECT 会产生比 ROW 更多的行级锁，复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时，需要比 RBR 请求更多的行级锁

3.对于有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 语句会阻塞其他 INSERT 语句，对于一些复杂的语句，在从服务器上的耗资源情况会更严重，而 RBR 模式下，只会对那个发生变化的记录产生影响，存储函数(不是存储过程)在被调用的同时也会执行一次 NOW() 函数，这个可以说是坏事也可能是好事，确定了的 UDF 也需要在从服务器上执行，数据表必须几乎和主服务器保持一致才行，否则可能会导致复制出错，执行复杂语句如果出错的话，会消耗更多资源。

2. ROW：任何情况都可以被复制，这对复制来说是最安全可靠的，和其他大多数数据库系统的复制技术一样。多数情况下，从服务器上的表如果有主键的话，复制就会快了很多。复制以下几种语句时的行锁更少：

* INSERT ... SELECT

* 包含 AUTO_INCREMENT 字段的 INSERT

* 没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句

执行 INSERT，UPDATE，DELETE 语句时锁更少，从服务器上采用多线程来执行复制成为可能，它的缺点是：inlog 大了很多，复杂的回滚时 binlog 中会包含大量的数据，主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而 SBR 只会写一次，这会导致频繁发生 binlog 的并发写问题，UDF 产生的大 BLOB 值会导致复制变慢，无法从 binlog 中看到都复制了写什么语句。

从安全和稳定性的缩合考虑上来说我们选择ROW模式。

3. 混合式-不推荐

如果不配的后果：

5.7.6之前默认为STATEMENT模式。MySQL 5.7.7之后默认为ROW模式

配置实例：

binlog_format = row

64)relay_log

主从复制用，定义relay_log的位置和名称，如果值为空，则默认位置在数据文件的目录（datadir），文件名为host_name-relay-bin.nnnnnn（By default, relay log file names have the form host_name-relay-bin.nnnnnn in the data directory）

65)relay_log_recovery

推荐设置：

1

作用：

主从复制用，推荐值为1，建议打开。
当slave从库宕机后，假如relay-log损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的relay-log，并且重新从master上获取日志，这样就保证了relay-log的完整性。默认情况下该功能是关闭的，将relay_log_recovery的值设置为 1时，可在slave从库上开启该功能，建议开启。
如果不配的后果：

默认情况下是关闭的。

配置实例：

relay_log_recovery = 1

66)slave_skip_errors

推荐设置：

ddl_exist_errors

作用：

主从复制用，推荐值：ddl_exist_errors。理论上我们不应该设置这个值的。即它在my.cnf文件中应该是消失的或者是这样的表示的：

#slave_skip_errors = ddl_exist_errors

但是有时我们的一些表（特别是不熟悉mysql的一些开发）真的是用的是mysql5.6旧版的建表语句，这个问题在平时单机模式下很难发现，一旦主从结构一上后，在5.7上真的是有一定机率（有10%-20%的机率）碰到ddl语句是旧版mysql而运行在mysql5.7上，这时在主从复制时会抛一个无法主从复制的错，那么这时我们需要抓数据，表已经建好了，这个影响不大、微乎其微，因此我们可以把它设成”忽略“。这个是本人的吐血经验，为什么要提这个梗。。。你们懂的。

如果不配的后果：

如果因为建表语句和mysql5.7有冲突时在单实例模式下mysql运行时不会发现，在主从复制时如果没有设跳过值，一旦发生，会影响主从复制，表现就是：主从复制失败。

配置实例：

slave_skip_errors = ddl_exist_errors

67)innodb_buffer_pool_dump_pct

推荐设置：

25~40

作用：

锦上添花的值，非必要，这边给出一些best practice:
通常来说我们会设成25%。对于大并发前提下我们会使用40这个值，这个值越大，mysql启动时间越长。它是你的innodb_buffer_pool_size的百分比！
MySQL默认在InnoDB缓冲池（而不是整个缓冲池）中仅保留最频繁访问页的25%。请注意，这个变量是基于内存中的实际数据量，而不是缓冲池的大小。例如，如果有100GB的缓冲池，但只有10GB的数据，默认只有10GB的25%（即2.5GB）数据保存在内存中。
在多数使用场景下，合理的选择是：保留最有用的数据页，比加载所有的页(很多页可能在后续的工作中并没有访问到)在缓冲池中要更快。你可以更改innodb_buffer_pool_dump_pct变量的值。
如果不配的后果：

不配的话不生效。

配置实例：

innodb_buffer_pool_dump_pct=25

68)innodb_page_cleaners=8

这值一般会在主从延迟的情况下会去设，它的值最好是=innodb_buffer_pool_instance的值，它就是cpu的核数。

69)innodb_undo_log_truncate

推荐设置：

1

作用：

建议开启，设为1

innodb_undo_log_truncate参数设置为1，即开启在线回收（收缩）undo log日志文件，支持动态设置。

如果不配的后果：

不配的话是不生效的。

配置实例：

innodb_undo_log_truncate=1

70)innodb_max_undo_log_size

推荐设置：

推荐在默认值的2倍（默认为1GB）

作用：

推荐在默认值的2倍（默认为1GB），一般我们不会轻易去设它。

这个值和innodb_undo_tablespaces、innodb_undo_logs以及innodb_purge_rseg_truncate_frequency有关，这4个值是互相有牵连的。

1）innodb_undo_tablespaces必须为>=3

2）innodb_undo_logs必须开启

3）innodb_purge_rseg_truncate_frequence必须开启

如果不配的后果：

系统按照1GB来计算。

配置实例：

innodb_max_undo_log_size=2G

71)innodb_purge_rseg_truncate_frequency

推荐设置：

128

作用：

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

如果不配的后果：

系统默认按照：128去设定。

配置实例：

innodb_purge_rseg_truncate_frequency=128

72)binlog_gtid_simple_recovery

推荐设置：

建议开启

作用：

前提是你的mysql必须>5.7.6，否则要设为关闭。

这个参数控制了当mysql启动或重启时，mysql在搜寻GTIDs时是如何迭代使用binlog文件的。

这个选项设置为真，会提升mysql执行恢复的性能。因为这样mysql-server启动和binlog日志清理更快。该参数为真时，mysql-server只需打开最老的和最新的这2个binlog文件。

如果不配的后果：

默认为0

配置实例：

binlog_gtid_simple_recovery=1

73)log_timestamps

推荐设置：

system

作用：

推荐使用:system

这个参数主要是控制错误日志、慢查询日志等日志中的显示时间。但它不会影响查询日志和慢日志写到表 (mysql.general_log, mysql.slow_log) 中的显示时间，此参数是全局的，可以动态修改。

如果不配的后果：

默认值为:UTC

配置实例：

log_timestamps=system

74)transaction_write_set_extraction

推荐设置：

这个值不需要去设，因为你用的不是mysql8.0，在5.7.6版以后这个制不是很成熟，如果要开启一般会使用：XXHASH64.

作用：

这个值是基于group(并行）复制用的，推荐值为：XXHASH64，如果没有开启基于group（并行）的复制千万不要去设这个参数，设都不用去设，保持默认就可以了。

如果不配的后果：

默认为off状态，即不生效。

配置实例：

transaction_write_set_extraction = OFF
transaction_write_set_extraction = XXHASH64
transaction_write_set_extraction = MURMUR32
75)show_compatibility_56

推荐设置：

on

作用：

推荐打开。这个参数是兼容mysql5.6版的INFORMATION_SCHEMA.GLOBAL_STATUS相关功能的，它有利于从5.6到5.7的过渡时非mysql专职dba但是懂mysql的运维用的。

如果不配的后果：

默认是off。相当于严格模式。

配置实例：

show_compatibility_56=on

至此，本文完，一共介绍了mysql5.7性能提升的75种方法和详细解释，希望对大家有所帮助！

参考文献：blog.csdn.net/lifetragedy/article/details/105944790 收起阅读 »

简介： Docker是什么？ Docker是一个虚拟环境容器，可以将你的开发环境、代码、配置文件等一并打包到这个容器中，并发布和应用到任意平台中。比如，你在本地用Python开发网站后台，开发测试完成后，就可以将Python3及其依赖包、Flask及其各种插件、Mysql、Nginx等打包到一个容器中，然后部署到任意你想部署到的环境。

原文链接

Docker的三个概念

1.镜像（Image）：类似于虚拟机中的镜像，是一个包含有文件系统的面向Docker引擎的只读模板。任何应用程序运行都需要环境，而镜像就是用来提供这种运行环境的。例如一个Ubuntu镜像就是一个包含 Ubuntu操作系统环境的模板，同理在该镜像上装上Apache软件，就可以称为Apache镜像。

2.容器（Container）：类似于一个轻量级的沙盒，可以将其看作一个极简的Linux系统环境（包括root权限、进程空间、用户空间和网络空间等），以及运行在其中的应用程序。Docker引擎利用容器来运行、隔离各个应用。容器是镜像创建的应用实例，可以创建、启动、停止、删除容器，各个容器之间是是相互隔离的，互不影响。注意：镜像本身是只读的，容器从镜像启动时，Docker在镜像的上层创建一个可写层，镜像本身不变。

3.仓库（Repository）：类似于代码仓库，这里是镜像仓库，是Docker用来集中存放镜像文件的地方。注意与注册服务器（Registry）的区别：注册服务器是存放仓库的地方，一般会有多个仓库；而仓库是存放镜像的地方，一般每个仓库存放一类镜像，每个镜像利用tag进行区分，比如Ubuntu仓库存放有多个版本（12.04、14.04等）的Ubuntu镜像。

Docker的安装和卸载

Docker可以安装在Windows、Linux、Mac等各个平台上。具体可以查看文档Install Docker。安装完成之后，可以查看Docker的版本信息：

[root@xxx ~]# docker version

Client:

 Version:      1.12.3

 API version:  1.24

 Go version:   go1.6.3

 Git commit:   6b644ec

 Built:

 OS/Arch:      linux/amd64



Server:

 Version:      1.12.3

 API version:  1.24

 Go version:   go1.6.3

 Git commit:   6b644ec

 Built:

 OS/Arch:      linux/amd64

查看Docker的帮助信息：# docker --help。各种命令的用法也不再赘述，后边用到哪些命令时会作出一定的解释。

Docker中关于镜像的基本操作

安装完Docker引擎之后，就可以对镜像进行基本的操作了。

我们从官方注册服务器（https://hub.docker.com）的仓库中pull下CentOS的镜像，前边说过，每个仓库会有多个镜像，用tag标示，如果不加tag，默认使用latest镜像：

[root@xxx ~]# docker search centos    # 查看centos镜像是否存在

[root@xxx ~]# docker pull centos    # 利用pull命令获取镜像

Using default tag: latest

latest: Pulling from library/centos

08d48e6f1cff: Pull complete

Digest: sha256:b2f9d1c0ff5f87a4743104d099a3d561002ac500db1b9bfa02a783a46e0d366c

Status: Downloaded newer image for centos:latest



[root@xxx ~]# docker images    # 查看当前系统中的images信息

REPOSITORY      TAG            IMAGE ID       CREATED        SIZE

centos          latest         0584b3d2cf6d   9 days ago     196.5 MB

以上是下载一个已有镜像，此外有两种方法可以帮助你新建自有镜像。

（1）利用镜像启动一个容器后进行修改 ==> 利用commit提交更新后的副本

[root@xxx ~]# docker run -it centos:latest /bin/bash    # 启动一个容器

[root@72f1a8a0e394 /]#    # 这里命令行形式变了，表示已经进入了一个新环境

[root@72f1a8a0e394 /]# git --version    # 此时的容器中没有git

bash: git: command not found

[root@72f1a8a0e394 /]# yum install git    # 利用yum安装git

......

[root@72f1a8a0e394 /]# git --version   # 此时的容器中已经装有git了

git version 1.8.3.1

此时利用exit退出该容器，然后查看docker中运行的程序（容器）：

[root@xxx ~]# docker ps -a

CONTAINER ID  IMAGE    COMMAND      CREATED   STATUS   PORTS    NAMES

72f1a8a0e394  centos:latest "/bin/bash"  9 minutes ago   Exited (0) 3 minutes ago      angry_hodgkin

这里将容器转化为一个镜像，即执行commit操作，完成后可使用docker images查看：

[root@xxx ~]# docker commit -m "centos with git" -a "qixianhu" 72f1a8a0e394 xianhu/centos:git



[root@xxx ~]# docker images

REPOSITORY       TAG    IMAGE ID         CREATED             SIZE

xianhu/centos    git    52166e4475ed     5 seconds ago       358.1 MB

centos           latest 0584b3d2cf6d     9 days ago          196.5 MB

其中，-m指定说明信息；-a指定用户信息；72f1a8a0e394代表容器的id；xianhu/centos:git指定目标镜像的用户名、仓库名和 tag 信息。注意这里的用户名xianhu，后边会用到。

此时Docker引擎中就有了我们新建的镜像xianhu/centos:git，此镜像和原有的CentOS镜像区别在于多了个Git工具。此时我们利用新镜像创建的容器，本身就自带git了。

[root@xxx ~]# docker run -it xianhu/centos:git /bin/bash

[root@520afc596c51 /]# git --version

git version 1.8.3.1

利用exit退出容器。注意此时Docker引擎中就有了两个容器，可使用docker ps -a查看。

（2）利用Dockerfile创建镜像

Dockerfile可以理解为一种配置文件，用来告诉docker build命令应该执行哪些操作。一个简易的Dockerfile文件如下所示，官方说明：Dockerfile reference：

# 说明该镜像以哪个镜像为基础

FROM centos:latest



# 构建者的基本信息

MAINTAINER xianhu



# 在build这个镜像时执行的操作

RUN yum update

RUN yum install -y git



# 拷贝本地文件到镜像中

COPY ./* /usr/share/gitdir/

有了Dockerfile之后，就可以利用build命令构建镜像了：

[root@xxx ~]# docker build -t="xianhu/centos:gitdir" .

其中-t用来指定新镜像的用户信息、tag等。最后的点表示在当前目录寻找Dockerfile。

构建完成之后，同样可以使用docker images命令查看：

[root@xxx ~]# docker images

REPOSITORY        TAG       IMAGE ID      CREATED            SIZE

xianhu/centos     gitdir    0749ecbca587  34 minutes ago     359.7 MB

xianhu/centos     git       52166e4475ed  About an hour ago  358.1 MB

centos            latest    0584b3d2cf6d  9 days ago         196.5 MB

以上就是构建自己镜像的两种方法。其中也涉及到了容器的一些操作。如果想删除容器或者镜像，可以使用rm命令，注意：删除镜像前必须先删除以此镜像为基础的容器。

[root@xxx ~]# docker rm container_name/container_id

[root@xxx ~]# docker rmi image_name/image_id

镜像其他操作指令：

点击了解更多，查看剩余部分

了解更多

关键字：Docker  云计算  开发运维  编码  程序

收起阅读 »

简介： Docker 是一个开源的应用容器引擎，基于 Go 语言 并遵从 Apache2.0 协议开源。 Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。 容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）,更重要的是容器性能开销极低。

Docker是什么？

在计算机技术日新月异的今天， Docker 在国内发展的如火如荼，特别是在一线互联网公司， Docker 的使用是十分普遍的，甚至成为了一些企业面试的加分项，不信的话看看下面这张图。



这是我在某招聘网站上看到的招聘 Java开发工程师 的招聘要求，其中有一条熟悉 docker 成为了你快速入职的加分项，由此可见熟悉 docker 在互联网公司的地位之重要。

当然对于我们 CTF选手 而言，熟悉 docker 可以快速搭建 CTF环境 ，完美地还原比赛真实漏洞的场景，帮助我们快速提升自己。

市面上已经有很多优秀的教程，但是很多原理性的东西，笔者认为那些教程对初学者而言还是很难理解，感觉没有说清楚(笔者自己都觉得挺懵逼的)，为了让初学者少走弯路，我将以我的学习经历以及作为一个 CTF选手 的角度，编写此套教程，来带大家去了解并熟练运用 docker ，祝愿各位读者朋友们学完此套教程后，在未来企业面试中能够多一项加分的筹码，能够帮助到大家，我觉得就很值了。

既然说了这么多， docker 到底是个什么东西呢？

我们在理解 docker 之前，首先我们得先区分清楚两个概念，容器和虚拟机。

可能很多读者朋友都用过虚拟机，而对容器这个概念比较的陌生。

我们用的传统虚拟机如 VMware ， VisualBox 之类的需要模拟整台机器包括硬件，每台虚拟机都需要有自己的操作系统，虚拟机一旦被开启，预分配给它的资源将全部被占用。每一台虚拟机包括应用，必要的二进制和库，以及一个完整的用户操作系统。

而容器技术是和我们的宿主机共享硬件资源及操作系统，可以实现资源的动态分配。容器包含应用和其所有的依赖包，但是与其他容器共享内核。容器在宿主机操作系统中，在用户空间以分离的进程运行。

容器技术是实现操作系统虚拟化的一种途径，可以让您在资源受到隔离的进程中运行应用程序及其依赖关系。通过使用容器，我们可以轻松打包应用程序的代码、配置和依赖关系，将其变成容易使用的构建块，从而实现环境一致性、运营效率、开发人员生产力和版本控制等诸多目标。容器可以帮助保证应用程序快速、可靠、一致地部署，其间不受部署环境的影响。容器还赋予我们对资源更多的精细化控制能力，让我们的基础设施效率更高。通过下面这幅图我们可以很直观的反映出这两者的区别所在。



Docker 属于 Linux 容器的一种封装，提供简单易用的容器使用接口。它是目前最流行的 Linux 容器解决方案。

而 Linux 容器是 Linux 发展出了另一种虚拟化技术，简单来讲， Linux 容器不是模拟一个完整的操作系统，而是对进程进行隔离，相当于是在正常进程的外面套了一个保护层。对于容器里面的进程来说，它接触到的各种资源都是虚拟的，从而实现与底层系统的隔离。

Docker 将应用程序与该程序的依赖，打包在一个文件里面。运行这个文件，就会生成一个虚拟容器。程序在这个虚拟容器里运行，就好像在真实的物理机上运行一样。有了 Docker ，就不用担心环境问题。

总体来说， Docker 的接口相当简单，用户可以方便地创建和使用容器，把自己的应用放入容器。容器还可以进行版本管理、复制、分享、修改，就像管理普通的代码一样。

Docker的优势

了解更多

点击了解更多，查看剩余部分

收起阅读 »

一.环境准备1.hosts设置
每台设备两块网卡:
第一块:NAT模式,用于下载软件包,设置好IP可以上网
第二块:桥接模式,用于External网络,用于虚拟机连接外部网络,不用设置IP
 
hosts:hosteth0eth1deploy9.110.187.130 controller019.110.187.131不需要IPcontroller029.110.187.132不需要IPcompute019.110.187.133不需要IPcompute029.110.187.134不需要IPstorage9.110.187.135不需要IP2.ssh免密登录

ssh-keygen

ssh-copy-id root@controller01

ssh-copy-id root@controller02

ssh-copy-id root@compute01

ssh-copy-id root@compute02

ssh-copy-id root@storage

3.存储节点配置

1. 要启动cinder存储服务，需先添加一块新的硬盘，然后创建pv、vg

[root@storage ~]# pvcreate /dev/sdb

[root@storage ~]# vgcreate cinder-volumes /dev/sdb  //vg名取名为 cinder-volumes，这里主要跟 kolla配置文件里vg名一致

1. 只允许vm实例访问块存储卷，对LVM可能出现异常做设置

vim /etc/lvm/lvm.conf

#修改 devices 下面的，有多少块硬盘就写多少块，如果不想使用系统盘，则不写a|sda

filter = [ "a|sda|", "a|sdb|", "r|.*|" ]

​

#重启lvm服务

systemctl restart lvm2-lvmetad.service

4.配置国内PIP源
所有节点都需要配置

mkdir ~/.pip

​

cat << EOF > ~/.pip/pip.conf

[global]

index-url = https://pypi.tuna.tsinghua.edu.cn/simple/

[install]

trusted-host=pypi.tuna.tsinghua.edu.cn

EOF

5.安装PIP

#安装依赖

yum install -y python-devel libffi-devel gcc openssl-devel libselinux-python

​

#安装PIP

yum install -y python-pip

pip install --upgrade pip

6.安装docker

1. 所有节点都安装

yum install -y yum-utils device-mapper-persistent-data lvm2

yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

yum install docker-ce

1. 配置Docker共享挂载

mkdir /etc/systemd/system/docker.service.d 

tee /etc/systemd/system/docker.service.d/kolla.conf << 'EOF' 

[Service] 

MountFlags=shared 

EOF

1. 使用阿里加速地址

mkdir -p /etc/docker

​

systemctl daemon-reload && systemctl enable docker && systemctl restart docker

systemctl status docker

二.部署节点安装1.安装docker模块

pip install docker   //这个其它节点也需要安装,否则后面会报错

2.ansible安装

yum install -y ansible

pip install -U ansible

3.安装kolla和kolla-ansible

• Kolla-Ansible 可以从pip安装，也可以从git安装，这里演示从pip安装

pip install kolla kolla-ansible

错误解决方案[list=1]

Cannot uninstall 'PyYAML'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.

解决:强制更新

pip install --ignore-installed PyYAML

[list=1]

如果出现

requests 2.20.0 has requirement idna<2.8,>=2.5, but you'll have idna 2.4 which is incompatible.

错误，则强制更新

requets

库

pip install --ignore-installed requests

• 配置kolla-ansible1)拷贝globals.yml 和passwords.yml 到 /etc/kolla 目录

  cp -r /usr/share/kolla-ansible/etc_examples/kolla /etc/

  2)拷贝kolla-ansible的主机清单文件（all-in-one和multinode）

  cp /usr/share/kolla-ansible/ansible/inventory/* /home/​

注：如果是在虚拟机里再启动虚拟机，那么需要把virt_type=qemu，默认是kvm

mkdir -p /etc/kolla/config/nova cat << EOF > /etc/kolla/config/nova/nova-compute.conf [libvirt] virt_type=qemu cpu_mode = none EOF

4.生成密码文件

kolla-genpwd

修改下面字段，使用方便的密码

vim /etc/kolla/passwords.yml    keystone_admin_password: devops

5.修改配置文件[list=1]

grep -Ev "^$|^[#;]" /etc/kolla/globals.yml

kolla_base_distro: "centos"kolla_install_type: "source"openstack_release: "rocky"kolla_internal_vip_address: "9.110.187.180"network_interface: "eth0"api_interface: "{{ network_interface }}"neutron_external_interface: "eth1"neutron_plugin_agent: "openvswitch"enable_cinder: "yes"enable_cinder_backend_iscsi: "yes"enable_cinder_backend_lvm: "no"enable_haproxy: "yes"enable_heat: "yes"glance_enable_rolling_upgrade: "no"ironic_dnsmasq_dhcp_range:tempest_image_id:tempest_flavor_ref_id:tempest_public_network_id:tempest_floating_network_name:

[list=1]

编辑/home/multinode文件

[control]controller01controller02​[network]controller01controller02​[inner-compute]​[external-compute]compute01compute02​[compute:children]inner-computeexternal-compute​[monitoring]deploy​[storage]storage​[deployment]localhost       ansible_connection=local........

6.网关配置这里physnet1是对外网络的名字,在dashboard里创建供应商网络的名字要和这里对应vim /usr/share/kolla-ansible/ansible/roles/neutron/templates/ml2_conf.ini.j2

[ml2_type_vlan]{% if enable_ironic | bool %}network_vlan_ranges = physnet1{% else %}network_vlan_ranges = physnet1{% endif %}

 三.openstack集群安装1.提前拉取镜像

kolla-ansible -i ./multinode pull -vvv

2.确认inventory配置文件是否正确

ansible -m ping all -i ./multinode

3.Bootstrap服务的依赖安装

kolla-ansible -i ./multinode bootstrap-servers

4.检查

kolla-ansible -i ./multinode prechecks

5.部署

kolla-ansible -i ./multinode deploy​注:可以加-vvv,显示更多

6.使用openstack

• 生成环境变量和脚本

kolla-ansible -i ./multinode post-deploy此时会在/etc/kolla下面生成admin-openrc.sh脚本,执行一下

至此multinodes部署完成，浏览器输入外网访问地址：http://9.110.187.180，即可访问Openstack的登陆页面，用户名和密码都是之前设置的 

• 各节点上服务常用目录

/etc/kolla 服务配置目录
/var/lib/docker/volumes/kolla_logs/_data 服务日志目录
/var/lib/docker/volumes 服务数据映射的目录销毁openstack

kolla-ansible destroy -i ./multinode  --yes-i-really-really-mean-it

  收起阅读 »

环境规划服务器规划
192.168.3.167                    192.168.3.168                    192.168.3.170
mongos                             mongos                              mongos
config server                     config server                       config server
shard server1 主节点         shard server1 副节点           shard server1 仲裁
shard server2 仲裁            shard server2 主节点           shard server2 副节点
shard server3 副节点         shard server3 仲裁              shard server3 主节点
端口分配:
mongos：20000 
config：27017
shard1：27001 
shard2：27002 
shard3：27003
 
配置yum源并安装mongodb3.6

cat > /etc/yum.repos.d/mongodb-org-3.6.repo << EOF

[mongodb-org-3.6]

name=MongoDB Repository

baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.6/x86_64/

gpgcheck=1

enabled=1

gpgkey=https://www.mongodb.org/static/pgp/server-3.6.asc

EOF

​

yum install mongodb-org -y

目录创建:
分别在每台机器建立conf、mongos、config、shard1、shard2、shard3目录，因为mongos不存储数据，只需要建立日志文件目录即可
配置服务:
可以根据业务需求创建相应目录，此文档按yum安装所产生的/etc/mongo.ocnf文件默认配置，如果自行创建记得修改目录权限

chown -R mongod:mongod /var/lib/mongo

vim /etc/mongod.conf

systemLog:

  destination: file

  logAppend: true

  path: /var/log/mongodb/mongod.log

storage:

  dbPath: /var/lib/mongo

  journal:

    enabled: true

processManagement:

  fork: true  # fork and run in background

  pidFilePath: /var/run/mongodb/mongod.pid  # location of pidfile

  timeZoneInfo: /usr/share/zoneinfo

net:

  port: 27017

  bindIp: 0.0.0.0

replication:

  replSetName: csReplSet

sharding:

  clusterRole: configsvr  

启动所有的mongo config server服务

mongod --config /etc/mongod.conf

 副本服务登录任意一台配置服务器，初始化配置副本集

mongo --port 27017

#创建配置

config = {

  _id : "csReplSet", 

  members : [ 

  {_id : 1, host : "192.168.3.167:27017" }, 

  {_id : 2, host : "192.168.3.168:27017" }, 

  {_id : 3, host : "192.168.3.170:27017" } 

  ] 

}

#初始化副本集

rs.initiate(config)

#查看状态

rs.status()

其中，"_id" : " csReplSet "应与配置文件中配置的 replicaction.replSetName 一致，"members" 中的 "host" 为三个节点的 ip 和 port
 
分片服务:
配置分片副本集(三台机器)
1.设置第一个分片副本集

vim /etc/shard1.conf

systemLog:

  destination: file

  logAppend: true

  path: /var/log/mongodb/shard1.log

storage:

  dbPath: /var/lib/mongo/shard1/data

  journal:

    enabled: true

processManagement:

  fork: true

  pidFilePath: /var/run/mongodb/shard1.pid

  timeZoneInfo: /usr/share/zoneinfo

net:

  port: 27001

  bindIp: 0.0.0.0

  maxIncomingConnections: 20000

replication:

  replSetName: shard1

sharding:

  clusterRole: shardsvr

  

#启动所有的shard1 server

mongod --config /etc/shard1.conf

​

#登陆任意一台shard1服务器，初始化副本集

mongo --port 27001

use admin

#定义副本集配置

config = {

   _id : "shard1",

    members : [

        {_id : 1, host : "192.168.3.167:27001",priority:2 },

        {_id : 2, host : "192.168.3.168:27001",priority:1 },

        {_id : 3, host : "192.168.3.170:27001",arbiterOnly: true }

    ]

}

#初始化副本集配置

rs.initiate(config);

​

#查看分区状态

rs.status()

​

====================

#配置第二个分片和副本集

vim /etc/shard2.conf

systemLog:

  destination: file

  logAppend: true

  path: /var/log/mongodb/shard2.log

storage:

  dbPath: /var/lib/mongo/shard2/data

  journal:

    enabled: true

processManagement:

  fork: true

  pidFilePath: /var/run/mongodb/shard2.pid

  timeZoneInfo: /usr/share/zoneinfo

net:

  port: 27002

  bindIp: 0.0.0.0

  maxIncomingConnections: 20000

replication:

  replSetName: shard2

sharding:

  clusterRole: shardsvr

  

#启动所有的shard2 server

mongod --config /etc/shard2.conf

​

#登陆任意一台非仲裁节点服务器，初始化副本集

mongo --port 27002

use admin

​

#定义副本集配置

config = {

   _id : "shard2",

    members : [

        {_id : 1, host : "192.168.3.167:27002",arbiterOnly: true },

        {_id : 2, host : "192.168.3.168:27002",priority:2 },

        {_id : 3, host : "192.168.3.170:27002",priority:1 }

    ]

}

#初始化副本集配置

rs.initiate(config);

​

#查看分区状态

rs.status()

​

#配置第三个分片和副本集

vim /etc/shard3.conf

systemLog:

  destination: file

  logAppend: true

  path: /var/log/mongodb/shard3.log

storage:

  dbPath: /var/lib/mongo/shard3/data

  journal:

    enabled: true

processManagement:

  fork: true

  pidFilePath: /var/run/mongodb/shard3.pid

  timeZoneInfo: /usr/share/zoneinfo

net:

  port: 27003

  bindIp: 0.0.0.0

  maxIncomingConnections: 20000

replication:

  replSetName: shard3

sharding:

  clusterRole: shardsvr

  

#启动所有的shard3 server

mongod --config /etc/shard3.conf

​

#初始化副本集配置

rs.initiate(config)

​

#查看分区状态

rs.status()

路由服务:
配置路由服务器 mongos
先启动配置服务器和分片服务器,后启动路由实例启动路由实例:（三台机器）

vim /etc/mongos.conf

systemLog:

  destination: file

  logAppend: true

  path: /var/log/mongodb/mongos.log

processManagement:

  fork: true

  pidFilePath: /var/run/mongodb/mongos.pid

  timeZoneInfo: /usr/share/zoneinfo

net:

  port: 20000

  bindIp: 0.0.0.0

  maxIncomingConnections: 20000

sharding:

  configDB: csReplSet/192.168.3.167:27017,192.168.3.168:27017,192.168.3.170:27017

​

#注意监听的配置服务器,只能有1个或者3个 csReplSet为配置服务器的副本集名字

configDB: csReplSet/192.168.3.167:21000, 192.168.3.168:21000, 192.168.3.170:21000

​

#启动路由服务器

mongos --config /etc/mongos.conf

​

#检查状态

netstat -tunlp | grep mongo

tcp        0      0 0.0.0.0:27001           0.0.0.0:*               LISTEN      8810/mongod     

tcp        0      0 0.0.0.0:27002           0.0.0.0:*               LISTEN      6962/mongod    

tcp        0      0 0.0.0.0:27003           0.0.0.0:*               LISTEN      12671/mongod      tcp        0      0 0.0.0.0:20000           0.0.0.0:*               LISTEN      13577/mongos      tcp        0      0 0.0.0.0:27017           0.0.0.0:*               LISTEN      10328/mongod  

启用分片
目前搭建了mongodb配置服务器、路由服务器，各个分片服务器，不过应用程序连接到mongos路由服务器并不能使用分片机制，还需要在程序里设置分片配置，让分片生效

#登录其中的一台路由节点，手动启用分片

mongo --port 20000

use admin

#添加分片到mongos

sh.addShard("shard1/192.168.3.167:27001,192.168.3.168:27001,192.168.3.170:27001")

sh.addShard("shard2/192.168.3.167:27002,192.168.3.168:27002,192.168.3.170:27002")

sh.addShard("shard3/192.168.3.167:27003,192.168.3.168:27003,192.168.3.170:27003")

​

#查看集群状态

sh.status()

收起阅读 »

kubeadm手动安装kubernetes 1.13高可用集群
 初始化集群:配置hosts文件
vim /etc/hosts

192.168.3.147test-master01

192.168.3.148test-master02

192.168.3.149test-master03

192.168.3.150test-work01

配置免密登录

ssh-keygen

ssh-copy-id test-master01

ssh-copy-id test-master02

ssh-copy-id test-master03

ssh-copy-id test-work01

设置参数

• 关闭防火墙

systemctl stop firewalldsystemctl disable firewalld

• 关闭swap

swapoff -ased -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

修改 /etc/fstab 文件，注释掉 SWAP 的自动挂载，使用free -m确认swap已经关闭。

• 关闭selinux

sed-i 's/SELINUX=permissive/SELINUX=disabled/' /etc/sysconfig/selinuxsetenforce0

• 配置转发相关参数，否则可能会出错

cat < /etc/sysctl.d/k8s.confnet.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-nf-call-iptables = 1net.ipv4.ip_forward=1net.ipv4.tcp_tw_recycle=0vm.swappiness=0vm.overcommit_memory=1vm.panic_on_oom=0fs.inotify.max_user_watches=89100fs.file-max=52706963fs.nr_open=52706963net.ipv6.conf.all.disable_ipv6=1net.netfilter.nf_conntrack_max=2310720EOFsysctl --system

以上在所有的Kubernetes节点执行命令使修改生效

• kube-proxy开启ipvs

在所有work节点执行：

cat > /etc/sysconfig/modules/ipvs.modules <上面脚本创建了的/etc/sysconfig/modules/ipvs.modules文件，保证在节点重启后能自动加载所需模块。 使用lsmod | grep -e ip_vs -e nf_conntrack_ipv4命令查看是否已经正确加载所需的内核模块.接下来还需要确保各个节点上已经安装了ipset软件包yum install ipset。 为了便于查看ipvs的代理规则，最好安装一下管理工具ipvsadm yum install ipvsadm
yum install ipset -yyum install ipvsadm -y
如果以上前提条件如果不满足，则即使kube-proxy的配置开启了ipvs模式，也会退回到iptables模式
系统优化参数


systemctl enable ntpdate.service

echo '*/30 * * * * /usr/sbin/ntpdate time7.aliyun.com >/dev/null 2>&1'> /tmp/crontab2.tmp

crontab /tmp/crontab2.tmp

systemctl start ntpdate.service
echo "* soft nofile 65536" >> /etc/security/limits.conf

echo "* hard nofile 65536" >> /etc/security/limits.conf

echo "* soft nproc 65536"  >>/etc/security/limits.conf

echo "* hard nproc 65536"  >>/etc/security/limits.conf

echo "* soft  memlock  unlimited"  >> /etc/security/limits.conf

echo "* hard memlock unlimited"  >>/etc/security/limits.conf


 安装docker
yum install -y epel-release

yum install -y yum-utils device-mapper-persistent-data lvm2 net-tools conntrack-toolswget vim  ntpdate libseccomp libtool-ltdltelnet rsync bind-utils

yum install -y https://mirrors.aliyun.com/docker-ce/linux/centos/7/x86_64/stable/Packages/docker-ce-18.06.1.ce-3.el7.x86_64.rpm 
配置docker国内镜像:

所有节点安装docker

编辑/etc/docker/daemon.json，添加以下一行
{

"registry-mirrors":["https://registry.docker-cn.com"]

}


重启docker
systemctl daemon-reload

systemctl enable docker

systemctl start docker


注：如果使用overlay2的写法：
daemon.json

{

    "log-driver": "json-file",

    "log-opts": {

        "max-size": "100m",

        "max-file": "10"

    },

    "registry-mirrors": ["https://pqbap4ya.mirror.aliyuncs.com"],

        "storage-driver": "overlay2",

    "storage-opts":["overlay2.override_kernel_check=true"]

}


如果要使用overlay2，前提条件为使用ext4，如果使用xfs，需要格式化磁盘加上参数 mkfs.xfs -n ftype=1 /path/to/your/device ，ftype=1这个参数需要配置为1

 安装keepalived+haproxy

三台master 节点

略

VIP : 192.168.3.80

 安装 kubeadm, kubelet 和 kubectl

所有节点都执行设置yum源
cat < /etc/yum.repos.d/kubernetes.repo

[kubernetes]

name=Kubernetes

baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/

enabled=1

gpgcheck=1

repo_gpgcheck=1

gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg

EOF
安装组件
yum install -y kubelet-1.13.1 kubeadm-1.13.1 kubectl-1.13.1
开机启动
systemctl enable kubelet.service


 初始化K8S集群编辑kubeadm配置文件:

下面配置是kubeadm安装etcd写法：
cat > kubeadm-config.yaml << EOF

apiVersion: kubeadm.k8s.io/v1beta1

kind: ClusterConfiguration

kubernetesVersion: v1.13.1

apiServer:

  certSANs:

    - "192.168.3.80"

controlPlaneEndpoint: "192.168.3.80:8443"

networking:

  podSubnet: "10.50.0.0/16"

imageRepository: "harbor.oneitfarm.com/k8s-cluster-images"

EOF

​


CNI使用Calico，设置podSubnet: “10.50.0.0/16”

192.168.3.80是刚才安装haproxy+keepalived的VIP初始化第一个master
kubeadm init --config kubeadm-config.yaml

...

[root@master01 ~]# mkdir -p $HOME/.kube

[root@master01 ~]# cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

[root@master01 ~]# chown $(id -u):$(id -g) $HOME/.kube/config
安装网络插件

按官网方式：

Installing with the Kubernetes API datastore—50 nodes or less：
kubectl apply -f \

https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml

​

kubectl apply -f \

https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml


以上建议先wget下来，需要根据自己网络修改配置 ：
- name: CALICO_IPV4POOL_CIDR

  value: "10.50.0.0/16"
复制相关文件到其他master节点
ssh root@master02 mkdir -p /etc/kubernetes/pki/etcd

scp /etc/kubernetes/admin.conf root@master02:/etc/kubernetes

scp /etc/kubernetes/pki/{ca.*,sa.*,front-proxy-ca.*} root@master02:/etc/kubernetes/pki

scp /etc/kubernetes/pki/etcd/ca.* root@master02:/etc/kubernetes/pki/etcd
部署master-other

在其它slave节点上执行下面命令，加入集群
kubeadm join 192.168.3.80:8443 --token pv2a9n.uh2yx1082ffpdf7n --discovery-token-ca-cert-hash sha256:872cac35b0bfec28fab8f626a727afa6529e2a63e3b7b75a3397e6412c06ebc5 --experimental-control-plane
kube-proxy开启ipvs

修改ConfigMap的kube-system/kube-proxy中的config.conf，mode: “ipvs”：
kubectl edit configmap kube-proxy -n kube-system

kubectl get pod -n kube-system | grep kube-proxy | awk '{system("kubectl delete pod "$1" -- grace-period=0 --force -n kube-system")}'


 检查测试查看kubernetes集群状态
kubectl get nodes -o wide

kubectl get cs

    NAME                 STATUS    MESSAGE              ERROR

    controller-manager   Healthy   ok

    scheduler            Healthy   ok

    etcd-0               Healthy   {"health": "true"}
查看etcd集群状态

本文通过kubeadm自动安装etcd，也就是docker方式安装的etcd,可以exec进去容器内检查：
kubectl exec -ti -n kube-system etcd-an-master01 sh

/ # export ETCDCTL_API=3

/ # etcdctl --endpoints=https://[127.0.0.1]:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt --key=/etc/kubernetes/pki/etcd/healthcheck-client.key member list
安装失败清理集群

集群初始化如果遇到问题，可以使用下面的命令进行清理：
kubeadm reset

systemctl stop kubelet

systemctl stop docker

rm -rf /var/lib/cni/

rm -rf /var/lib/kubelet/*

rm -rf /etc/cni/

ifconfig cni0 down

ifconfig flannel.1 down

ifconfig docker0 down

ip link delete cni0

ip link delete flannel.1

systemctl start docker


 设置资源调度

使用kubeadm初始化的集群，出于安全考虑Pod不会被调度到Master Node上，也就是说Master Node不参与工作负载。这是因为当前的master节点被打上了node-role.kubernetes.io/master:NoSchedule的污点：
kubectl describe node master01 | grep Taint

Taints:             node-role.kubernetes.io/master:NoSchedule


检查join进集群的master和work节点，如果调度不对，可以通过如下方式设置：
[root@an-master01 ~]# kubectl get nodes

NAME          STATUS   ROLES    AGE     VERSION

an-master01   Ready    master   4h39m   v1.13.1

an-master02   Ready       4h32m   v1.13.1

an-master03   Ready    master   86m     v1.13.1

an-work01     Ready       85m     v1.13.1

​

查看当前状态：

kubectl describe nodes/an-master02 |grep -E '(Roles|Taints)'

Roles:              

Taints:             

​

设置为master节点且不调度：

kubectl label node an-master02 node-role.kubernetes.io/master=

kubectl taint nodes an-master02 node-role.kubernetes.io/master=:NoSchedule

如果想去除限制的话：

kubectl taint nodes an-master03 node-role.kubernetes.io/master-

​

work节点设置：

kubectl label node an-work01 node-role.kubernetes.io/work=

kubectl describe nodes/an-work01 |grep -E '(Roles|Taints)'

Roles:              work

Taints:             


 																			        	收起阅读 »
								        											

    学习Kubernetes没有什么特殊技巧，需要循序渐进，理论结合实践，不管目前生产中是否使用K8S，作为运维工程师，每个人都应该有自己的一个K8S集群，才能开启探索之路。拒绝夸夸其谈，前后不一致！！！
 
    请查看下面的链接：
 
    https://mp.weixin.qq.com/s?__biz=MzI5MjA5Mjg5OA==&mid=2247484395&idx=1&sn=0767cc24ec99ce818e41f7c40dda5d23&chksm=ec07ed66db7064707b05a9dda9c23882b9106577fc5f1ef45a9d78e6a93a57a5f507210207ae&token=1791180619&lang=zh_CN#rd 收起阅读 »