Suzf Blog

一直觉得如果写成系列的技术文章，用 wp 显得有点力不从心。最近 GitBook 也是不错的。
翻到一年多前，茫然想起自己曾经耍过 DokuWiki, 那么便拿出来耍耍吧。毕竟时间太久远了。
自己设置的密码已经抛在脑后了。也懒得想了，重置密码吧。简单粗暴有疗效。

后期会在网站中考虑 加入 wiki 或者 gitbooks, 欢迎小伙伴们前来围观。

dokuwiki 管理员默认用户名: admin
如果采用简单验证方法，用资料存储在文件中，第二列即为密码的 hash值.

cat conf/users.auth.php
# users.auth.php
# <?php exit()?>
# Don't modify the lines above
#
# Userfile
#
# Format:
#
# login:passwordhash:Real Name:email:groups,comma,seperated


lucy:$6$hdLEXRS9$X4lQKUDKoCnk9ubS.XPKR1:Lucy:[email protected]:admin,user



^_^[13:38:12][[email protected] tmp]#cat crypt_test.php 
<?php
// 设置密码
$password = 'yourpassword';

// 获取散列值,使用自动盐值
$hash = crypt($password);
echo "password: $password\n";
echo "hash: $hash\n";

?>

^_^[13:38:16][[email protected] tmp]php crypt_test.php 
password: yourpassword
hash: $1$rtfdScJg$uQh7Dl6bFFwgtI6iWDkcv.

将旧的hash 值替换为新的hash 就可以从新登录了。
同级目录下有 ./conf/acl.auth.php 文件是用来控访问权限的。

摘要

在Elasticsearch中节点可以分为主(master)节点，数据(data)节点，客户端节点和部落节点，每种类型的节点有不同的使用方法，对于一个大的集群中，合理的配置这些属性，对集群的健壮性和性能有很大的帮助。

节点类型

当我们启动Elasticsearch的实例，就会启动至少一个节点。相同集群名的多个节点的连接就组成了一个集群，在默认情况下，集群中的每个节点都可以处理http请求和集群节点间的数据传输，集群中所有的节点都知道集群中其他所有的节点，可以将客户端请求转发到适当的节点。节点有以下类型：

• 主(master)节点：在一个节点上当node.master设置为True（默认）的时候，它有资格被选作为主节点，控制整个集群。
• 数据(data)节点：在一个节点上node.data设置为True（默认）的时候。该节点保存数据和执行数据相关的操作，如增删改查，搜索，和聚合。
• 客户端节点：当一个节点的node.master和node.data都设置为false的时候，它既不能保持数据也不能成为主节点，该节点可以作为客户端节点，可以响应用户的情况，并把相关操作发送到其他节点。
• 部落节点： 当一个节点配置tribe.*的时候，它是一个特殊的客户端，它可以连接多个集群，在所有连接的集群上执行搜索和其他操作。

默认情况下，节点配置是一个主节点和一个数据节点。这是非常方便的小集群，但随着集群的发展，分离主节点和数据节点将变得很重要。

tcpdump 是一个运行在命令行下的嗅探工具。它允许用户拦截和显示发送或收到过网络连接到该计算机的TCP/IP和其他数据包。tcpdump 是一个在BSD许可证下发布[2]的自由软件。

tcpdump 适用于大多数的类Unix系统 操作系统：包括Linux、Solaris、BSD、Mac OS X、HP-UX和AIX 等等。在这些系统中，tcpdump 需要使用libpcap这个捕捉数据的库。其在Windows下的版本称为WinDump；它需要WinPcap驱动，相当于在Linux平台下的libpcap.

用途

tcpdump能够分析网络行为，性能和应用产生或接收网络流量。它支持针对网络层、协议、主机、网络或端口的过滤，并提供and、or、not等逻辑语句来帮助你去掉无用的信息，从而使用户能够进一步找出问题的根源。

也可以使用 tcpdump 的实现特定目的，例如在路由器和网关之间拦截并显示其他用户或计算机通信。通过 tcpdump 分析非加密的流量，如Telnet或HTTP的数据包，查看登录的用户名、密码、网址、正在浏览的网站内容，或任何其他信息。因此系统中存在网络分析工具主要不是对本机安全的威胁，而是对网络上的其他计算机的安全存在威胁。[3]

背景

在写压力负载比较重的MySQL实例上，InnoDB可能积累了较长的没有被purge掉的transaction history，导致实例性能的衰减，或者空闲空间被耗尽，下面就来看看它是怎么产生的，或者有没有什么方法来减轻，避免这样的问题出现。

InnoDB purge 概要

InnoDB是一个事务引擎，实现了MVCC特性，也就是在存储引擎里对行数据保存了多个版本。在对行数据进行delete或者update更改时，行数据的前映像会保留一段时间，直到可以被删除的时候。

在大部分OLTP负载情况下，前映像会在数据操作完成后的数秒钟内被删除掉，但在一些情况下，假设存在一些持续很长时间的事务需要看到数据的前映像，那么老版本的数据就会被保留相当长一段时间。

虽然MySQL 5.6版本增加了多个purge threads来加快完成老版本数据的清理工作，但在write-intensive workload情况下，不一定完全凑效。

准备工作

Mysql 单机多实例详解 What is the GTID of the replication

实验环境

Os: CentOS 6.X Mysql: 5.6 单机多实例 [3306,3307] Hostname: lab.suzf.net

场景一：新机器 无数据

对于GTID的配置，主要修改配置文件中与GTID特性相关的几个重要参数

GTID是一个基于原始mysql服务器生成的一个已经被成功执行的全局事务ID，它由服务器ID以及事务ID组合而成。这个全局事务ID不仅仅在原始服务器器上唯一，在所有存在主从关系 的mysql服务器上也是唯一的。正是因为这样一个特性使得mysql的主从复制变得更加简单，以及数据库一致性更可靠。本文主要描述了快速配置一个基于GTID的主从复制架构，供大家参考。

一、GTID的概念

1、全局事务标识：global transaction identifiers。
2、GTID是一个事务一一对应，并且全局唯一ID。
3、一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
4、GTID用来代替传统复制方法，不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制。而是使用MASTER_AUTO_POSTION=1的方式开始复制。
5、MySQL-5.6.5开始支持的，MySQL-5.6.10后开始完善。
6、在传统的slave端，binlog是不用开启的，但是在GTID中slave端的binlog是必须开启的，目的是记录执行过的GTID（强制）。

二、GTID的组成

GTID = source_id:transaction_id
source_id，用于鉴别原服务器，即mysql服务器唯一的的server_uuid，由于GTID会传递到slave，所以也可以理解为源ID。
transaction_id，为当前服务器上已提交事务的一个序列号，通常从1开始自增长的序列，一个数值对应一个事务。
示例：
3E11FA47-71CA-11E1-9E33-C80AA9429562:23
前面的一串为服务器的server_uuid，即3E11FA47-71CA-11E1-9E33-C80AA9429562，后面的23为transaction_id

三、GTID的优势

1、更简单的实现failover，不用以前那样在需要找log_file和log_pos。
2、更简单的搭建主从复制。
3、比传统的复制更加安全。
4、GTID是连续的没有空洞的，保证数据的一致性，零丢失。

四、GTID的工作原理

1、当一个事务在主库端执行并提交时，产生GTID，一同记录到binlog日志中。
2、binlog传输到slave,并存储到slave的relaylog后，读取这个GTID的这个值设置gtid_next变量，即告诉Slave，下一个要执行的GTID值。
3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有该GTID。
4、如果有记录，说明该GTID的事务已经执行，slave会忽略。
5、如果没有记录，slave就会执行该GTID事务，并记录该GTID到自身的binlog，
在读取执行事务前会先检查其他session持有该GTID，确保不被重复执行。
6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

节选自： 乐沙弥的世界

 

必填配置参数

clientPort

该端口监听客户端的连接。也就是说，客户端都会尝试连接该端口。

dataDir

该路径用于存储zookeeper内存数据库快照。除非有特殊设定，否则也会存储数据库更新的事物日志。事物日志的存放位置是很有讲究的。有一台专门用于存放事物日志的设备，可以产生持久的高性能。讲日志放在高负荷的设备上，会对性能产生副作用。

tickTime

一个心跳的长度，它是zookeeper毫秒级的一个基本时间单位。它用来设定心跳间隔和超时时间。例如，最小会话超时时间是两倍的心跳长度。

可选配置参数

dataLogDir

这个选项指定将事物日志存储于该路径，代替了dataDir。目的是可以用专门的设备来存储日志，这样可以避免日志和快照的资源竞争。有一个专门的 日志存储设备，可以导致高的吞吐量和稳定性。我们更推荐使用一台专用日志设备并用dataLogDir在该设备上指定目录来存放日志，这样可以保证 dataDir指定的目录不在该设备上(dataDir指定存放快照的目录，快照和日志会竞争资源)。

globalOutstandingLimit(java:zookeeper.globalOutstandingLimit)

客户端提交请求的速度可能会超过zookeeper处理请求的速度，尤其是存在大量的客户端。为了避免由于排队的请求导致的内存溢 出，zookeeper将会对客户端进行限流，将请求的数量保持在globalOutstandingLimit以下。 globalOutstandingLimit的默认值是1000。

preAllocSize(java:zookeeper.preAllocSize)

zookeeper将事务日志文件分割成preAllocSize kb大小的模块，这样可以避免查询带来的消耗。默认的模块大小是64M。当快照频繁产生时，我们可以肩上模块的大小来提高系统的效率(这段好难翻译，还不知道对不对)。

snapCount(java:zookeeper.snapCount)

zookeeper将所有事务记录到日志中。当记录了snapCount数量的事务后，会生成新的快照和事务日志文件。snapCount默认值是100000。

traceFile(Java:requestTraceFile)

如果使用该选项，我们会将请求记录在追踪文件中，并将其以traceFile.year.month.day格式命名。这个选项可以提供调试信息，但会影响性能。

maxClientCnxns

一个客户端的最大并发连接数(接口级别)，每台客户端用IP地址区分，成为zookeeper总体中的一个成员(貌似翻译的不对)。它用来防止某些DoS攻击，包括文件描述符耗尽(不懂-_-||)。默认值是60。将其设定为0，则取消并发连接数的限制。

clientPortAddress

监听客户端连接的地址(ipv4,ipv6,hostname)，也就是说，客户端会尝试连接该地址。可选配置，默认情况下，客户端都会连接到clientPort上(address,interface,nic)。

minSessionTimeout

最小会话超时时间(毫秒级)，默认是2倍的tickTime。

maxSessionTimeout

最大会话超时时间(毫秒级)，默认是20倍的tickTime。(在代码中会设置超时时间，但是必须在这里设定的最小与最大值之间，否则直接取最小/最大值)

fsync.warningthresholdms(java:fsync.warningthresholdms)

当日志中的fsync函数超出了该值的长度，就会在日志出输出警告信息。默认值是1000(毫秒级)，是系统属性。

autopurge.snapRetainCount

当启用时，zookeeper将自动储存最近autopurge.snapRetainCount次的快照和事务日志，分别放在dataDir和dataLogDir中，其余部分将被删除。默认值是3，最小值是3。

autopurge.purgeInterval

设置该定时器，能定时触发净化任务(清理快照和日志)，单位为小时，值为大于等于1的正整数，默认值是0。

集群选项

electionAlg

作用是实现选举。0是基于UDP的传统版本，1是基于未认证UDP的快速选举版本，2是基于已认证UDP的快速选举版本，3是基于TCP的快速选举版本。默认值是3。(0/1/2已经不建议使用，在下个版本准备取消)

initLimit

在心跳连接中，允许followers连接leader和与leader同步数据的时间。如果zookeeper管理的数据比较大，可以增加此值。

leaderServes(zookeeper.leaderServes)

leader接受客户端的连接。默认值是“yes”。leader主机的坐标更新。要实现使用很少的读取量而达到更高的更新量，leader可以不 接受客户端的连接而是只专注于负载的均衡。默认值是“yes”，就是可以接受连接。(当集群中存在3台以上的zookeeper服务端时，推荐使用 “no”)

server.x=[hostname]:nnnnn[:nnnnn]，etc

配置的服务端组成zookeeper集群。集群启动时，将在配置的服务端上寻找myid文件。该文件包含服务器编号，于server.x中的x值相匹配。

每台zookeeper服务器都持有这个服务器列表，客户端必须根据这个列表进行连接。

配置中还存在两个端口号nnnnn。第一个端口号用于follower连接leader，第二个端口号用于leader的选举。当electionAlg=1,2,3时，选举端口是必要的。当=0时，不是必要的。加入想要在单机上测试集群，可以使用不同端口号来模拟。

syncLimit

在心跳连接中，允许followers同步zookeeper数据的时间。如果followers与leader长久失去连接，它将被丢弃。

group.x=nnnnn[:nnnnn]

实现一个分层的法定人数的构造。“x”是组的标识，“=”后边是服务器的标识。

例：group.2=4:5:6
group.3=7:8:9

weight.x=nnnnn[:nnnnn]

要与group搭配使用，为服务器设置一个比重。这个比重就是选举投票时一台服务器的比重。group.1=1:2:3

例：weight.1=1
weight.2=1
weight.3=1
weight.4=1
weight.5=1
weight.6=1
weight.7=1
weight.8=1
weight.9=1

cnxTimeout

leader选举的超时时间，electionAlg=3时才起作用。默认值是5秒。

原文地址：http://zookeeper.apache.org/doc/r3.4.5/zookeeperAdmin.html

来源： 静静的小猪

 

入门：分布式应用程序协调服务 ZooKeeper

本文档包含的信息来帮助你的ZooKeeper快速入门。它是在开发人员希望能够尝试一下主要目的，并包含安装简单说明一个ZooKeeper的服务器，几个命令，以验证它是否正在运行，一个简单的编程示例。最后，为了方便，还有更多的关于安装复杂，几节，例如运行复制的部署和优化事务日志。然而，对于商业部署的完整说明，请参阅的ZooKeeper管理员指南。

ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。 Zookeeper是hadoop的一个子项目，其发展历程无需赘述。在分布式应用中，由于工程师不能很好地使用锁机制，以及基于消息的协调机制不适合在 某些应用中使用，因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。Zookeeper的目的就在于此。本文简单分析 zookeeper的工作原理，对于如何使用zookeeper不是本文讨论的重点。