cassandra修复损坏的sstables
由于磁盘阵列Unreadable Sectors错误,强制修复后导致cassandra的一个sstable损坏,cassandra启动时报错:
1 | ERROR \[CompactionExecutor:2\] 2019-07-15 15:03:27,161 DefaultFSErrorHandler.java:92 - Exiting forcefully due to file system exception on startup, disk failure policy "stop" |
lb-47344-big-Data.db这个sstable被破坏了。
因为节点已经无法启动了,所以下面的尝试无可避免的失败了
1 | $ nodetool scrub |
尝试离线修复,如果数据量很大,记得开启screen会话
1 | $ sudo -u cassandra sstablescrub reis image |
注意cassandra数据目录的权限,这里使用cassandra用户来执行scrub
执行结束后,删除掉已经损坏的sstable,scrub时cassandra会将损坏的sstable保持原样
1 | $ sudo mv lb-47344* backups/ |
启动cassandra
1 | $ sudo systemctl start cassandra |
确认系统运行正常
1 | $ nodetool status |
之后可以删除sstablescrub自动创建的快照,释放掉已经无用的sstables
1 | $ nodetool clearsnapshot |
最后需要repair本节点,修复节点数据
1 | $ nodetool repair -local -- reis image |
References:
[1]sstablescrub
[2]Dealing with a corrupt SSTable in Cassandra
[3]So You Have A Broken Cassandra SSTable File?
DS5020存储Unreadable Sectors故障修复
一台IBM DS5020(1814-20 FAStT) RAID5存储阵列,OS报错误:
1 | \[ 274.331664\] sd 4:0:0:0: \[sdc\] tag#5206 Add. Sense: Unrecovered read error |
连上存储,有报警信息:
1 | Failure Entry 1: USM_UNREADABLE_SECTORS_EXIST-Recovery Failure Type Code: 75 |
有两个不可读取的扇区,可以进一步看到这两个扇区位于哪个磁盘驱动器,这种故障一般就是硬盘不稳定了,该换就换吧。
存储管理EMW(Enterprise Manage Window)窗口找到存储阵列,右击弹出context菜单中选择“Exectute script…”
脚本窗口中执行:
1 | show storageArray unreadableSectors; |
结果窗口输出:
1 | Executing script... |
可以看到这两个扇区的详细状况,然后继续执行命令清除这两个扇区
1 | clear allVolumes unreadableSectors; |
最后重新查看
1 | show storageArray unreadableSectors; |
可以看到已经没有不可读取的扇区了,阵列的报警灯也恢复正常。
注意,那两个扇区的数据应该是丢失了,应用程序如果需要这些数据应该通过其他途径恢复数据。
debian buster安装wine-devel
wine是个伟大的工程。
wine有三个分支wine-stable,wine-devel和wine-staging,就好像debian的三个分支stable,testing和sid,devel分支其实很稳定的,也能支持更多的应用程序
但是debian buster上安装wine-devel出现依赖问题:
1 | wine-devel : Depends: wine-devel-amd64 (= 4.12.1~buster) but it is not going to be installed |
从wine4.5开始,wine-devel依赖libfaudio0,但是debian官方源并没有提供这个包,因此可以从参考[2]给出的链接下载amd64和i386两个架构的安装包libfaudio0_19.07-0_buster_amd64.deb和libfaudio0_19.07-0_buster_i386.deb
并手工安装
1 | $ sudo dpkg -i libfaudio0_19.07-0_buster_amd64.deb |
然后再安装wine-devel
1 | $ sudo apt -y install wine-devel |
注意wine-devel安装到/opt/wine-devel目录,因此要使用wine-devel需要在.bashrc中添加
1 | export PATH=/opt/wine-devel/bin:$PATH |
References:
[1]Installing WineHQ packages
[2]FAudio for Debian and Ubuntu
xterm on gnome wayland
debian buster gnome桌面默认启用wayland,当前仍然可以切换回Xorg
wayland兼容性还是有一些小问题,wayland并不加载profile环境配置文件,
也不理会Xsession,导致.xinitrc,.Xresources等无法加载
系统及用户的Xresources是由/etc/X11/Xsession.d/30x11-common_xresources脚本加载的,在wayland面前失效了,直接后果就是每次重启机器xterm就会被打回原形,只能手工重新加载~/.Xresources
回到gnome on xorg则xterm恢复正常
发现一个跨平台GPU加速的terminale emulator alacritty看起来很不错,可以试用一番。
References:
[1]GNOME, Wayland, and environment variables
transfer.sh快速分享文件
transfer.sh可以使用命令行快速的分享文件,最大可以上传10G,有效期最长14天,也可以设定下载次数和有效期。
上传文件
1 | $ curl --upload-file ./go.sh https://transfer.sh/go.sh |
设定下载次数和最大天数
1 | $ curl -H "Max-Downloads: 1" -H "Max-Days: 5" --upload-file ./hello.txt https://transfer.sh/hello.txt |
添加.bashrc命令行别名
1 | transfer() { |
然后可以这样
1 | $ transfer hello.txt |
是不是很简单,很好用,但是,不要用来传输敏感文件,传输敏感文件请使用onionshare或加密后再传输。
还有一点儿要注意,github上的tansfer.sh项目与http://transfer.sh网站并无关系。
References:
[1]Easy and fast file sharing from the command-line
oh OnionShare
OnionShare是一个安全匿名的开源文件分享工具,可以使用它在本地机器通过tor网络发布共享服务,生成一个不可猜测的onion地址,通过这个地址其他人可以使用tor browser来获取分享的文件。只要生成的onion地址没有泄露,文件就是安全的。文件传输的过程不会被任何第三方窃取。
安装
1 | $ sudo apt install onionshare |
分享文件
1 | $ onionshare go.sh |
获取文件
将生成的连接通过安全路径发送,然后在tor browser中打开连接即可,简单可靠又安全,美中不足,速度慢慢慢。