寻觅生命中的那一片浅草......

发布者 夜行人

Nginx备忘两例

Nginx reload会有影响长连接吗?

不会,处理长连接的worker会处于「is shutting down」的状态,这种状态是会完成已有连接,不接受新连接

另外,Nginx始终会保持配置中定义的可用worker数量,例如你定义了4个worker,就是除了上述处于「is shutting down」的进程外, 依然有4个进程

Nginx reload时CPU飙高

版本太旧导致,是1.4.x版本,nginx reload的时候会遍历所有连接引起的,连接不多的时候感觉不出来,大量的时候就很明显。cpu会飙到100%,1.9.4版本修复

感谢微信群里的朋友。

利用undrop-for-innodb恢复MySQL数据

这是一个MySQL数据恢复工具,我们尝试下恢复MySQL数据

1 环境说明

  • VMware 8H2G
  • CentOS 6.2 64bit
  • MySQL version: 5.7.17-11 Percona Server
  • 一个没有任何读写的测试数据库实例
  • innodb_file_per_table on

2 安装

比较简单

cd /dist/src
git clone https://github.com/twindb/undrop-for-innodb.git
cd undrop-for-innodb/
make
gcc `$basedir/bin/mysql_config --cflags` `$basedir/bin/mysql_config --libs` -o sys_parser sys_parser.c

3 环境准备

create database recover;
use recover;
CREATE TABLE `actor` (
  `actor_id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
  `first_name` varchar(45) NOT NULL,
  `last_name` varchar(45) NOT NULL,
  `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`actor_id`),
  KEY `idx_actor_last_name` (`last_name`)
) ENGINE=InnoDB AUTO_INCREMENT=201 DEFAULT CHARSET=utf8;

insert into actor(first_name, last_name) values('zhang', 'jian');
insert into actor(first_name, last_name) values('zhan', 'jian');
insert into actor(first_name, last_name) values('zha', 'jian');
insert into actor(first_name, last_name) values('zh', 'jian');
insert into actor(first_name, last_name) values('z', 'jian');

checksum table actor;
+-----------+------------+
| Table     | Checksum   |
+-----------+------------+
| per.actor | 2184463059 |
+-----------+------------+
1 row in set (0.00 sec)

# 此处模拟误删除表
DROP TABLE actor;

4 开始恢复

由于我们有表结构SQL了,所以本例没有恢复表结构,参考资料中有恢复表结构的操作

避免磁盘被覆盖写

由于是innodb_file_per_table on,就是drop操作会直接删除文件,此时比较稳妥的处理是关掉所有服务,将文件系统挂载为只读,由于本例是测试环境,没有任何写入,所以没有做以下处理

/etc/init.d/mysql stop
# 或者加-f参数,不过好像比较暴力
mount -o remount,ro /data

开始在磁盘上查找InnoDB页文件

本操作会在/dist/src/undrop-for-innodb/生成pages-sda5

cd /dist/src/undrop-for-innodb/

# 73G为df -h显示的sda5的总大小
# 以下指令本例大概会消耗20+小时
./stream_parser -f /dev/sda5 -s 1G -t 73G

将ibdata1分页

此操作不会影响ibdata1,会在/dist/src/undrop-for-innodb/生成pages-ibdata1

./stream_parser -f /data/database/mysql/ibdata1 

获取TABLE ID

21616为TABLE ID

./c_parser -4Df pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -t dictionary/SYS_TABLES.sql  | grep 'recover/actor'  
00000001E113    2F0000018C08A0  SYS_TABLES      "recover/actor" 21616   4       33      0       80      ""      21619

获取INDEX ID

其中36728和36729为NDEX ID

./c_parser -4Df pages-ibdata1/FIL_PAGE_INDEX/0000000000000003.page -t dictionary/SYS_INDEXES.sql  | grep '21616'
00000001E113    2F0000018C071D  SYS_INDEXES     21616   36728   "PRIMARY"       1       3       21619   4294967295
00000001E113    2F0000018C078F  SYS_INDEXES     21616   36729   "idx\_actor\_last\_name"        1       0       21619   4294967295

恢复数据

根据上面找到的INDEX ID找到对应的pages,sakila/actor.sql为建表SQL文件,好像只需要用到36728这个INDEX ID

从输出可以看到,数据找回了

./c_parser -6f pages-sda5/FIL_PAGE_INDEX/0000000000036728.page -t sakila/actor.sql
-- Page id: 3, Format: COMPACT, Records list: Valid, Expected records: (5 5)
00000001E106    A6000001D60110  actor   201     "zhang" "jian"  "2017-12-04 15:58:38"
00000001E107    A7000002D30110  actor   202     "zhan"  "jian"  "2017-12-04 15:58:38"
00000001E109    A9000002D50110  actor   203     "zha"   "jian"  "2017-12-04 15:58:38"
00000001E10B    AA000002D60110  actor   204     "zh"    "jian"  "2017-12-04 15:58:38"
00000001E10E    AC000002D80110  actor   205     "z"     "jian"  "2017-12-04 15:58:38"

5 其他

  • 大内存和读写性能好的磁盘将有效加快恢复进度

6 参考资料

MySQL · 数据恢复 · undrop-for-innodb

github-undrop-for-innodb

vmware回收vmdk空间

1 问题

我们内网有一个vmware的集群,以前年少无知,所以vmdk的格式选择了「厚置备延迟置零」,也就是分配多少,vmdk文件就会占用多大的空间,这里的好处是能提供较好的io,但我们虚拟机大部分用来做测试的,所以对io要求不高,而且实际并不需要这么大的空间,这里是第一个问题,我们需要将vmdk转换为「Thin Provisioning」,就是按需使用,并不是一开始就分配所有空间。

后来的虚拟机,我们选用了「Thin Provisioning」,部分虚拟机在一开始写了大量文件,现在不需要存了,需要回收这部分空间,这是第二个问题。

2 转换

有2个方式

vShpere Client

就是迁移虚拟机,只需要转移存储就可以了,当然也可以连主机也迁移了,原来就是在迁移选择存储时,可以在「选择虚拟磁盘格式」下拉菜单中选择「Thin Provisioning」,我感觉原理和vmkfstools是一样的,就是在迁移的过程中,做一次转换

vmkfstools

由于我没有使用此方法,直接贴参考资料好了

Cloning and converting virtual machine disks with vmkfstools (1028042)

3 回收空间

在转换的时候, 发现部分机器已经回收空间了,但有些没有自动回收,暂时不知道什么原因,下面讲下手动回收。

大概原理是先在虚拟机里标记哪些磁盘块是已经删除了,然后再通过vmkfstools进行回收

Windows虚拟机

可以用

sdelete.exe -z [DRIVE:]

Linux虚拟机

比较粗暴,用dd填满磁盘,再删除文件

由于它是填满磁盘,就是该盘会最终占用分配给它的全部空间,所以要看看该vmdk所在的物理盘是否有足够的空间

# xxx为你需要回收的磁盘挂载点
cd xxx
dd if=/dev/zero of=zeroes bs=4096 || rm -f zeroes

开始回收

经过上面2种虚拟机的处理后,就可以ssh到vmware物理机上进行回收

此处注意,vmkfstools要用xxx.vmdk,不要用xxx-ctk.vmk,也不要用xxx-flat.vmdk

# 处理前确认大小
du -h xxx-flat.vmdk
vmkfstools -K xxx.vmdk
# 处理后确认大小
du -h xxx-flat.vmdk

处理完后,在「vShpere Client」中,可以选择「刷新存储使用情况」来获取最新的使用情况

4 注意

磁盘有价,数据无价,请操作前做好备份,操作的时候,再三确认

5 参考资料

PostgreSQL简介

怎么用了PostgreSQL?

PostgreSQL,在国内应该是没有MySQL那么流行,但对它的介绍,通常是和Oracle比,我们也只在2个地方用了:

  1. Zabbix,一开始是MySQL,后来agent端出现很多unreachable,才用了PostgreSQL,但换数据库并没有解决问题,最后是采用了表分区才解决了
  2. 大数据,CDH这个Hadoop发行版,默认使用的是PostgreSQL 8.4(2009年发行),有几个数据库连接 ,长期占用CPU达50%,花了点时间去看,但最终也没有解决。而且版本太旧,目前搜到的资料,都不太适用

安装

官方提供了各系统,各版本的rpm包,直接yum或者rpm即可

rpm -ivh https://download.postgresql.org/pub/repos/yum/9.3/redhat/rhel-6-x86_64/pgdg-centos93-9.3-3.noarch.rpm
yum -y install libxslt uuid
yum -y install postgresql93-server postgresql93-contrib postgresql93-libs postgresql93

上面的安装可能会提示证书有问题,此时可以去看看yum仓库的地址,然后手动wget回来安装即可

grep baseurl /etc/yum.repos.d/pgdg-93-centos.repo 

初始化和连接

# 初始化数据,数据库文件目录在/var/lib/pgsql/9.3/data/
/etc/init.d/postgresql-9.3 initdb

# 启动
/etc/init.d/postgresql-9.3 start

连接

# 以系统用户连接
# 连接,切换到postgres,然后就可以直接连接了
su - postgres
psql
# 通过用户密码连接,只能通过环境变量指定密码
PGPASSWORD=xxx /usr/bin/psql -U zabbix
# 把连接信息写到文件
cat /root/.pgpass
localhost:5432:*:test_user:user_password
# 通过指定用户名即可连接 
psql -U test_user

认证

它和MySQL一样,也是基于用户和主机进行认证的,配置文件如下,就是和数据在一起

# 修改此文件
# 需要以root身份进行reload:/etc/init.d/postgresql-9.3  reload

/var/lib/pgsql/9.3/data/pg_hba.conf

文件内容

# "local" is for Unix domain socket connections only
# 类型 数据库             用户           地址          认证方式
local   all             all                        peer
# IPv4 local connections:
host    all             all       127.0.0.1/32   ident
host    replication     replica     192.168.8.198/32    md5

认证类型

local的话,就是不指定主机名或者指定主机名为localhost,它默认使用unix socket进行连接/tmp/.s.PGSQL.5432,5432会随着监听端口改变,例如改为7432,则socket文件名就会变成/tmp/.s.PGSQL.7432

其他的就是通过host:port这样的tcp方式访问

认证方式

数据库和用户没什么要说的,这里讲下认证方式

  • ident,就是用PostgreSQL所在机器的系统用户,例如上面提到的切换到postgres用户,当系统用户和PostgreSQL里的用户名一致,就可以连接
  • peer,和ident一样,只是它是在客户端系统进行识别
  • md5,就是密码认证
  • trust,只验证主机,不验证用户名和密码
  • password,这个没去了解

使用

以下指令为输入psql进入PostgreSQL控制台输入

\?:
    打印PostgreSQL帮助
\h:
    打印SQL帮助
\c   :  
    可以通过\c databasename  切换数据库
\l    :
    数据库列表的详细信息
\q   :
    退出数据库
\d或\dt:
      该数据库下所有表的详细信息
\d  tablename:
      该表的表结构
\df 
    打印函数
\df+ partition_every_day
    打印partition_every_day的信息
\du
    列出所有用户

alter user postgres with password 'xxx'
    修改用户名密码 
      

以下指令在系统终端执行

# 创建数据库
createdb test_db

# 备份数据库,dumpall为备份所有库
pg_dump/pg_dumpall

# 备份结构
pg_dump --schema-only

# 执行sql文件

psql -f xxx.sql

schema

目前我无法说清楚这是什么东西,大概理解为是一种隔离机制吧,默认只有$userpublic,如果你的表有分区,那么你虽然在打印的时候可以看到,但你要drop分区的时候,则会提示找不到

# 显示Schema的搜索路径
SHOW search_path;

# 从上面的输出可以看出,默认没有partitions,我们加入,如果不加入,在drop table的时候,就会提示does not exist
SET search_path TO "$user",partitions,public;

# 可以drop了,CASCADE的作用是把关联的触发条件删除,这触发条件,其实就是什么数据应该插入此分区的,现在已经是2017了,自然不会有2015的数据需要插入,所以可以放心删除
drop table history_uint_2015_01_11 CASCADE;

# 当然也可以不用设置,直接加partitions前缀

drop table partitions.history_uint_2015_01_11 CASCADE;

性能

  • shared_buffers,缓存最近查询的数据页,设置为系统内存的25%,但不应该超过8G
  • effective_cache_size,单次查询可用缓存,如果是专门的PostgreSQL服务器,设置为系统总内存一半
  • work_mem,用于排序、表扫描、哈希关联等操作的最大内存量,如果是多用户并发进行简单查询,那么此设置很小也没有问题,如果执行复杂查询,可以调大
  • maintenance_work_mem,用于vaccum(回收内存和磁盘空间)操作的内存总量。不应该大于1G。

一些工具

pgAdmin

是PostgreSQL官方的图形界面管理客户端

  • 版本3可以管理PostgreSQL 8.4
  • 版本4可以管理PostgreSQL 9.x

pgsniff

从网络流量中提取SQL,测试支持9.3版本,8.4版本不支持

# 最后一个-,意思是输出到终端
pgsniff -d eth1 -l -

还有一个叫pgshark,没测试

书籍

  • PostgreSQL 9 Admin Cookbook,有中文版
  • PostgreSQL即学即用
  • PostgreSQL 9.0性能调校,一定不要看中文版

shadowsocket和ipset实现科学上网

1. 背景

我们有了专线接入的,而基于shadowsocket,网上的资料已经无法访问了,经过一翻摸索,终于又还原出来

2. 使用原有软件

上面专线版本,我们已经安装了一些软件,这里可以继续用

  • dnsmasq
  • pdnsd

3. shadowsocket配置

服务器端已经有了,这里讲下客户端,CentOS 6安装shadowsocket 3.x比较麻烦,这里安装2.x的

配置yum源

sudo cat > /etc/yum.repos.d/librehat-shadowsocks.repo <<EOF
[librehat-shadowsocks]
name=Copr repo for shadowsocks owned by librehat
baseurl=https://copr-be.cloud.fedoraproject.org/results/librehat/shadowsocks/epel-6-$basearch/
type=rpm-md
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://copr-be.cloud.fedoraproject.org/results/librehat/shadowsocks/pubkey.gpg
repo_gpgcheck=0
enabled=1
enabled_metadata=1
EOF

安装

sudo yum install shadowsocks-libev

连接shadowsocket

# 下面需要以root身份运行,主要是ulimit
ulimit -SHn 65535
# -v参数为输出详细信息,在debug的时候有用
# 要用ss-redir才行,ss-local不支持iptables REDIRECT的方式
su - ssproxy bash -c "ss-redir -s ss_svr_ip -p 58000 -k abc_pass -m aes-256-cfb -l 1080 -b 0.0.0.0 -v"

4. 设置dnsmasq

sudo cat > /data/conf/dnsmasq/ss_kexue.conf <<EOF
server=/facebook.com/127.0.0.1#1053
ipset=/facebook.com/ss_kexue
EOF
# 另外需要修改dnsmasq.conf,让它包含ss_kexue.conf,并重启dnsmasq

5. 设置ipset

# 新增hash表
sudo /usr/sbin/ipset -N ss_kexue iphash
# 添加facebook的ip倒表里
sudo ipset add ss_kexue facebook_ip
# 从旧的hash表里移除
sudo ipset del kk_kexue facebook_ip

6. 设置iptables

# 需要写到配置文件
sudo iptables -t nat -A PREROUTING -p tcp -m set --match-set ss_kexue dst -j REDIRECT --to-port 1080
sudo iptables -A RH-Firewall-1-INPUT -s 192.168.0.0/16 -p tcp --dport 1080 -j ACCEPT
sudo iptables -A RH-Firewall-1-INPUT -s 172.16.28.0/23 -p tcp --dport 1080 -j ACCEPT

好了,现在应该可以了

参考资料

2018年八月
« 2月    
 12345
6789101112
13141516171819
20212223242526
2728293031