记录与分享
Chrony 是一个开源的自由软件，它能帮助你保持系统时钟与时钟服务器同步，因此让你的时间保持精确。Chrony既可以作为时钟同步服务端，也可以作为时钟同步客户端，它由两个程序组成，分别是 chronyd 和 chronyc。
Chrony启动会监听两个端口udp 323、udp 123，udp 323监听本地服务，udp 123是我们熟知的NTP（Network Time Protocol）协议，server/client之间通过udp 123端口进行网络时钟同步，如果设置防火墙规则，放行udp 123端口就行
iptables -I INPUT -p udp -m udp -s 10.111.56.0/24 --dport 123 -j ACCEPT
今天监控信息收到一个磁盘容量告警
根据监控告警信息去相应服务器检查磁盘空间情况
使用df与du命令显示的结果不一致，/data分区主要用于应用服务部署运行，应用服务部署的tomcat服务，每天日志量增长比较大。前段时间手动清理过tomcat的历史日志，其他应用服务不存在占用磁盘空间增长太大的情况。首先想到的是日志文件在被程序打开的时候被删除了，因为之前遇到过这种情况。但是tomcat日志都是按天切割的，删除的都不是当前程序打开的文件。
还是使用lsof检查看下有没有程序打开已经被删除的文件
继续阅读“Linux下使用df与du命令磁盘容量不一致”养成对数据经常做备份是平时运维中一种良好的习惯，良好的数据备份习惯或许可以成为你生产工作中紧急情况的救命稻草。记录下工作中收集整理的数据库备份与还原的操作，这里介绍两种针对mysql数据库的备份还原方法。
mysqldump是mysql数据库官方自带对数据库进行备份还原的工具。
数据库自带不用单独找其他工具，另外因为是数据库自带工具，对数据库本身兼容性更好，特别在跨数据库版本迁移备份还原的时候推荐使用官方的mysqldump数据备份个工具。
说了优点也说下缺点，mysqldump在进行数据备份还原的时候会进行锁表操作，操作结束后又对表进行解锁。如果需要备份的数据库数据比较小还好，数据量比较大锁表时间太长对数据库的生产访问使用也存在影响。
[root@10 bin]# ./mysqldump -ugray -p -P 3308 --databases csm > /home/gray/dbbak/csm_20180118.sql
-u表示数据库用户名
-p表示数据库密码
-P表示数据库访问端口
–databases表示数据库，后面跟参数csm表示备份名叫csm的数据库
>表示输出备份数据到备份路径/home/gray/dbbak/csm_20180118.sql
生产工作环境中经常会遇到随着业务数据增长，原先磁盘分区挂载规划不能很好满足系统的长远发展，这就对前期系统磁盘规划有很高要求。但是即使你最初规划设计的在完美也无法改变磁盘空间满的那天。这时候就需要一种可动态可扩展的磁盘技术，于是就有了LVM（Logical Volume Manager）逻辑卷管理。如果你是运维linux服务器，LVM使用肯定是会接触到的。LVM的强大以及原理网上已经有很多文章介绍过，这里只做简单说明，主要记录下工作中实际的使用情况。
物理存储设备(Physical Media)：指系统的存储设备文件，比如 /dev/sda、/dev/sdb 等。
物理卷PV (Physical Volume)：一个可供存储LVM的块设备. 例如: 一块硬盘, 一个MBR或GPT分区, 一个回环文件, 一个被内核映射的设备 (例如 dm-crypt).它包含一个特殊的LVM头。
卷组 VG(Volume Group)：物理卷的一个组，作为存放逻辑卷的容器。 PEs are allocated from a VG for a LV.
逻辑卷 LV(Logical Volume)：”虚拟/逻辑卷”存放在一个卷组中并由物理块组成。是一个类似于物理设备的块设备，例如，你可以直接在它上面创建一个文件系统文件系统。
物理块 PE(Physical Extent)：一个卷组中最小的连续区域(默认为4 MiB)，多个物理块将被分配给一个逻辑卷。你可以把它看成物理卷的一部分，这部分可以被分配给一个逻辑卷。
逻辑块LE(Logical Extent)：LV(逻辑卷)中可以分配的最小存储单元称为 LE，在同一个卷组中，LE 的大小和 PE 的大小是一样的，并且一一对应。
字面上可以简单理解是从物理存储设备上抽象出一层逻辑卷进行磁盘管理，这样做的好处是不用对磁盘进行直接的重新分区，从逻辑划分的层面便可动态管理磁盘。默认情况，以下操作都是在root账号权限下操作。
继续阅读“LVM使用” 今天在整理之前系统异常事故问题时想记录下当时事故发生的情况跟解决思路。
先介绍下生产环境情况：
早上来上班是用户登录使用系统的高峰期，上班后不久就接到用户报问题反馈聊天消息发送后窗口显示空白
根据用户反馈在本地验证复现问题，验证问题确实存在查看监控系统告警信息，根据监控告警信息去检查具体服务运行情况。当检查服务运行情况时发现所有服务均运行正常，再查看监控系统告警开始解除，多人客户端发送消息验证也恢复正常。当时监控看到的告警是来自数据库服务器，为什么去检查数据库服务的时候看着运行也正常呢？又查看数据库服务器负载情况，相比平时上班高峰期负载明显更高，数据库服务器只部署了一个数据库服务，那就是找出引起数据库负载升高的原因。
继续阅读“VMware虚拟机快照对MySQL数据库备份性能的影响”2020即将过去，这一年必将被历史所铭记。各种年终总结又勾起了对这一年的回忆。从跨年的祝福演变成伴随新冠病毒的痛苦经历，本以为社会的进步、科技的发达会让我们过上科幻世界里的未来世界。然而2020又把我们拉回现实！
新一年的开始是covid-19给的，这是一种疑是SARS的新型冠状病毒。非典时期的惨痛经历还在记忆的脑海里，我们抵抗了住洪水猛兽，却被肉眼看不见的细菌病毒肆虐。当我们最终控制住SARS病毒传播时，这是科学技术的胜利，又是人类历史进步的胜利。10多年后又一波病毒来袭，面对肉眼看不到的病毒更现代的医疗技术也束手无策，人们开始恐慌，原来我们的生活除了权力、金钱、房子，社会还需要各种不同的职业岗位，医生的角色再次出现在公众视野里。
继续阅读“这一年2020”
最近服务器做了一次安全漏扫，扫描报告显示存在多处安全漏洞，其中一项是openssh版本漏洞。服务器操作系统用的红帽RHEL6.5，默认软件源openssh版本都很低存在安全风险。由于服务器运行环境不能访问外网，软件升级下载到本地手动编译安装。听同事说手动编译安装openssh比较麻烦，外网服务器使用yum方式安装没注意手动编译安装软件的困难性，因为ssh这类工具的特殊性也记录下自己的升级安装过程，本次计划openssh版本升至OpenSSH 8.0。
[root@test1 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.5 (Santiago)
[root@test1 ~]# ssh -V
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
[root@test1 ~]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
[root@test1 ~]#
查看当前版本OpenSSH_5.3p1，OpenSSL 1.0.1e-fips
继续阅读“CentOS 6升级OpenSSH”又过去了一年，又经历了一个四季春夏秋冬。年初立的一些flag明年还可以接着用，越长大越孤单，回想小时候的快乐是那么简单，天真的以为这世界可以一直“玩”下去。有父母、有亲人、有朋友、有上课总批评你的老师，有村里随处游荡的狗，每次遇到脸上嬉戏的表情总是突然凝固，有儿时收集不到又羡慕的玩具，还有一天去小伙伴家里抢着玩的游戏机……童年总是很多可玩的，每次期末老师的评语都是“贪玩！”，任性的解释这是好奇心求知欲驱使“长大想要当科学家！”。
现在长大了，离开家父母就见的少了，我妈总抱怨我野了，不会想家，不会想父母。一起长大的小伙伴现在也各奔东西。以为离开学校，离开老师就是天堂，只能说 too young，too simple！回村子时间少了，总是跟你偶遇确认过眼神的那只狗也很少见了，它现在日子过得怎么样？有没有骨头啃？还认不认识我？有没有找到其他小狗伴，还是说单身狗状态……很多玩具现在都没有了，不会再去抢着用小霸王学习机来”学习“，不用偷着躲着进游戏室，网吧上网时长不够玩就买台电脑回家自己玩，再不行选择计算机专业，投身IT队伍。当时期待的玩着电脑吃着泡面喝完最后一口汤的愿望现在算实现了，跟随互联网浪潮，能见证IT行业这些年发展，对当初选择投身这个行业感到荣幸。在新的领域总是会被人嘲笑，但总是有一批批执着愿意为此努力的人，也许他们是一群怪人，看起来跟那些光鲜亮丽总是格格不入，他们只是”贪玩“，也是因为”贪玩“才真正改变着这个世界，因为”贪玩“找回儿时纯粹的快乐，继续保持好奇心求知欲，即使长大了不能当上科技家！
首先他们无视于你，而后是嘲笑你，接着是批斗你，再来就是你的胜利之日。——圣雄甘地
明天会怎样？像1999迈入千禧之年一样让人激动还是未知？就让2020去回答吧！
2020继续做一个普通人，继续做一个对社会有贡献的人，继续做一个被这个社会所需要的人。如果被这个世界感动，不要吝啬你的泪水！最后希望在2020平安健康，找到一个什么事都想跟她分享的人，认真的！
又是从2019写到2020，总是那么拖拉……明年见。
最近服务器出现点异常，MySQL主数据库卡死导致业务受到影响，切换至从数据库后很快业务恢复正常。接着出现复制线程告警Slave_SQL_Running: No ，之前数据库服务器异常也出现过主从复制相同问题，记录下其中处理办法。
mysql> STOP SLAVE;
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
mysql> START SLAVE;
思路就是停止复制，跳过当前错误点再启动复制。
mysql> show slave status\G;
Slave_SQL_Running: Yes
Slave_IO_Running: Yes
查看复制状态，两个都显示为Yes后正常。有时候多次跳过当前错误点后还是显示 Slave_SQL_Running: No ，那就需要考虑重建主从复制关系了。
生产环境数据库使用过程中出现过几次事故，查看日志因为版本缺陷引起，最近打算升级数据库版本，由于动到数据库的东西，升级失败影响会很大，先在测试环境做升级测试。
系统：Red Hat Enterprise Linux Server release 6.5 (Santiago)
数据库：MySQL-5.7.14
由于下载的二进制压缩包方式安装，自己用的Ubuntu一直apt-get方式安装升级，一直没试过二进制压缩包版本升级，网上搜了一通升级步骤，小版本可以采取本地直接升级方式。
官网下载安装包mysql-5.7.26-linux-glibc2.12-x86_64.tar.gz
继续阅读“MySQL数据库版本升级”