So Tired !_! 逆水行舟, 不进则退!

MySQL的binlog日志

binlog 基本认识
MySQL的二进制日志可以说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。

一般来说开启二进制日志大概会有1%的性能损耗(参见MySQL官方中文手册 5.1.24版)。二进制有两个最重要的使用场景:
其一：MySQL Replication在Master端开启binlog，Mster把它的二进制日志传递给slaves来达到master-slave数据一致的目的。
其二：自然就是数据恢复了，通过使用mysqlbinlog工具来使恢复数据。

二进制日志包括两类文件：二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件，二进制日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查询语句)语句事件。
一、开启binlog日志：
vi编辑打开mysql配置文件
# vi /usr/local/mysql/etc/my.cnf
在[mysqld] 区块
设置/添加 log-bin=mysql-bin 确认是打开状态(值 mysql-bin 是日志的基本名或前缀名)；

重启mysqld服务使配置生效
# pkill mysqld
# /usr/local/mysql/bin/mysqld_safe --user=mysql &
二、也可登录mysql服务器，通过mysql的变量配置表，查看二进制日志是否已开启 单词：variable[ˈvɛriəbəl] 变量

登录服务器
# /usr/local/mysql/bin/mysql -uroot -p123456

mysql> show variables like 'log_%';
+----------------------------------------+---------------------------------------+
| Variable_name | Value |
+----------------------------------------+---------------------------------------+
| log_bin | ON | ------> ON表示已经开启binlog日志
| log_bin_basename | /usr/local/mysql/data/mysql-bin |
| log_bin_index | /usr/local/mysql/data/mysql-bin.index |
| log_bin_trust_function_creators | OFF |
| log_bin_use_v1_row_events | OFF |
| log_error | /usr/local/mysql/data/martin.err |
| log_output | FILE |
| log_queries_not_using_indexes | OFF |
| log_slave_updates | OFF |
| log_slow_admin_statements | OFF |
| log_slow_slave_statements | OFF |
| log_throttle_queries_not_using_indexes | 0 |
| log_warnings | 1 |
+----------------------------------------+---------------------------------------+

三、常用binlog日志操作命令
1.查看所有binlog日志列表
mysql> show master logs;

2.查看master状态，即最后(最新)一个binlog日志的编号名称，及其最后一个操作事件pos结束点(Position)值
mysql> show master status;

3.刷新log日志，自此刻开始产生一个新编号的binlog日志文件
mysql> flush logs;
注：每当mysqld服务重启时，会自动执行此命令，刷新binlog日志；在mysqldump备份数据时加 -F 选项也会刷新binlog日志；

4.重置(清空)所有binlog日志
mysql> reset master;
四、查看某个binlog日志内容，常用有两种方式：

1.使用mysqlbinlog自带查看命令法：
注: binlog是二进制文件，普通文件查看器cat more vi等都无法打开，必须使用自带的 mysqlbinlog 命令查看
binlog日志与数据库文件在同目录中(我的环境配置安装是选择在/usr/local/mysql/data中)
在MySQL5.5以下版本使用mysqlbinlog命令时如果报错，就加上 “--no-defaults”选项

# /usr/local/mysql/bin/mysqlbinlog /usr/local/mysql/data/mysql-bin.000013
下面截取一个片段分析：

...............................................................................
# at 552
#131128 17:50:46 server id 1 end_log_pos 665 Query thread_id=11 exec_time=0 error_code=0 ---->执行时间:17:50:46；pos点:665
SET TIMESTAMP=1385632246/*!*/;
update zyyshop.stu set name='李四' where id=4 ---->执行的SQL
/*!*/;
# at 665
#131128 17:50:46 server id 1 end_log_pos 692 Xid = 1454 ---->执行时间:17:50:46；pos点:692
...............................................................................

注: server id 1 数据库主机的服务号；
end_log_pos 665 pos点
thread_id=11 线程号
2.上面这种办法读取出binlog日志的全文内容较多，不容易分辨查看pos点信息，这里介绍一种更为方便的查询命令：

mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];

选项解析：
IN 'log_name' 指定要查询的binlog文件名(不指定就是第一个binlog文件)
FROM pos 指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
LIMIT [offset,] 偏移量(不指定就是0)
row_count 查询总条数(不指定就是所有行)

截取部分查询结果：
*************************** 20. row ***************************
Log_name: mysql-bin.000021 ----------------------------------------------> 查询的binlog日志文件名
Pos: 11197 ----------------------------------------------------------> pos起始点:
Event_type: Query ----------------------------------------------------------> 事件类型：Query
Server_id: 1 --------------------------------------------------------------> 标识是由哪台服务器执行的
End_log_pos: 11308 ----------------------------------------------------------> pos结束点:11308(即：下行的pos起始点)
Info: use `zyyshop`; INSERT INTO `team2` VALUES (0,345,'asdf8er5') ---> 执行的sql语句
*************************** 21. row ***************************
Log_name: mysql-bin.000021
Pos: 11308 ----------------------------------------------------------> pos起始点:11308(即：上行的pos结束点)
Event_type: Query
Server_id: 1
End_log_pos: 11417
Info: use `zyyshop`; /*!40000 ALTER TABLE `team2` ENABLE KEYS */
*************************** 22. row ***************************
Log_name: mysql-bin.000021
Pos: 11417
Event_type: Query
Server_id: 1
End_log_pos: 11510
Info: use `zyyshop`; DROP TABLE IF EXISTS `type`

这条语句可以将指定的binlog日志文件，分成有效事件行的方式返回，并可使用limit指定pos点的起始偏移，查询条数；

A.查询第一个(最早)的binlog日志：
mysql> show binlog events\G;

B.指定查询 mysql-bin.000021 这个文件：
mysql> show binlog events in 'mysql-bin.000021'\G;

C.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起：
mysql> show binlog events in 'mysql-bin.000021' from 8224\G;

D.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起，查询10条
mysql> show binlog events in 'mysql-bin.000021' from 8224 limit 10\G;

E.指定查询 mysql-bin.000021 这个文件，从pos点:8224开始查起，偏移2行，查询10条
mysql> show binlog events in 'mysql-bin.000021' from 8224 limit 2,10\G;
五、恢复binlog日志实验(zyyshop是数据库)
1.假设现在是凌晨4:00，我的计划任务开始执行一次完整的数据库备份：

将zyyshop数据库备份到 /root/BAK.zyyshop.sql 文件中：
# /usr/local/mysql/bin/mysqldump -uroot -p123456 -lF --log-error=/root/myDump.err -B zyyshop > /root/BAK.zyyshop.sql
......

大约过了若干分钟，备份完成了，我不用担心数据丢失了，因为我有备份了，嘎嘎~~~

由于我使用了-F选项，当备份工作刚开始时系统会刷新log日志，产生新的binlog日志来记录备份之后的数据库“增删改”操作，查看一下：
mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000023 | 120 | | |
+------------------+----------+--------------+------------------+
也就是说， mysql-bin.000023 是用来记录4:00之后对数据库的所有“增删改”操作。
2.早9:00上班了，业务的需求会对数据库进行各种“增删改”操作~~~~~~~
@ 比如：创建一个学生表并插入、修改了数据等等：
CREATE TABLE IF NOT EXISTS `tt` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(16) NOT NULL,
`sex` enum('m','w') NOT NULL DEFAULT 'm',
`age` tinyint(3) unsigned NOT NULL,
`classid` char(6) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
导入实验数据
mysql> insert into zyyshop.tt(`name`,`sex`,`age`,`classid`) values('yiyi','w',20,'cls1'),('xiaoer','m',22,'cls3'),('zhangsan','w',21,'cls5'),('lisi','m',20,'cls4'),('wangwu','w',26,'cls6');
查看数据
mysql> select * from zyyshop.tt;
+----+----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+----------+-----+-----+---------+
| 1 | yiyi | w | 20 | cls1 |
| 2 | xiaoer | m | 22 | cls3 |
| 3 | zhangsan | w | 21 | cls5 |
| 4 | lisi | m | 20 | cls4 |
| 5 | wangwu | w | 26 | cls6 |
+----+----------+-----+-----+---------+
中午时分又执行了修改数据操作
mysql> update zyyshop.tt set name='李四' where id=4;
mysql> update zyyshop.tt set name='小二' where id=2;

修改后的结果：
mysql> select * from zyyshop.tt;
+----+----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+----------+-----+-----+---------+
| 1 | yiyi | w | 20 | cls1 |
| 2 | 小二 | m | 22 | cls3 |
| 3 | zhangsan | w | 21 | cls5 |
| 4 | 李四 | m | 20 | cls4 |
| 5 | wangwu | w | 26 | cls6 |
+----+----------+-----+-----+---------+
假设此时是下午18:00，莫名地执行了一条悲催的SQL语句，整个数据库都没了：
mysql> drop database zyyshop;
3.此刻杯具了，别慌！先仔细查看最后一个binlog日志，并记录下关键的pos点，到底是哪个pos点的操作导致了数据库的破坏(通常在最后几步)；

备份一下最后一个binlog日志文件：
# ll /usr/local/mysql/data | grep mysql-bin
# cp -v /usr/local/mysql/data/mysql-bin.000023 /root/

此时执行一次刷新日志索引操作，重新开始新的binlog日志记录文件，理论说 mysql-bin.000023 这个文件不会再有后续写入了(便于我们分析原因及查找pos点)，以后所有数据库操作都会写入到下一个日志文件；
mysql> flush logs;
mysql> show master status;

4.读取binlog日志，分析问题
方式一：使用mysqlbinlog读取binlog日志：
# /usr/local/mysql/bin/mysqlbinlog /usr/local/mysql/data/mysql-bin.000023

方式二：登录服务器，并查看(推荐)：
mysql> show binlog events in 'mysql-bin.000023';

以下为末尾片段：
+------------------+------+------------+-----------+-------------+------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+------------------+------+------------+-----------+-------------+------------------------------------------------------------+
| mysql-bin.000023 | 922 | Xid | 1 | 953 | COMMIT /* xid=3820 */ |
| mysql-bin.000023 | 953 | Query | 1 | 1038 | BEGIN |
| mysql-bin.000023 | 1038 | Query | 1 | 1164 | use `zyyshop`; update zyyshop.tt set name='李四' where id=4|
| mysql-bin.000023 | 1164 | Xid | 1 | 1195 | COMMIT /* xid=3822 */ |
| mysql-bin.000023 | 1195 | Query | 1 | 1280 | BEGIN |
| mysql-bin.000023 | 1280 | Query | 1 | 1406 | use `zyyshop`; update zyyshop.tt set name='小二' where id=2|
| mysql-bin.000023 | 1406 | Xid | 1 | 1437 | COMMIT /* xid=3823 */ |
| mysql-bin.000023 | 1437 | Query | 1 | 1538 | drop database zyyshop |
+------------------+------+------------+-----------+-------------+------------------------------------------------------------+

通过分析，造成数据库破坏的pos点区间是介于 1437--1538 之间，只要恢复到1437前就可。
5.现在把凌晨备份的数据恢复：

# /usr/local/mysql/bin/mysql -uroot -p123456 -v < /root/BAK.zyyshop.sql;

注: 至此截至当日凌晨(4:00)前的备份数据都恢复了。
但今天一整天(4:00--18:00)的数据肿么办呢？就得从前文提到的 mysql-bin.000023 新日志做文章了......
6.从binlog日志恢复数据

恢复语法格式：
# mysqlbinlog mysql-bin.0000xx | mysql -u用户名 -p密码 数据库名

常用选项：
--start-position=953 起始pos点
--stop-position=1437 结束pos点
--start-datetime="2013-11-29 13:18:54" 起始时间点
--stop-datetime="2013-11-29 13:21:53" 结束时间点
--database=zyyshop 指定只恢复zyyshop数据库(一台主机上往往有多个数据库，只限本地log日志)

不常用选项：
-u --user=name Connect to the remote server as username.连接到远程主机的用户名
-p --password[=name] Password to connect to remote server.连接到远程主机的密码
-h --host=name Get the binlog from server.从远程主机上获取binlog日志
--read-from-remote-server Read binary logs from a MySQL server.从某个MySQL服务器上读取binlog日志

小结：实际是将读出的binlog日志内容，通过管道符传递给mysql命令。这些命令、文件尽量写成绝对路径；

A.完全恢复(本例不靠谱，因为最后那条 drop database zyyshop 也在日志里，必须想办法把这条破坏语句排除掉，做部分恢复)
# /usr/local/mysql/bin/mysqlbinlog /usr/local/mysql/data/mysql-bin.000021 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop

B.指定pos结束点恢复(部分恢复)：
@ --stop-position=953 pos结束点
注：此pos结束点介于“导入实验数据”与更新“name='李四'”之间，这样可以恢复到更改“name='李四'”之前的“导入测试数据”
# /usr/local/mysql/bin/mysqlbinlog --stop-position=953 --database=zyyshop /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop

在另一终端登录查看结果(成功恢复了)：
mysql> select * from zyyshop.tt;
+----+----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+----------+-----+-----+---------+
| 1 | yiyi | w | 20 | cls1 |
| 2 | xiaoer | m | 22 | cls3 |
| 3 | zhangsan | w | 21 | cls5 |
| 4 | lisi | m | 20 | cls4 |
| 5 | wangwu | w | 26 | cls6 |
+----+----------+-----+-----+---------+

C.指定pso点区间恢复(部分恢复)：
更新 name='李四' 这条数据，日志区间是Pos[1038] --> End_log_pos[1164]，按事务区间是：Pos[953] --> End_log_pos[1195]；

更新 name='小二' 这条数据，日志区间是Pos[1280] --> End_log_pos[1406]，按事务区间是：Pos[1195] --> End_log_pos[1437]；

c1.单独恢复 name='李四' 这步操作，可这样：
# /usr/local/mysql/bin/mysqlbinlog --start-position=1038 --stop-position=1164 --database=zyyshop /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop

也可以按事务区间单独恢复，如下：
# /usr/local/mysql/bin/mysqlbinlog --start-position=953 --stop-position=1195 --database=zyyshop /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop
c2.单独恢复 name='小二' 这步操作，可这样：
# /usr/local/mysql/bin/mysqlbinlog --start-position=1280 --stop-position=1406 --database=zyyshop /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop

也可以按事务区间单独恢复，如下：
# /usr/local/mysql/bin/mysqlbinlog --start-position=1195 --stop-position=1437 --database=zyyshop /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop
c3.将 name='李四'、name='小二' 多步操作一起恢复，需要按事务区间，可这样：
# /usr/local/mysql/bin/mysqlbinlog --start-position=953 --stop-position=1437 --database=zyyshop /usr/local/mysql/data/mysql-bin.000023 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop
D.在另一终端登录查看目前结果(两名称也恢复了)：
mysql> select * from zyyshop.tt;
+----+----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+----------+-----+-----+---------+
| 1 | yiyi | w | 20 | cls1 |
| 2 | 小二 | m | 22 | cls3 |
| 3 | zhangsan | w | 21 | cls5 |
| 4 | 李四 | m | 20 | cls4 |
| 5 | wangwu | w | 26 | cls6 |
+----+----------+-----+-----+---------+

E.也可指定时间区间恢复(部分恢复)：除了用pos点的办法进行恢复，也可以通过指定时间区间进行恢复，按时间恢复需要用mysqlbinlog命令读取binlog日志内容，找时间节点。
比如，我把刚恢复的tt表删除掉，再用时间区间点恢复
mysql> drop table tt;

@ --start-datetime="2013-11-29 13:18:54" 起始时间点
@ --stop-datetime="2013-11-29 13:21:53" 结束时间点

# /usr/local/mysql/bin/mysqlbinlog --start-datetime="2013-11-29 13:18:54" --stop-datetime="2013-11-29 13:21:53" --database=zyyshop /usr/local/mysql/data/mysql-bin.000021 | /usr/local/mysql/bin/mysql -uroot -p123456 -v zyyshop

总结：所谓恢复，就是让mysql将保存在binlog日志中指定段落区间的sql语句逐个重新执行一次而已。

减小lvm根分区容量, 分配到swap

在安装Linux系统时LVM划分/分区过大，使用一段时间后觉得没必要把/分区（/dev/vgsrv/root)分的这么大（100G呢），此时可以从Linux安装光盘启动进入rescue模式,选择相关的语言，键盘模式，当系统提示启用网络设备时，选择“NO”，然后在提示允许rescue模式挂载本地Linux系统到/mnt/sysimage下时选择“Skip”，文件系统必须不被挂载才可以对/分区减小容量操作。最后系统会提示选择进入shell终端还是reboot机器，选择进入shell终端。

依次输入pvscan、vgscan、lvscan三个命令扫描pv、vg、lv相关信息，

然后输入 lvchange -ay /dev/vgsrv/root（上文提到的/分区名称）此命令是激活/分区所在的逻辑卷。

下一步是缩小文件系统大小和逻辑卷/dev/vgsrv/root，

在缩小文件系统前先检查下硬盘，e2fsck -f /dev/vgsrv/root

缩小文件系统为指定大小: resize2fs/dev/vgsrv/root 50G

设置逻辑卷大小为50G：lvreduce -L 50g /dev/vgsrv/root

系统会进入是否缩小逻辑卷，输入 y 确定。

再检查下硬盘，e2fsck -f /dev/vgsrv/root

缩小逻辑卷成功后可输入vgdisplay，lvdisplay查看。输入exit可退出rescue模式。

正常进入系统后, 下面针对系统Swap分区扩容与缩减做说明： 

[root@server10 ~]# free -g
            total       used       free     shared    buffers     cached
Mem:            62         62          0          0          0         60
-/+ buffers/cache:          2         60
Swap:          127          0        127
[root@server10 ~]# df -h
[root@server10 ~]# cat /etc/fstab
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
[root@server10 ~]# lvdisplay
 --- Logical volume ---
  LV Name                /dev/VolGroup00/LogVol00
 VG Name                VolGroup00
 LV UUID                oZ7rEm-hphT-MsGk-fNaD-RC5X-INgZ-oCJdml
 LV Write Access        read/write
 LV Status              available
 # open                 1
  LV Size                150.84 GB
 Current LE             4827
 Segments               1
 Allocation             inherit
 Read ahead sectors     auto
 - currently set to     256
 Block device           253:0
 
 --- Logical volume ---
  LV Name                /dev/VolGroup00/LogVol01
 VG Name                VolGroup00
 LV UUID                pCpqVB-cwXV-MunF-OtBQ-usYA-hFxt-l07IJc
 LV Write Access        read/write
 LV Status              available
 # open                 1
  LV Size                127.91 GB
 Current LE             4093
 Segments               1
 Allocation             inherit
 Read ahead sectors     auto
 - currently set to     256
 Block device           253:1
 
[root@server10 ~]# vgdisplay
 --- Volume group ---
 VG Name               VolGroup00
 System ID            
 Format                lvm2
 Metadata Areas        1
 Metadata Sequence No  3
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                2
 Open LV               2
 Max PV                0
 Cur PV                1
 Act PV                1
 VG Size               278.75 GB
 PE Size               32.00 MB
 Total PE              8920
  Alloc PE / Size       8920 / 278.75 GB
 Free  PE / Size       0 / 0  
 VG UUID               9hHRZZ-VUd4-bMwc-rnhK-wiyq-sPZw-dtJREo  
[root@server10 ~]# free -m
            total       used       free     shared    buffers     cached
Mem:         64449      64129        320          0        327      61494
-/+ buffers/cache:       2307      62142
Swap:       130975          0     130975
[root@server10 ~]# swapoff -a
[root@server10 ~]# free -m
            total       used       free     shared    buffers     cached
Mem:         64449      64065        384          0        327      61494
-/+ buffers/cache:       2243      62206
Swap:            0          0          0
[root@server10 ~]# lvreduce /dev/VolGroup00/LogVol01 -L -64G
 WARNING: Reducing active logical volume to 63.91 GB
 THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce LogVol01? [y/n]: y
 Reducing logical volume LogVol01 to 63.91 GB
 Logical volume LogVol01 successfully resized
[root@server10 ~]# mkswap /dev/VolGroup00/LogVol01
Setting up swapspace version 1, size = 68618809 kB
[root@server10 ~]# swapon /dev/VolGroup00/LogVol01
[root@server10 ~]# free -m
            total       used       free     shared    buffers     cached
Mem:         64449      64150        299          0        327      61549
-/+ buffers/cache:       2273      62175
Swap:        65439          0      65439
[root@server10 ~]# free -g
            total       used       free     shared    buffers     cached
Mem:            62         62          0          0          0         60
-/+ buffers/cache:          2         60
Swap:           63          0         63
[root@server10 ~]# vgdisplay
 --- Volume group ---
 VG Name               VolGroup00
 System ID            
 Format                lvm2
 Metadata Areas        1
 Metadata Sequence No  4
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                2
 Open LV               2
 Max PV                0
 Cur PV                1
 Act PV                1
 VG Size               278.75 GB
 PE Size               32.00 MB
 Total PE              8920
  Alloc PE / Size       6872 / 214.75 GB
 Free  PE / Size       2048 / 64.00 GB
 VG UUID               9hHRZZ-VUd4-bMwc-rnhK-wiyq-sPZw-dtJREo
 
[root@server10 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                     147G   74G   65G  54% /
/dev/sda1              99M   13M   81M  14% /boot
tmpfs                  32G     0   32G   0% /dev/shm
[root@server10 ~]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
[root@server10 ~]# lvextend /dev/VolGroup00/LogVol00 -l +100%FREE
  Extending logical volume LogVol00 to 214.84 GB
 Logical volume LogVol00 successfully resized
[root@server10 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                     147G   74G   65G  54% /
/dev/sda1              99M   13M   81M  14% /boot
tmpfs                  32G     0   32G   0% /dev/shm
[root@server10 ~]# resize2fs /dev/VolGroup00/LogVol00
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/VolGroup00/LogVol00 is mounted on /; on-line resizing required
Performing an on-line resize of /dev/VolGroup00/LogVol00 to 56320000 (4k) blocks.
The filesystem on /dev/VolGroup00/LogVol00 is now 56320000 blocks long.

[root@server10 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                     209G   74G  124G  38% /
/dev/sda1              99M   13M   81M  14% /boot
tmpfs                  32G     0   32G   0% /dev/shm
[root@server10 ~]# 

------------------------------------------------------------------

以上是减容量，下面针对增加容量做一下命令解析：

swapoff -a   //关闭swap分区
lvextend -l +100%free /dev/VolGroup00/LogVol00 //增加swap卷所有可用空间
mkswap /dev/VolGroup00/LogVol00 //建立swap分区
swapon /dev/VolGroup00/LogVol00//启用swap分区

ubuntu18.04安装mysql 5.5

官网下载LINUX编译版本 mysql-5.5.61-linux-glibc2.12-x86_64.tar.gz 解压

1. shell> sudo apt-get install libaio-dev（或者libaio1）
2. shell> sudo groupadd mysql
3. shell> sudo useradd -r /nonexistent -s /bin/false -c mysql -g mysql mysql
4. shell> sudo cd /usr/local
5. shell> tar zxvf /home/niumd/mysql-5.5.13-linux2.6-i686.tar.gz
6. shell> sudo mv /home/niumd/mysql-5.5.13-linux2.6-i686 /usr/local/mysql
7. shell> cd /usr/local/mysql
8. shell> sudo chown -R mysql:mysql .
9. shell> sudo scripts/mysql_install_db --user=mysql     
10. shell> sudo chown -R mysql:mysql data
11. shell> sudo cp support-files/mysql.server /etc/init.d/mysql.server
12. shell> sudo cp support-files/my-medium.cnf /etc/mysql/my.cnf
13. shell> sudo bin/mysqld_safe --user=mysql & 
14. shell> sudo pwd /usr/local/mysql
15. shell> sudo bin/mysqladmin -u root password 'new-password'
16. shell> sudo bin/mysql -uroot -p

H3C WA2620i-AGN多AP自动漂移设置

更多设置地址: http://www0.h3c.com.cn/Service/Document_Center/Wlan/WX/WX5000/Command/Command_Manual/H3C_WX_CR-6W104/02/201208/751156_30005_0.htm

此处只是简单的设置当终端(手机等设备)连接AP的信号值低于某个阀值则AP端主动断开连接, 让终端重新连接, 当终端重新连接时会自动连接到信号较的AP(即距离比较近的AP), 因此只要把多个AP的接入点名称,密码,加密方式设为一致即可, 此操作可实现企业简单无线网络漂移设置, 超多AP节点建议使用AC统一控制.

以下操作通过TELNET或者控制线连接到交换机, 阀值需要自己测试, 根据实际情况调整, 一般情况下20能够满足

wlan option client-reconnect-trigger

【命令】

wlan option client-reconnect-trigger rssi signal-check

undo wlan option client-reconnet-trigger

【视图】

系统视图

【缺省级别】

2：系统级

【参数】

rssi：主动触发无线客户端重连接的信号强度门限值，取值范围为1～40，建议取值为20，单位dBm。

【描述】

wlan option client-reconnect-trigger命令用来配置主动触发无线客户端重连接功能，如果无线客户端接收到信号的rssi值小于配置的门限值，就主动触发无线客户端重连接。当配置了signal-check时，如果无线客户端接收到信号的rssi值小于配置的门限值，不立即触发无线客户端重连接，而是等待检查下一次无线客户端接收到信号的rssi值，如果rssi又减少了3dBm以上，才触发无线客户端重连接，否则，不触发无线客户端重连接。

undo wlan option client-reconnet-trigger命令用来恢复缺省情况。

缺省情况下，关闭主动触发无线客户端重接接功能。

【举例】

# 开启主动触发无线客户端重接接功能。

<sysname> system-view

[sysname] wlan option client-reconnect-trigger 20

编写systemd service文件

什么是 Systemd service？

一种以 .service 结尾的单元（unit）配置文件，用于控制由 systemd 控制或监视的进程。简单说，用于后台以守护精灵（daemon）的形式运行程序。

编写 Systemd service

基本结构

Systemd 服务的内容主要分为三个部分，控制单元（unit）的定义、服务（service）的定义、以及安装部分。

和 SysV init 脚本的差异

过去，*nix 服务（守护精灵）都是用 SysV 启动脚本启动的。SysV 启动脚本就是 Bash 脚本，通常在 /etc/init.d 目录下，可以被一些标准参数如 start，stop，restart 等调用。启动该脚本通常意味着启动一个后台守护精灵（daemon）。shell 脚本常见的缺点就是，慢、可读性不强、太详细又很傲娇。虽然它们很灵活（毕竟那就是代码呀），但是有些事只用脚本做还是显得太困难了，比如安排并列执行、正确监视进程，或者配置详细执行环境。

SysV 启动脚本还有一个硬伤就是，臃肿，重复代码太多。因为上述的“标准参数”必须要靠各个脚本来实现，而且各个脚本之间的实现都差不多（根本就是从一个 skeleton 骨架来的）。而 Systemd 则进行了统一实现，也就是说在 Systemd service 中完全就不需要、也看不到这部分内容。这使得 Systemd 服务非常简明易读，例如 NetworkManager 这一重量级程序的服务，算上注释一共才有 19 行。而它相应的 SysV 启动脚本头 100 行连标准参数都没实现完。

Systemd 兼容 Sysv 启动脚本，这也是为什么这么久我们仍然需要一个 systemd-sysvinit 软件包的原因。但是根据以上理由，最好针对所有您安装的守护精灵都使用原生 Systemd 服务来启动。另外，Systemd 服务可无缝用于所有使用 Systemd 的发行版，意思是 Arch 下编写的脚本拿过来依然能够使用。

通常来说，上游应该在发布源代码的同时发布 Systemd 服务，但如果没发布，你可以对照本教学来为它们写一个并贡献给它们。

关于 SysV init 启动脚本的编写可见openSUSE:Packaging_init_scripts，这主要用于你的服务器，毕竟服务器追求稳定软件更新的不是很勤（但你一定不知道欧盟汽车里的车载系统必须是 Systemd）。

真正开始前需要注意的问题

如上所述，Systemd 的 service 文件是完全跨发行版的，所以有时候没有必要重造轮子。真正编写你的服务前，请确认它在各大发行版中完全就不存在：

• 我们的 Systemd 服务集合
• Fedora Systemd 服务集合
• Arch Linux Systemd 服务集合
• Gentoo Systemd 服务集合
• Debian 中的少量 Systemd 服务
• ubuntu 中的少量 Systemd 服务

Systemd 语法

Systemd 语法和 .desktop 文件的语法比较像，也比较类似 Windows 下的 .ini 文件，因此无论对于打包者还是最终用户都是非常容易上手的。

主要格式请见下面的小例子，这里需要说明三点：

• Systemd 单元文件中的以 “#” 开头的行后面的内容会被认为是注释
• Systemd 下的布尔值，1、yes、on、true 都是开启，0、no、off、false 都是关闭。注：

仅限于 Systemd 文件，比如：

RemainOnExit=yes

并不适用于该文件中嵌入的 shell 语句，比如：

ExecStartPre=/usr/bin/test "x${NETWORKMANAGER}" = xyes

这里的 yes 就不能替换。因为等号后面是一条嵌入的 shell 语句。

• Systemd 下的时间单位默认是秒，所以要用毫秒（ms）分钟（m）等请显式说明。

一个小例子

NetworkManager 的 Systemd service：

[Unit]
Description=Network Manager
After=syslog.target
Wants=remote-fs.target network.target

[Service]
Type=dbus
BusName=org.freedesktop.NetworkManager
ExecStart=/usr/sbin/NetworkManager --no-daemon
EnvironmentFile=/etc/sysconfig/network/config
ExecStartPre=/usr/bin/test "x${NETWORKMANAGER}" = xyes
# Suppress stderr to eliminate duplicated messages in syslog. NM calls openlog()
# with LOG_PERROR when run in foreground. But systemd redirects stderr to
# syslog by default, which results in logging each message twice.
StandardError=null

[Install]
WantedBy=multi-user.target
Also=NetworkManager-wait-online.service

以下我们以编写我们论坛（https://forum.suse.org.cn）所使用的 He.net IPv6 单元文件为例。

定义控制单元 [Unit]

在 Systemd 中，所有引导过程中 Systemd 要控制的东西都是一个单元。Systemd 单元类型有：

• 系统服务
• 套接字（socket）
• 设备
• 挂载点
• 自动挂载点
• SWAP 文件
• 分区
• 启动对象（startup target）
• 文件系统路径
• 定时器

简单说，Systemd 把 *nix 里那些分散开发因此宏观看变成一团杂碎的东西重新统一命名了。单元名就是你写的这个 .service 文件的名称。但不只有 .service 后缀的文件才可以是一个单元，单元还可以有 .target, .path 等后缀，具体可以去 /usr/lib/systemd/system 下了解。但那种后缀要么由 Systemd 上游开发者写好随 systemd 软件包分发，要么由我们的 Base:system 团队添加，一般用户是不太需要写其它后缀的控制单元的。

我们先要声明我们在定义控制单元：

[Unit]

单元名称就不用写了，我们要写一条单元描述：

[Unit]
Description=Daemon to start He.net IPv6

下面我们要讲解一下 Systemd 是如何控制各个单元之间的关系的。它和 RPM 的 specfile 的依赖关系控制的语法非常相似（毕竟都是红帽一家的）：

• Requires: 这个单元启动了，那么它“需要”的单元也会被启动; 它“需要”的单元被停止了，它自己也活不了。但是请注意，这个设定并不能控制某单元与它“需要”的单元的启动顺序（启动顺序是另外控制的），即 Systemd 不是先启动 Requires 再启动本单元，而是在本单元被激活时，并行启动两者。于是会产生争分夺秒的问题，如果 Requires 先启动成功，那么皆大欢喜; 如果 Requires 启动得慢，那本单元就会失败（Systemd 没有自动重试）。所以为了系统的健壮性，不建议使用这个标记，而建议使用 Wants 标记。可以使用多个 Requires。

• RequiresOverridable：跟 Requires 很像。但是如果这条服务是由用户手动启动的，那么 RequiresOverridable 后面的服务即使启动不成功也不报错。跟 Requires 比增加了一定容错性，但是你要确定你的服务是有等待功能的。另外，如果不由用户手动启动而是随系统开机启动，那么依然会有 Requires 面临的问题。

• Requisite：强势版本的 Requires。要是这里需要的服务启动不成功，那本单元文件不管能不能检测等不能等待都立刻就会失败。

• Wants：推荐使用。本单元启动了，它“想要”的单元也会被启动。但是启动不成功，对本单元没有影响。

• Conflicts：一个单元的启动会停止与它“冲突”的单元，反之亦然。注意这里和后面的启动顺序是“正交”的：

两个相互冲突的单元被同时启动，要么两个都启动不了（两者都是第三个单元的 Requires），要么启动一个（有一个是第三个单元的 Requires，另一个不是），不是 Requires 的那个会被停止。要是两者都不是任何一个单元的 Requires，那么 Conflicts 别的那个单元优先启动，被 Conflicts 的后启动，要是互相写了，那么两个都启动不了。

• OnFailure：很明显，如果本单元失败了，那么启动什么单元作为折衷。

好了，现在我们来想象一下，我们的单元（Ipv6 隧道）应该想要什么呢？很显然是一个连通着的网络。有一个 Systemd 默认提供的对象叫做 network-online.target（默认的 target 列表可见 systemd.special，必看，因为你大多数时候 Wants 的都是一个固定的系统状态而不是其它 systemd 服务），正正好好能够提供我们需要的环境。于是：

[Unit]
Description=Daemon to start He.net IPv6
Wants=network-online.target

下面我们需要定义一下服务启动顺序，不然连 / 目录所在的硬盘都没挂载就开始干活，上哪儿找程序去呀。Systemd 服务启动顺序主要使用以下两个标记定义的：

• Before/After：要是一个服务 Before 另一个服务，那么在并行启动时（Systemd 总是用进程 0 并行启动所有东西，然后通过这两个标记来二次等待排序），那另一个服务这时就会等这个服务先启动并返回状态，注意是先启动而不是启动成功，因为失败也是一种状态，一定要成功才启动另一个服务是通过依赖关系定义的。反之 After 亦然。

下面说下“关机”（可以是挂起，这时候有些服务是依然在跑的，比如网络唤醒）时候的顺序：如果两个服务都是要关掉的，Before 是先关自己，After 是先关别人，这很好理解; 但如果一个服务是要关，而另一个是要开的，那么不管 Before/After 写了什么，总是优先关闭而不是开始。也就是比如服务 A Before 服务 B，但是服务 B 是在关，而服务 A 是在 restart，那么服务 B 的顺序在服务 A 的前面。

好啦，我们的单元应该在什么的前后启动呢？它不需要一定在什么服务前面跑起来，这不像 ifup 和 dhcp，网络起不来获取 ip 肯定没用。我们只需要有网就可以了。“有网”在 Systemd 中也是由一个默认 target：network.target 提供的，于是我们的控制单元就定义好了：

[Unit]
Description=Daemon to start He.net IPv6
Wants=network-online.target
After=network.target

定义服务本体 [service]

在定义完了 Systemd 用来识别服务的单元后，我们来定义服务本体，依然是声明：

[Service]

然后是声明服务类型：

[Service]
Type=

Systemd 支持的服务类型有以下几类：

• simple 默认，这是最简单的服务类型。意思就是说启动的程序就是主体程序，这个程序要是退出那么一切皆休。这在图形界面里非常好理解，我打开 Amarok，退出它就没有了。但是命令行的大部分程序都不会那么设计，因为命令行的一个最基本原则就是一个好的程序不能独占命令行窗口。所以输入命令，回车，接着马上返回给你提示符，但程序已经执行了。所以只有少数程序比如 python xxx.py 还使用这种方式。在这种类型下面，如果你的主程序是要响应其它程序的，那么你的通信频道应该在启动本服务前就设好（套接字等），因此这种类型的服务，Systemd 运行它后会立刻就运行下面的服务（需要它的服务），这时没有套接字后面的服务会失败，写 After 也没用，因为 simple 类型不存在主进程退出的情况也就不存在有返回状态的情况，所以它一旦启动就认为是成功的，除非没起来。

• forking 标准 Unix Daemon 使用的启动方式。启动程序后会调用 fork() 函数，把必要的通信频道都设置好之后父进程退出，留下守护精灵的子进程。你要是使用的这种方式，最好也指定下 PIDFILE=，不要让 Systemd 去猜，非要猜也可以，把 GuessMainPID 设为 yes。

判断是 forking 还是 simple 类型非常简单，命令行里运行下你的程序，持续占用命令行要按 Ctrl + C 才可以的，就不会是 forking 类型。

创建 PIDFILE 是你为它写服务的程序的任务而不是 Systemd 的功能，甚至也不是 Sysvinit 脚本的功能。参考 startproc创建pid file的问题了解进一步的知识。因此如果你的程序确实是 forking 类型，但就是没实现创建 PIDFILE 的功能，那么建议使用 ExecStartPost= 结合 shell 命令来手动抓取进程编号并写到 /var/run/xxx.pid。

• oneshot 顾名思义，打一枪换一个地方。所以这种服务类型就是启动，完成，没进程了。常见比如你设置网络，ifup eth0 up，就是一次性的，不存在 ifup 的子进程（forking 那样），也不存在主进程（simple 那样），它运行完成后便了无痕迹。因为这类服务运行完就没进程了，我们经常会需要 RemainAfterExit=yes。后面配置的意思是说，即使没进程了，我们也要 Systemd 认为该服务是存在并成功了的。所以如果你有一个这样的服务，服务启动后，你再去 ifup eth0 up，这时你再看服务，依然显示是 running 的。因为只要在执行那条一次性命令的时候没出错，那么它就永远认为它是成功并一直存在的，直到你关闭服务。

• dbus 这个程序启动时需要获取一块 DBus 空间，所以需要和 BusName= 一起用。只有它成功获得了 DBus 空间，依赖它的程序才会被启动。

一般人也就能用到上面四个，还有两种少见的类型：

• notify 这个程序在启动完成后会通过 sd_notify 发送一个通知消息。所以还需要配合 NotifyAccess 来让 Systemd 接收消息，后者有三个级别：none，所有消息都忽略掉; main，只接受我们程序的主进程发过去的消息; all，我们程序的所有进程发过去的消息都算。NotifyAccess 要是不写的话默认是 main。

• idle 这个程序要等它里面调度的全部其它东西都跑完才会跑它自己。比如你 ExecStart 的是个 shell 脚本，里面可能跑了一些别的东西，如果不这样的话，那很可能别的东西的控制台输出里会多一个“启动成功”这样的 Systemd 消息。

由于 He.net 的 IPv6 是用 iproute2 的 ip 命令来弄的，所以是一个 oneshot 一次性服务。

[Service]
Type=oneshot
RemainAfterExit=yes

接下来要设置 ExecStart, ExecStop。如果程序支持的话，你还可以去设置 ExecReload，Restart 等。注意，这里设置的是它们 Reload/Restart 的方式，但并不代表没有它们 Systemd 就不能完成比如 systemctl restart xxx.service 这样的任务，程序有支持自然最好，程序不支持那就先 stop 再 start 咯。同样有特殊要求的时候你也可以去设置比如 ExecStartPre/ExecStartPost,RestartSec,TimeoutSec 等其它东西，参考链接里都有使用方法。

这里要特殊讲一下 ExecStart：

• 如果你服务的类型不是 oneshot，那么它只可以接受一个命令，参数不限，比如你先 ip tunnel create 再 ip tunnel0 up，那是两个 ip 命令，如果你不是 oneshot 类型这样是不行的。
• 如果有多条命令（oneshot 类型），命令之间以分号 ; 分隔，跨行可用反斜杠 \。
• 除非你的服务类型是 forking，否则你在这里输入的命令都会被认为是主进程，不管它是不是。

于是我们的 [Service] 就写好了：

 [Service]
 Type=oneshot
 RemainAfterExit=yes
 ExecStart=/usr/sbin/ip tunnel add he-ipv6 mode sit remote 66.220.18.42 local 108.170.7.158     ttl 255 ; \
           /usr/sbin/ip link set he-ipv6 up ; \
           /usr/sbin/ip addr add 2001:470:c:1184::2/64 dev he-ipv6 ; \
           /usr/sbin/ip route add ::/0 dev he-ipv6 ; \
           /usr/sbin/ip -6 addr
 ExecStop=/usr/sbin/ip route delete ::/0 dev he-ipv6 ; \
          /usr/sbin/ip -6 addr del 2001:470:c:1184::2/64 dev he-ipv6 ; \
          /usr/sbin/ip link set he-ipv6 down ; \
          /usr/sbin/ip tunnel del he-ipv6

安装服务 [install]

这可能有点绕，我服务文件都弄好了，放到 /etc/systemd/system（供系统管理员和用户使用），/usr/lib/systemd/system（供发行版打包者使用）了，不就是安装好了嘛。

这里说的是一种内部状态，默认你放对位置它显示的是 disabled，unloaded，所以我们要在 Systemd 内部对它进行一下 load，没人要的东西是不需要安装的（我们不收渣渣），所以我们要告诉 Systemd 它是有人要的，被谁要。一般都是被

[Install]
WantedBy=multi-user.target 

要（multi-user.target 表示多用户系统好了，简单理解就是你可以登入了）。这样在 multi-user.target 启用时，我们的服务也就会被启用了。

[Install] 部分下除了 WantedBy 还有两种属性，分别是：

• Alias= 给你自己的别名，这样 systemctl command xxx.service 的时候就可以不输入完整的单元名称。比如你给 NetworkManager 一个别名叫 Alias=nm，那你就可以 systemctl status nm.service 查看实际是 NetworkManager.service 的服务了。

• Also= 安装本服务的时候还要安装别的什么服务。比如我们的 He.net 脚本按理应该需要一个 iproute2.service 作为 also，但是 iproute2 实际上不需要 systemd 控制，所以就没写。它和 [Unit] 定义里面的依赖关系相比，它管理的不是运行时依赖，而是安装时。安装好了之后启动谁先谁后，谁依赖谁，和 Also= 都没有关系。