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

ArchLinux搭建TimeMachine

因为netatalk在AUR仓库,所以无法直接使用pacman安装

cd /data/backup/tmp/
git clone https://aur.archlinux.org/netatalk.git
cd netatalk
makepkg -s
sudo pacman -U netatalk-3.1.12-6-armv7h.pkg.tar.xz 
sudo pacman -S avahi
sudo systemctl enable --now avahi-daemon.service

/etc/afp.conf

[Global]
;mimic model = TimeCapsule6,106
log file = /var/log/afpd.log
log level = default:info

[TimeMachine]
path = /data/backup/timemachine 
valid users = timemachine
time machine = yes
vol size limit = 500000

建立用户,目录等

sudo useradd timemachine
sudo passwd timemachine

cd /data/backup/
sudo mkdir timemachine
sudo chown -R timemachine.timemachine timemachine
sudo systemctl enable --now netatalk

参考

VirtualBox虚拟机类型选择错误引起的血案

问题症状

  1. 系统是CentOS 7 64bit
  2. 跑了10+java进程,系统load很高,可以去到100+,系统为16核CPU
  3. top查看,CPU的us time是0.2%,sys time是31.8%
  4. 此时祭出perf top,看到消耗最高的是acpipmread

解决过程

调整VirtualBox的vm配置

Googleacpi_pm_read,得出以下文章

Virtualbox 4.3.4虚拟机上面linux guest的tsc时钟源不可用,降级使用acpipm的问题(导致clockgettime函数和gettimeofday性能变差,debian内核升级等)

经过一番折腾,处理是以下3条指令

VBoxManage.exe setextradata "192.168.2.12" "VBoxnternal/TM/MaybeUseOffsettedHostTSC" 1
VBoxManage setextradata "192.168.2.12" "VBoxInternal/TM/UseRealTSC" 1
VBoxManage setextradata "192.168.2.12" "VBoxInternal/TM/TSCVirtualized" 0

由于我埋头苦干,没有留意到上文已经是考古级别,我们用的virtualbox 6.0,有2个指令已经不起作用,导致vm无法开机,通过以下指令去除配置

VBoxManage setextradata "192.168.2.12" "VBoxInternal/TM/UseRealTSC"
VBoxManage setextradata "192.168.2.12" "VBoxInternal/TM/TSCVirtualized"

此时开机,系统load不高了,但某java进程还是100%,其他java进程则80%+,由于本机是内网开发机,不应该这么高

修改VM类型

同物理机上有另外一台vm,它是正常的,最后经过排查,发现192.168.2.12选择的是windows系统,而另外一台正常的则是Linux,然后我把vm类型修改为Linux,重新开机,稳定后,系统load只有0.x

从来没有想到vm类型影响这么大

旁路路由透明代理

方案优点

需要透明代理上网的客户机不需要任何设置,网关地址都不需要改

环境

  • 主路由 华硕刷梅林固件 192.168.0.1
  • 旁路由 CubieTruck刷的ArchLinux 192.168.0.66
  • 需要透明代理上网的客户机 192.168.0.119

数据走向

192.168.0.119 -> 192.168.0.1 -> 192.168.0.66 -> 192.168.0.1

192.168.0.1设置

# 将进入table 10的数据发去192.168.0.66
ip route add default via 192.168.0.66 table 10

# 设置从192.168.0.119来的数据进入table 10
# 就是让192.168.0.119的数据发去192.168.0.66进行处理
ip rule add from 192.168.0.119/32 table 10

# 查看路由规则
ip rule show

192.168.0.66设置

# 设置数据转发
sudo sysctl -w net.ipv4.ip_forward=1

# 开启v2ray
v2ray -config config.json

# 设置防火墙
sudo /usr/sbin/iptables  -t nat -N V2RAY
sudo /usr/sbin/iptables -t nat -A V2RAY -p tcp -j REDIRECT --to-ports 1060
sudo /usr/sbin/iptables -t nat -A PREROUTING -s 192.168.0.119 -p tcp -j V2RAY

主要参考文章

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

2021年十一月
« 5月    
1234567
891011121314
15161718192021
22232425262728
2930