近日，Apache Solr/Lucene修复了一个0-day漏洞，该漏洞可能导致运程代码执行、信息泄露，危害严重。请及时检查您所使用的Apache Solr是否受影响，并采取安全防御措施。
 
影响范围:

Solr 5.5.0 to 5.5.4

Solr 6.0.0 to 6.6.1

Solr 7.0.0 to 7.0.1

修复方案：

升级到官方提供的安全修复版本：

Solr 6.6.2

Solr 7.1.0

漏洞详情：
CVE-2017-12629：Apache Solr存在XXE和RCE漏洞：

1. lucene xml解析器没有明确禁止doctype 外部实体的声明，黑客可通过构造恶意的XML请求来读取服务器任意文件，导致信息泄露。
2. Apache Solr“RunExecutableListener”类可以通过恶意的请求来执行任意操作，导致服务器被控制。

 
参考链接：
https://issues.apache.org/jira/browse/SOLR-11482  
https://issues.apache.org/jira/browse/SOLR-11477   收起阅读 »

前几天我尝试去创建一个仅包含我们经常在 CentOS 7 下使用的软件的本地仓库。当然，我们可以使用 curl 或者 wget 下载任何软件包，然而这些命令并不能下载要求的依赖软件包。你必须去花一些时间而且手动的去寻找和下载被安装的软件所依赖的软件包。然而，我们并不是必须这样。在这个简短的教程中，我将会带领你以两种方式下载软件包及其所有依赖包。我已经在 CentOS 7 下进行了测试，不过这些相同的步骤或许在其他基于 RPM 管理系统的发行版上也可以工作，例如 RHEL，Fedora 和 Scientific Linux。
 

方法1利用"Downloadonly"插件下载 RPM 软件包及其所有依赖包

我们可以通过 yum 命令的 “Downloadonly” 插件下载 RPM 软件包及其所有依赖包, 为了安装 Downloadonly 插件，以 root 身份运行以下命令：

yum install yum-plugin-downloadonly

现在，运行以下命令去下载一个 RPM 软件包

yum install --downloadonly 

默认情况下，这个命令将会下载并把软件包保存到 /var/cache/yum/ 的 rhel-{arch}-channel/packageslocation 目录，不过，你也可以下载和保存软件包到任何位置，你可以通过 –downloaddir 选项来指定。

yum install --downloadonly --downloaddir= 

例子:

yum install --downloadonly --downloaddir=/root/mypackages/ httpd

终端输出:

Loaded plugins: fastestmirror

Loading mirror speeds from cached hostfile

 * base: centos.excellmedia.net

 * epel: epel.mirror.angkasa.id

 * extras: centos.excellmedia.net

 * updates: centos.excellmedia.net

Resolving Dependencies

--> Running transaction check

---> Package httpd.x86_64 0:2.4.6-40.el7.centos.4 will be installed

--> Processing Dependency: httpd-tools = 2.4.6-40.el7.centos.4 for package: httpd-2.4.6-40.el7.centos.4.x86_64

--> Processing Dependency: /etc/mime.types for package: httpd-2.4.6-40.el7.centos.4.x86_64

--> Processing Dependency: libaprutil-1.so.0()(64bit) for package: httpd-2.4.6-40.el7.centos.4.x86_64

--> Processing Dependency: libapr-1.so.0()(64bit) for package: httpd-2.4.6-40.el7.centos.4.x86_64

--> Running transaction check

---> Package apr.x86_64 0:1.4.8-3.el7 will be installed

---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed

---> Package httpd-tools.x86_64 0:2.4.6-40.el7.centos.4 will be installed

---> Package mailcap.noarch 0:2.1.41-2.el7 will be installed

--> Finished Dependency Resolution

Dependencies Resolved

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

 Package Arch Version Repository Size

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

Installing:

 httpd x86_64 2.4.6-40.el7.centos.4 updates 2.7 M

Installing for dependencies:

 apr x86_64 1.4.8-3.el7 base 103 k

 apr-util x86_64 1.5.2-6.el7 base 92 k

 httpd-tools x86_64 2.4.6-40.el7.centos.4 updates 83 k

 mailcap noarch 2.1.41-2.el7 base 31 k

Transaction Summary

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

Install 1 Package (+4 Dependent packages)

Total download size: 3.0 M

Installed size: 10 M

Background downloading packages, then exiting:

(1/5): apr-1.4.8-3.el7.x86_64.rpm | 103 kB 00:00:01 

(2/5): apr-util-1.5.2-6.el7.x86_64.rpm | 92 kB 00:00:01 

(3/5): mailcap-2.1.41-2.el7.noarch.rpm | 31 kB 00:00:01 

(4/5): httpd-tools-2.4.6-40.el7.centos.4.x86_64.rpm | 83 kB 00:00:01 

(5/5): httpd-2.4.6-40.el7.centos.4.x86_64.rpm | 2.7 MB 00:00:09 

---------------------------------------------------------------------------------------------------------------------------------------

Total 331 kB/s | 3.0 MB 00:00:09 

exiting because "Download Only" specified

现在去你指定的目录位置下，你将会看到那里有下载好的软件包和依赖的软件。在我这种情况下，我已经把软件包下载到 /root/mypackages/ 目录下。
 
让我们来查看一下内容:

ls /root/mypackages/

样本输出：

apr-1.4.8-3.el7.x86_64.rpm

apr-util-1.5.2-6.el7.x86_64.rpm

httpd-2.4.6-40.el7.centos.4.x86_64.rpm

httpd-tools-2.4.6-40.el7.centos.4.x86_64.rpm

mailcap-2.1.41-2.el7.noarch.rpm

正如你在上面输出所看到的, httpd软件包已经被依据所有依赖性下载完成了 。
 
请注意，这个插件适用于 yum install/yum update， 但是并不适用于 yum groupinstall。默认情况下，这个插件将会下载仓库中最新可用的软件包。然而你可以通过指定版本号来下载某个特定的软件版本。

例子:

yum install --downloadonly --downloaddir=/root/mypackages/ httpd-2.2.6-40.el7

此外，你也可以如下一次性下载多个包：

yum install --downloadonly --downloaddir=/root/mypackages/ httpd vsftpd

方法 2 使用 "Yumdownloader"工具来下载 RPM 软件包及其所有依赖包

“Yumdownloader” 是一款简单，但是却十分有用的命令行工具，它可以一次性下载任何 RPM 软件包及其所有依赖包。

以 root 身份运行如下命令安装 “Yumdownloader” 工具。

yum install yum-utils

一旦安装完成，运行如下命令去下载一个软件包，例如 httpd:

yumdownloader httpd

为了根据所有依赖性下载软件包，我们使用 --resolve 参数：

yumdownloader --resolve httpd

默认情况下，Yumdownloader 将会下载软件包到当前工作目录下。

为了将软件下载到一个特定的目录下，我们使用 --destdir 参数：

yumdownloader --resolve --destdir=/root/mypackages/ httpd

或者

yumdownloader --resolve --destdir /root/mypackages/ httpd

终端输出：

Loaded plugins: fastestmirror

Loading mirror speeds from cached hostfile

 * base: centos.excellmedia.net

 * epel: epel.mirror.angkasa.id

 * extras: centos.excellmedia.net

 * updates: centos.excellmedia.net

--> Running transaction check

---> Package httpd.x86_64 0:2.4.6-40.el7.centos.4 will be installed

--> Processing Dependency: httpd-tools = 2.4.6-40.el7.centos.4 for package: httpd-2.4.6-40.el7.centos.4.x86_64

--> Processing Dependency: /etc/mime.types for package: httpd-2.4.6-40.el7.centos.4.x86_64

--> Processing Dependency: libaprutil-1.so.0()(64bit) for package: httpd-2.4.6-40.el7.centos.4.x86_64

--> Processing Dependency: libapr-1.so.0()(64bit) for package: httpd-2.4.6-40.el7.centos.4.x86_64

--> Running transaction check

---> Package apr.x86_64 0:1.4.8-3.el7 will be installed

---> Package apr-util.x86_64 0:1.5.2-6.el7 will be installed

---> Package httpd-tools.x86_64 0:2.4.6-40.el7.centos.4 will be installed

---> Package mailcap.noarch 0:2.1.41-2.el7 will be installed

--> Finished Dependency Resolution

(1/5): apr-util-1.5.2-6.el7.x86_64.rpm | 92 kB 00:00:01 

(2/5): mailcap-2.1.41-2.el7.noarch.rpm | 31 kB 00:00:02 

(3/5): apr-1.4.8-3.el7.x86_64.rpm | 103 kB 00:00:02 

(4/5): httpd-tools-2.4.6-40.el7.centos.4.x86_64.rpm | 83 kB 00:00:03 

(5/5): httpd-2.4.6-40.el7.centos.4.x86_64.rpm | 2.7 MB 00:00:19

让我们确认一下软件包是否被下载到我们指定的目录下：

ls /root/mypackages/

终端输出：

apr-1.4.8-3.el7.x86_64.rpm

apr-util-1.5.2-6.el7.x86_64.rpm

httpd-2.4.6-40.el7.centos.4.x86_64.rpm

httpd-tools-2.4.6-40.el7.centos.4.x86_64.rpm

mailcap-2.1.41-2.el7.noarch.rpm

不像 Downloadonly 插件，Yumdownload 可以下载一组相关的软件包。

yumdownloader "@Development Tools" --resolve --destdir /root/mypackages/

在我看来，我喜欢 Yumdownloader 更胜于 Yum 的 Downloadonly 插件。但是，两者都是十分简单易懂而且可以完成相同的工作。

这就是今天所有的内容，如果你觉得这份引导教程有用，清在你的社交媒体上面分享一下去让更多的人知道。

阅读分享，英文：https://www.ostechnix.com/download-rpm-package-dependencies-centos/ 中文：https://linux.cn/article-7937-1.html 收起阅读 »

早期防火墙是通过IP地址或端口来控制用户资源访问的，但通过“IP地址+端口”的方式很难控制及识别用户，从而存在安全隐患，而智能身份识别能够识别用户和用户所使用的计算机，进而可以对用户的网络行为进行访问控制，最终达到安全的目的。

Checkpoint防火墙主要是通过以下几种方式获取用户身份

1、AD query

通过微软Ad server来获得用户的身份信息、适用于大型网络，用户较多的环境。结合AD域只针对用户的AD记录来进行认证，不再针对IP地址一类信息。

（1）    安全网关从AD服务器上获得安全事件日志；
（2）    用户登录到域；
（3）    域服务器发送安全事件日志给安全网关，安全网关获取到用户的IP和用户相关信息（如用户的域信息，计算机名和源IP地址）；
（4）    用户要访问Internet；
（5）    安全网关确认用户身份后，根据策略决定是否允许用户访问Internet。

2、通过浏览器捕获身份

使用基于浏览器捕获身份认证信息。适用于非微软AD用户，通过浏览器来访问web资源。
流程如下：
（1）    用户从外部发起到datacenter的访问；
（2）    防火墙IA模块没有识别出用户，然后重定向用户的访问至Web portal界面；
（3）    用户输入自己的认证信息：可以使AD/LDAP/RADIUS等；
（4）    认证信息被发送至防火墙，之后防火墙通过后边所连接的AD server来返回用户的认证结果；
（5）    如果允许，则放通访问；
（6）    如果不允许，则不能通过访问。

3、通过agent获得用户身份

基于agent的认证类型有两种：

（1）    Endpoint Identity Agent：安装在用户PC上。
（2）    Terminal Servers Endpoint Identity Agent：安装在虚拟桌面系统中，能够识别同一IP源地址的不同用户。

认证流程如下：
（1）    用户发起到datacenter访问；
（2）    启用IA的安全网关向用户弹出web认证页面；
（3）    用户在web界面中点击下载agent的链接；
（4）    用户下载并安装Endpoint Identity Agent；
（5）    用户通过这个agent去连接安全网关；
（6）    用户认证通过，安全网关根据安全策略决定是否发起用户到目的地址的访问。

相同之处：

都有一个安全的身份识别的过程，都需要流量经过防火墙，然后通过防火墙来结合（AD域）来达到用户识别的目的。

不同之处：

有的是用浏览器来获取用户身份，而有的是用客户端来识别，还有结合浏览器和AD域来识别。

学习完整Check point智能身份识别课程，请点击“Check point智能身份识别” 收起阅读 »

Oracle RDA英文全称叫做“Oracle Remote Diagnostic Agent”。它是Oracle用来收集、分析数据库信息的工具，它是用perl编写的，包含非常丰富的诊断脚本，使用它科技非常便捷的采集到Oracle数据库服务器系统配置和数据库的详细信息，运行该工具不会改变系统的任何参数。
RDA收集的相关数据非常全面，可以简化我们日常监控、分析数据库的工作。Oracle Support也建议我们在反馈相关问题时，提供RDA收集的数据，这样可以为快速解决问题提供一个有力的保证。
Oracle作为目前行业最成熟的商业数据库管理系统软件，Oracle开发出很多有助于系统调试和运维的工具。借助这些优秀的免费工具，可以大大方便我们日常运维和管理工作。
无论是作为专业DBA，还是第三方支持人员，数据库巡检都是日常工作中不可缺少的工作内容。巡检项目通常是设置好的项目内容，有时候我们还会准备一些脚本或者命令作为手机手段。
巡检项目类型也会包括从操作系统，硬性文件系统，到数据库内存配置等广泛的内容，可能大多人员都会借助于AWR报告，同时，我们还可以借助Oracle提供的RDA来完成。
RDA全称Oracle Remote Diagnostic Agent（RDA）-RDA文档索引，RDA是Oracle用来收集，分析数据库的工具，运行该工具不会改变系统的任何参数，RDA收集的相关数据非常全面，这个Oracle诊断工具是用perl编写的，包含非常丰富的诊断脚本，使用它可以分成便利的采集到oracle数据库服务器系统配置和数据库的详细信息。可以简化我们的日常监控、分析数据库的工作。一般Oracle原厂的巡检也是使用RDA工具，不过一般国内的DBA巡检时很少使用这个工具，一般都是通过AWR或者自己整几个脚本跑一下，分析一下就OK了。
通过RDA可以快速的了解系统的状况，将会大大的缩短问题处理的周期，避免信息的反复采集。RDA不会更改数据库服务器的任何配置，仅仅是采集信息。
想要更详细的了解Oracle RDA工具的使用方法，请进入OTPUB技术课堂：http://www.otpub.com/Course/detail/index/id/210.html 收起阅读 »

    OpenStack作为一款全球化的开源软件，其设计之初的定位就是对于大中型企业，因为这些企业可以派出丰富而强大的技术团队进行深度开发与维护，而对缺乏软件开发和运维能力的传统企业及中小企业来说，易思捷OVM是100%更好的选择。(技术服务qq

群22265939)

[b]OVM是开箱即用的一站式解决方案[/b]

OpenStack的开源软件安装部署对于很多运维人员来说都不陌生，企业大多只提供安装包和简单的安装文档，而这些安装过程大多会涉及到数据库、redis、rabbitmq、ruby等环境的配置，这些配置也要求运维人员学习以上软件的安装部署，否则一步配置错误就会导致整体的安装部署失败，从而造成整个安装部署少则2-3天多则1-2周才能完成的窘境，复杂的安装部署过程让运维人员疲惫不堪。Openstack作为开源产品也不例外，并且 OpenStack可下载的厂商定制版本就有20多个，客户根本不知道应选择哪个版本，更不要说在不同厂商版本之间组合、混搭、迁移了，对于IT投入较小且缺乏专业人才的中小企业而言只能望洋兴叹。

而OVM是面向数据中心的一款开箱即用的免费服务器虚拟化软件，有别于传统的开源软件，OVM安装部署全部（包括管理平台和计算节点）采用一键式的ISO方式，整个安装过程就像是在安装一个Centos操作系统一样的简单，只用花费10-20分钟的过程就可以完成。即使是运维小白，通过OVM提供的ISO镜像也可在1小时内完成整个产品的安装部署。

[b]OVM的稳定性经得起考验[/b]

OVM从架构设计之初就充分考虑到产品的稳定性，并把稳定性放在了第一位。因为作为一款Iaas级的虚拟化管理软件，它不仅仅是一个软件，更是连接用户数据中心的中枢（包括物理机、存储、网络、防火墙、灾备等）。在架构设计上，OVM同时具备了开源软件和商业软件的优点，首先保证产品无单点故障，即管理平台高可用；其次支持分布式部署，将不可预估因素造成的损失降到最小。OVM架构包括分布式和插件式，这两个特点既允许用户将不同的模块和服务部署在同一台Server上面，也可以将其分开部署在多台Server上，大大了提高了部署的灵活性，同时也可将单点故障的风险降到最小。另外OVM引入了Zookeeper、Pacemaker等软件来为OVM提供高可用性，避免单点故障的发生。OVM的每个版本均经过严格的内测，再正式对外发布，每一个环节我们都严把质量关，将稳定性自始至终贯穿到OVM产品的每个环节。

而OpenStack每半年升级一次，每次升级都需要花费大量时间修复bug。根据www.51cto.com做的一项关于OpenStack的用户调查, 33.33%的用户认为OpenStack还不够稳定而且修改难度大。

[b]OVM升级更轻松简单[/b]

对于一个产品来说，迭代升级是必然的事情，未来产品研发规划中， OVM将考虑如何让用户不费吹灰之力就可以升级使用最新版本。最终做到与UI无缝结合，用户只需点击WEB管理平台中的一键升级按钮便可轻松实现版本的快速升级，并且不会影响到业务的正常运行。

而OpenStack的Nova，Swift，Cinder和Neutron分别使用各自的数据库存储配置信息，

要升级就要修改多个数据库schema，做不到热升级。再如，HP作为OpenStack的白金会员在部署网络服务(Neutron)时，遇到了噩梦般的经历，不得不重写网络组件的代码才能达到大规模应用的要求。OpenStack还有一个问题就是半年快速迭代，发布新产品，速度太快，老版本跟不上，理论上，新版本向下兼容，但当一些版本改动较大，加入新功能时，如果企业已经深度应用了旧版本，可能面临技术无法升级，或者需要重度开发的问题。由此说明，OpenStack在集成性、扩展性和实用性上还不足，如果要选用，需要一支专家队伍帮助实施。

[b]OVM可以提供端到端的服务[/b]

易思捷OVM社区作为OVM产品唯一的服务商，提供统一的产品功能和技术服务，以用户需求为导向来提供产品功能，也可以为用户提供端到端的服务保障。

而OpenStack不能提供端到端的服务保障。云平台必备的自动化部署、自动化运维、状态监控、设备管理、可用性检测、安全性、可靠性和平台自修复功能在OpenStack中或者缺失，或者散落在单独产品中。客户拿到手的只是散落的“骨架“，必须通过专业技术人员手工将多厂商、多版本的逐个功能集成起来，这对于中小企业来说显然难度很大。

[b]OVM的架构和性能更优[/b]

与OpenStack笨重的架构对比，OVM更加的轻量级，对于产品初期的按照及后期的运维都要简单得多。众所周知，OpenStack大小模块和组件加起来会有好几十个，要想真正搞懂每个组件，一两个人是无法完成的，是必须要有一个强大的技术团队才能支撑起来的。而且直接使用开源的OpenStack会存在很多bug，无法规模化商用，所以很多企业只能选择商业公司封装的OpenStack版本。另外需要着重说明的是，OpenStack不是产品，只是架构，在开源社区开发的各类版本，只有在“封装”之后才可以使用。一般的企业不具备这种技术实力，需要IT公司帮助实施、运维、开发等工作，这样无疑又加重了企业的总体成本。

综上，与OpenStack相比，易思捷OVM产品架构的设计严格按照商业产品架构的高标准要求，始终把产品的稳定性、易用性、可扩展性，以及产品的高性能放在第一位，秉承“用户是上帝”的理念，为用户提供优质的服务和高品质的产品，让大家共同来使用和见证中国人自己的虚拟化产品！

(技术服务qq群22265939)

收起阅读 »

VPN一般指虚拟专用网络，是一种在公用网络上建立的专用网络，进行加密通讯，在企业网络中有广泛应用。

VPN网关通过对数据包的加密和数据包目标地址的转换实现远程访问。VPN有多种分类方式，主要是按协议进行分类。VPN可通过服务器、硬件、软件等多种方式实现。

随着应用市场的需求，多分支计算机应用已经越来越广泛，但对于多分支点的计算机管理还存在着诸多挑战。

传统分支点管理的痛点

1、网点非常多

2、地域广

3、网点增长快

4、计算机少

5、无法跟上高增长节奏的有限的IT资源

总部IT部门无法有效进行管理

1、无法统一安全策略

2、运维效率低下

3、持续投入的人员成本

分支点的计算机管理通常是总部 IT 的恶梦。然而以上这些恶梦，通过VPN组建即可轻松化解。

如果您的企业设有较多的小微型分支机构，利用Sophos公司独特的VPN设备——RED，快速组建一个免配置、免维护的星型VPN网络。便于您简单经济地实现分支机构与总部的连接，并确保安全的 Internet 访问。

敬请关注，9月14日14：00，“Sophos云服务助力快速组网VPN网络”直播活动，专家与您分享，VPN快速搭建的方法.

直播间地址：“Sophos云服务助力快速组网VPN网络​” 收起阅读 »

一、前言​
关于mysql主从同步，相信大家都不陌生，随着系统应用访问量逐渐增大，单台数据库读写访问压力也随之增大，当读写访问达到一定瓶颈时，将数据库的读写效率骤然下降，甚至不可用；为了解决此类问题，通常会采用mysql集群，当主库宕机后，集群会自动将一个从库升级为主库，继续对外提供服务；那么主库和从库之间的数据是如何同步的呢？本文针对MySQL 5.7版本进行下面的分析，下面随笔者一起探究一下mysql主从是如何同步的。
 
二、MySQL主从复制原理
为了减轻主库的压力，应该在系统应用层面做读写分离，写操作走主库，读操作走从库，下图为MySQL官网给出的主从复制的原理图，从图中可以简单的了解读写分离及主从同步的过程，分散了数据库的访问压力，提升整个系统的性能和可用性，降低了大访问量引发数据库宕机的故障率。

 
三、binlog简介
MySQL主从同步是基于binlog文件主从复制实现，为了更好的理解主从同步过程，这里简单介绍一下binlog日志文件。

binlog日志用于记录所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个DELETE）的所有语句。语句以“事件”的形式保存，它描述数据更改，它是以二进制的形式保存在磁盘中。我们可以通过mysql提供的查看工具mysqlbinlog查看文件中的内容，例如 mysqlbinlog mysql-bin.00001 | more，这里注意一下binlog文件的后缀名00001，binlog文件大小和个数会不断的增加，当MySQL停止或重启时，会产生一个新的binlog文件，后缀名会按序号递增，例如mysql-bin.00002、mysql-bin.00003，并且当binlog文件大小超过 max_binlog_size系统变量配置时也会产生新的binlog文件。
 
（一）binlog日志格式
（1） statement ： 记录每一条更改数据的sql;

• 优点：binlog文件较小，节约I/O，性能较高。
• 缺点：不是所有的数据更改都会写入binlog文件中，尤其是使用MySQL中的一些特殊函数（如LOAD_FILE()、UUID()等）和一些不确定的语句操作，从而导致主从数据无法复制的问题。

 （2） row ： 不记录sql，只记录每行数据的更改细节

• 优点：详细的记录了每一行数据的更改细节，这也意味着不会由于使用一些特殊函数或其他情况导致不能复制的问题。
• 缺点：由于row格式记录了每一行数据的更改细节，会产生大量的binlog日志内容，性能不佳，并且会增大主从同步延迟出现的几率。

 （3） mixed：一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。 （二）binlog日志内容  （三）binlog事件类型MySQL binlog记录的所有操作实际上都有对应的事件类型的，譬如STATEMENT格式中的DML操作对应的是QUERY_EVENT类型，ROW格式下的DML操作对应的是ROWS_EVENT类型，如果想了解更多请参考官方文档，有关binlog日志内容不在这里过多赘述，简单介绍一下是为了更好的理解主从复制的细节，下面我们进入正题。  四、MySQL主从复制原理mysql主从复制需要三个线程，master（binlog dump thread）、slave（I/O thread 、SQL thread）。  Master（1）binlog dump线程：当主库中有数据更新时，那么主库就会根据按照设置的binlog格式，将此次更新的事件类型写入到主库的binlog文件中，此时主库会创建log dump线程通知slave有数据更新，当I/O线程请求日志内容时，会将此时的binlog名称和当前更新的位置同时传给slave的I/O线程。 Slave（2）I/O线程：该线程会连接到master，向log dump线程请求一份指定binlog文件位置的副本，并将请求回来的binlog存到本地的relay log中，relay log和binlog日志一样也是记录了数据更新的事件，它也是按照递增后缀名的方式，产生多个relay log（ host_name-relay-bin.000001）文件，slave会使用一个index文件（ host_name-relay-bin.index）来追踪当前正在使用的relay log文件。 （3）SQL线程：该线程检测到relay log有更新后，会读取并在本地做redo操作，将发生在主库的事件在本地重新执行一遍，来保证主从数据同步。此外，如果一个relay log文件中的全部事件都执行完毕，那么SQL线程会自动将该relay log 文件删除掉。 下面是整个复制过程的原理图：  四、主从同步延迟mysql的主从复制都是单线程的操作，主库对所有DDL和DML产生binlog，binlog是顺序写，所以效率很高，slave的I/O线程到主库取日志，效率也比较高，但是，slave的SQL线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的，不是顺序的，成本高很多，还可能存在slave上的其他查询产生lock争用的情况，由于SQL也是单线程的，所以一个DDL卡住了，需要执行很长一段事件，后续的DDL线程会等待这个DDL执行完毕之后才执行，这就导致了延时。当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，延时就产生了，除此之外，还有可能与slave的大型query语句产生了锁等待导致。 由于主从同步延迟是客观存在的，我们只能从我们自己的架构上进行设计， 尽量让主库的DDL快速执行。下面列出几种常见的解决方案：[list=1]

业务的持久化层的实现采用分库架构，mysql服务可平行扩展，分散压力。

服务的基础架构在业务和mysql之间加入memcache或者Redis的cache层。降低mysql的读压力；

使用比主库更好的硬件设备作为slave；

sync_binlog在slave端设置为0；

–logs-slave-updates 从服务器从主服务器接收到的更新不记入它的二进制日志。

禁用slave的binlog

 
五、参考资料
https://dev.mysql.com/doc/refman/5.7/en/replication.html  
http://www.linuxidc.com/Linux/2014-05/101450.htm  
http://blog.csdn.net/xiongping_/article/details/49907095  
http://www.cnblogs.com/martinzhang/p/3454358.html  
“本文转载自 linkedkeeper.com (文／张松然)”地址：http://www.linkedkeeper.com/detail/blog.action?bid=1028   收起阅读 »

Web框架类型

web框架的主流，是采用轻量级的中间件式框架，把网站变成只有api的一个个小服务，其他都扔到cdn之类的地方处理。

这种方式，开发快速、拼装能力强，要什么就加什么，不要的就不加，就像是乐高玩具，大受欢迎。

问题在于，这种框架有一堆，到底该选哪个。

Gin vs Echo

在golang中，这种杰出代表，有2个：gin 和 echo。

这两个框架，在同类中，路由性能最高，超出其他框架一大截。google了一大堆英文站，也没有找到这两个框架的比较。于是，在我们实际使用后，提供个比较。

先说结论：

• 如果你代表企业，最好选择gin，无痛开发。
• 如果是个人，开发个轻量服务，哪怕echo有点小问题，你也觉得没啥，那么，就用echo。

 下面是开始进行比较。

框架成熟度

gin完胜

• gin拥有详尽的出错信息，极为方便调试。
• 这非常关键。团队项目，这个更加重要。
• echo在这方面，就略微逊色。使用框架的第一天，就遇到了明明路由语法写错了，却不报错、不给结果，也没有任何提示的情况。

 

路由性能

gin微弱小胜

• gin的卖点，是所有web框架中，路由性能最好。
• echo的卖点，是它的路由性能，比gin还好10%。

 国外实际测试结果是：echo只在空路由时，性能比gin好10%。而常用的各种带参数路由，echo其实要输给gin约5-10%。echo给出和其他框架的对比 最新详尽对比：https://github.com/gin-gonic/gin/issues/329   

路由便利、灵活性

一回事，都有点小不便:

• 两个路由采用同一种算法，这种算法性能很高，但有个缺点： 不支持路由排序，会认为是路由冲突。
• 比如： 路由Get("/name")和 Get("/:id") ，一般来说，只要把Get("/name")放在Get("/:id")前面，就是不冲突的。路由模块，会先尝试匹配前面那个，没匹配上，再去匹配后面的。
• 而 gin和echo用的路由模块，会认为这两个路由是冲突的。gin会给出提醒，不让编译通过；echo完全不提醒，冲突就冲突了。。。

这给路由起名、设计，带来了一些麻烦。

框架的可持续发展

两个都不够好。

• gin的主创是2个大学生。每年寒暑假就频繁更新，快到期末考试了，就完全不更新了。两人不在的时候，有网友在帮忙热情的维护，但主要是修bug、整理中间件。框架本身的发展，还是靠主创寒暑假爆发。就是这样的框架，连csico都在用。。。
• 好在，gin的代码注释量大，易读性高，便于其他人参与。而且包装中间件，也超级容易。
• 作者本人的态度是，对于一个在github上，start达到5000+的项目，他怎么可能会不去维护。请大家放心使用，到寒暑假了，他自然会去更新。。。
• echo则是主创当前处于活跃状态，并且乐呵呵的想要开发2.0版。由于主创活跃，它自带了一些流行功能，比如websocket, http2, jwt授权。用gin的话，这些功能要自己包装个中间件，虽然也很容易就是了。
• 但echo的问题在于，它的代码毫无注释。作者现在是在劲头上，等3-6个月，在路上看到个穿超短的妹子，热情转移了，很快就会忘记当时代码是怎么写的。没有注释，不但别人不方便接手，自己也懒得再去看，于是慢慢就永不再更新。
• 缺少注释的开源包，大部分都有这个问题。echo最终会不会变成这个结局，我们无从得知。

 

总结

综上

• echo的状态是当下主创本人活跃，框架还不太成熟，适合最轻量级服务；
• gin则是整体成熟、易于调试，但可以预期，框架本身发展不会太快，除非主创大学毕业，从事和golang相关的工作。
• echo的使用方式、命名，都参考了gin，两者很接近，切换框架很容易，所以不用担心选错。

 
更新
由于echo的路由冲突频繁且没有调试信息，目前不是合理选择。等作者补上了路由冲突检测，那么就还不错。
 
如果想要回避这种框架的路由冲突，又想享受类似的优秀，neo框架目前最接近.
 
原文地址：https://www.golangtc.com/t/56a38761b09ecc083100010c  收起阅读 »

下面列举出来的一些小技巧在邮件管理员的日常中会经常用到，如果有什么错误，请留言交流。
 
打印邮件队列：

# postqueue –p

# mailq

如果队列数较大可以配合tail查看：

# mailq | tail

刷新队列：

# postqueue -f

立即为队列中domain.com的域名的邮件发送：

# postqueue -s domain.com

删除队列中所有邮件：

# postsuper -d ALL

删除一个特定的信息：

# postsuper -d messageid

重新发送特定的邮件:

# postfix -r msgid

查看postfix邮件版本：

# postconf -d mail_version

mail_version = 2.6.6

英文原文： https://techarena51.com/blog/postfix-configuration-and-explanation-of-parameters/ 

收起阅读 »

超融合基础架构，是一种将计算、网络、存储和安全等资源作为基本组成元素，根据系统需求进行选择和预定义的一种技术架构。
深信服紧密围绕客户价值需求，提出了超融合构建的企业级云方案，其在逻辑上分为两个层面：一层是云基础架构层面，通过超融合来实现，只用通用的x86服务器和二三层交换机，通过完全软件定义的方式实现云基础架构；另一层是云管平台，实现底层云基础架构和上层应用的紧密融合。
深信服致力于企业级云解决方案，并一直秉承着“利用创新云化技术，帮助客户打造极简、随需应变、平滑演进的IT新架构”的理念。深信服企业云方案兼具超融合和云管理的独特价值，是数据中心云化的最佳路径。
深信服企业级云，基础架构只有X86服务器和交换机两种设备，使得云数据中心的初始建设成本大幅下降，基于分布式架构，三台一体机就能构建资源池，系统可靠性得到有效保障，而基于模块化标准化的资源池，使建设过程变得非常简单。
云时代，超融合已成为当前云计算基础架构领域最大的热点，如何构建企业级云？最先进的超融合架构什么样？8月29日14:00“大话超融合——全融合云IT帮您轻松上云”直播活动即将开启，听听超融合领域资深专家为您指点迷津。

直播间地址：http://www.otpub.com/home/live/live/liveid/10038.html 收起阅读 »