暗网巨头Empire Market关闭数日

打开可以看到，里面有13个根的名字和IP，其名字从A.root-servers.net到M.root-servers.net。

A开头那个简称A根，是主根，其他12个(B、C、D、E、F、G、H、I、J、K、L、M)是辅根。

为什么根DNS只有13台?

本节看不懂没关系(一般人都看不懂)，你只需要知道，由于历史原因和技术原因，对于IPv4而言，根DNS只能有13个IP。

正宗答案是：DNS主要使用UDP数据报传送报文，不含前面的各种头部，DNS报文要求被控制在512字节之内( RFC1035 )，主要考虑是这个大小几乎可以在互联网上畅通无阻，不会因为路径中某个MTU太小( MTU 通常总会 >= 576，见 RFC791 )而导致IP分片，从而预防了各种不可预期的后果3。

而每一个根DNS在DNS报文中都要占用一定的字节数，比如根的名称、TTL、IP地址等。这样，13个根域名服务器基本上就把空间占差不多了，剩余的字节还要用于包装DNS报头以及其它协议参数，所以根域名服务器不易太多，13个算是比较合适的数目。具体可以看一下“Why 13 DNS root servers?”这篇文章。4

真的只有13台服务器吗?

和很多人想象的完全不一样，这13个根域名服务器，并不是只有13台物理的服务器。

这13个根，只是一个逻辑上的概念，每个根DNS，背后都有多台真正的物理服务器在工作!

截至2020年8月12日，全球一共有1097个根服务器。每一个根都有若干个镜像，分布在全球不同的地方。

 

1)不同版本的参数文件，比如环境有5.5,5.6,5.7,8.0等，如何更好的支持多个版本

2)初始化用户和权限，根据业务特点有些预置的用户需要创建，配置相应的权限，不同版本下的语法格式都有差异，还有密码插件相关影响。

3)安装部署通常是和监控报警，备份恢复相关的，这些工作是不是可以作为可选项

4)单机多实例和service部署模式还是有一定的差别，如何平滑适配

5) 新增数据库版本支持，已有的接口和部署方式如何适配

MySQL 8.0已经推出了几年，也在内部做了一些测试和总结，而且早期我们直接入主MySQL 5.7版本，也算是积累了3年多的经验，所以果断决定新业务都按照MySQL 8.0的基线来推广。

已有的脚本都好几年没动过了，经过一番需求分析，发现这是一个半成品，主要原因如下：

1)脚本目前直接使用的场景很少，去年团队下大功夫开发的一键部署，因为流程长而显得比较脆弱，已经和这个功能有了很大的差别

2)脚本执行不稳定，因为之前的脚本设计中采用了很多分散的脚本，也就意味着是脚本调脚本的思路，逻辑相对比较庞大，混杂

3)新增8.0的功能，脚本需要整体改动，涉及的面比较大

4)目前脚本里面也存在一些细小的问题，一直没有修复

对于这些问题，我做了如下的一些事情。

1)备份脚本内容后，我开始删除一些过时的逻辑检查代码，去掉一些没有使用场景的逻辑和相关脚本

2)将多个脚本整合为1个，重新组织了脚本关联依赖

3)将依赖的参数文件模板和脚本模板都上传到配置中心里面，在脚本里面会用命令方式提取

4)把原来文件夹的脚本结构重构为一个单一的脚本

5)修改前端的配置，去掉冗余无效的配置项，修改调用逻辑

6)团队内部做了简单演示，团队提了一些改进建议，修正后发布

这些工作经过了很多的测试和整理之后，在不同版本中也做了相关的测试和验证。也算是让原本半成品的状态变为可用，而且是最新版本，接下来要做几件更细致的事情。

1)安装部署的时间目前在30秒以内，涉及数据字典的初始化，目前使用了一刀切的逻辑，后台sleep 20秒，保证这个过程的初始化时间足够，其实可以更加动态友好一些，做动态监测

2)考虑使用基于自制yum的配置方式，把一些固化的参数，命令等方式重新打包构建，这样后续就可以使用yum的方式快速部署了。

3)把软件安装和部署整合起来，提供多版本的软件支持和安装，比如8.0.19,8.0.20

4)使用基于压缩镜像的模式，可以把一个数据库压缩到极小容量，需要时直接解压启动即可，经过之前的测试，一个可用的数据库镜像大概在2M左右，解压后在2G~3G左右(涉及ibdata，reod等文件的容量)

（编辑：鹰潭站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!