那些年/那些事

========================= 配置环境 =加速bbr命令：   wget -N --no-check-certificate "https://raw.githubusercontent.com/chiakge/Linux-NetSpeed/master/tcp.sh" && chmod +x tcp.sh && ./tcp.sh 我的blog用的是这个 wget -N --no-check-certificate "https://gist.github.com/zeruns/a0ec603f20d1b86de6a774a8ba27588f/raw/4f9957ae23f5efb2bb7c57a198ae2cffebfb1c56/tcp.sh" && chmod +x tcp.sh && ./tcp.sh 然后命令 reboot 3.安装成功，重启VPS之后我们重新连接服务器。输入下列指令来启用其BBR plus。 ./tcp.sh 第三步：验证bbr是否已经开启 1、输入 sysctl net.ipv4.tcp_available_congestion_control 如果返回 net.ipv4.tcp_available_congestion_control = reno cubic bbr 则安装 成功 2、输入 lsmod | grep bbr 如果返回 tcp_bbr 20480 2 则安装成功 ============ Google BBR 是一款免费开源的TCP拥塞控制传输控制协议, 可以使 Linux 服务器显著提高吞吐量和减少 TCP 连接的延迟。 项目地址: https://github.com/google/bbr CentOS开启BBR 第一步： 1、yum系统更新 yum update 2、查看系统版本 cat /etc/redhat-release 输出如下则表示已升级到7.6 CentOS Linux release 7.6.1810 (Core) 3、安装elrepo并升级内核 rpm -- import https : / / www . elrepo . org / RPM - GPG - KEY -

  对于博主而言，除了研究原创文章和拓展流量之外，最重要的就是WordPress备份了。 回想起很久很久以前，在使用虚拟主机建站时，博主根本就没做过备份。 原因主要有两点： 一是因为当时用WordPress建站只是一种简单的爱好，对博客的重要性认识不足；二是知识欠缺，脑子里压根就没有备份这根弦。 直到有一天，悲剧来了。。 不知道此刻正在看文章的你是否也和博主一样，忍受不了管理后台的WordPress更新提示。每次看到有更新的插件，总忍不住去升级。 一般来说，为了系统安全，插件和主题升级到最新版本是推荐的，有时候也是必需的。 但这往往会忽略一个重要问题，就是兼容性。 这包括两个方面：插件和主机系统的兼容性，以及插件和插件之间的兼容性。 比如，某个插件旧的版本是用PHP5.X写的，新版本则是用PHP7.X写的，而你的主机系统使用的是PHP5.X，升级后则可能就会出现不兼容。 或者，一个插件升级后和另一个或几个插件运行时有冲突，同样会导致不兼容。 不兼容的后果就是： 网站打不开！ （ 500 Internal Server Error ） 是不是有点眼熟？ 于是，那天我登入WordPress后台，在升级了几个插件之后，网站突然就显示500错误了。 当时博主的建站知识非常有限，只能去找虚拟主机商家解决。 一封接着一封的工单，耗费了差不多一整天的时间，最后主机商答应可以限时下载他们自己备份的网站数据。 但是，这个数据是十几天前的。因为他们只提供每半月一次的WordPress整站备份。 好在博客更新并不频繁，而且后续网站恢复也很顺利，所以丢失的数据并不算多。但是，这仍然让博主感觉非常不愉快，并且直到现在，想起来多少还有些后怕。 （现在看来，其实当时并不需要那么麻烦，只要把插件目录一个一个的改名再启用，然后找出异常插件并将其停用就可以了。） 从这件事上，博主学到了两点教训： ①WordPress整站数据一定要经常备份 ； ②插件一定不要着急升级，最好等一段时间（比如半个月）后再升级，并且升级前做好整站备份和SnapShot快照备份（如果你的VPS支持的话） 。 所以，自那之后，博主所有的网站都会每周备份至少两次。 起初是通过手动备份，压缩整站数据并导出数据库，保存在服务器上，同时下载到电脑里。 后来，随着博主对Linux命令的日益熟练，发现在WordPress备份过程中，很多手动