运维部落

三步创建一个用户，使他有与root一样的权限。
1. 上root下，创建一个用户“app”
[root@daddylinux~]#useradd app
[root@daddylinux~]#passwd app
2. 限定app使用root特权，如下所示，编辑visudo文件。
[root@daddylinux~]# visudo
3. 在最后一行，添加下列信息。
app ALL=(ALL) ALL
退出并保存。

设你正在运行使用InnoDB表格的MySQL,糟糕的硬件设备，驱动程序错误，内核错误，不幸的电源故障或某些罕见的MySQL错误使你的InnoDB表空间被损坏了。
在这种情况下，InnoDB的一般会出现这样的输出：

InnoDB: Database page corruption on disk ora failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
080703 23:46:16 InnoDB: Page dump in ascii and hex (16384bytes):
… 这里省略很多二进制和十六进制编码…
080703 23:46:16 InnoDB: Page checksum 587461377,prior-to-4.0.14-form checksum 772331632
InnoDB: stored checksum 2287785129, prior-to-4.0.14-form storedchecksum 772331632
InnoDB: Page lsn 24 1487506025, low 4 bytes of lsn at page end1487506025
InnoDB: Page number (if stored to page already) 7,
InnoDB: Database page corruption on disk or a failed

mysqldump导出库时报错如下：
“mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `; at row:6880″
或是操作对应表时，也会报错。这时数据库会重启。
当时想到的是在修复之前保证数据库正常，不是这么异常的无休止的重启。

使用innodb_force_recovery =1，正如你所看到的，即使日志文件中有校验失败的记录，但CHECK TABLE还是说表格是正确的。
这意味着你不能太依赖CHECKTABLE在InnoDB上执行的结果。
所以就修改了配置文件的一个参数：innodb_force_recovery
innodb_force_recovery影响整个InnoDB存储引擎的恢复状况。默认为0，表示当需要恢复时执行所有的，
innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。
当设置参数值大于0后，可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。
1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
4(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。
6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。
因为错误日志里面提示出现了坏页，导致数据库崩溃，所以这里把innodb_force_recovery 设置为1，忽略检查到的坏页。
重启数据库之后，找到错误信息出现的表

因为后者可以通过使用OPTIMIZE TABLE命令来修复，但这和更难以恢复的表格目录(table dictionary)被破坏的情况来说要好一些。

操作步骤：

修改my.cnf 配置文件，添加innodb_force_recovery = 1运行InnoDB，然后重启mysql 。

1，建议一个备份表，T_MinuteStore_BAK，使用MYISAM存储引擎，建表语句如下:

CREATE TABLE `T_MinuteStore_BAK` (
`T_MinuteStore_ID` bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘行标识’,
`siteID` int(11) DEFAULT NULL COMMENT ‘站点标识’,
`genTime` datetime DEFAULT NULL COMMENT ‘监测时间’,
`itemID` int(11) DEFAULT NULL COMMENT ‘监测项目’,
`value` varchar(255) DEFAULT NULL COMMENT ‘监测值’,
`flag` varchar(255) DEFAULT NULL COMMENT ‘异常标志’,
`filterFlag` bit(1) DEFAULT NULL COMMENT ‘过滤标志’,
PRIMARY KEY (`T_MinuteStore_ID`)
) ENGINE=MYISAM AUTO_INCREMENT=188995 DEFAULT CHARSET=utf8 COMMENT=’监测分钟数据–5分钟一组数据’;

2,把T_MinuteStore表中的数据导入到新表T_MinuteStore_BAK.

insert into T_MinuteStore_BAK select * from T_MinuteStore;

提示报错: 2013 (HY000): Lost connection TO MySQL server during query
你可能想对数据表进行扫描直到第一个被损坏的行，然后从MyISAM表中得到结果？
不幸的是，运行之后的T_MinuteStore_BAK表格是只有一部份数据。
这里查看T_MinuteStore_BAK表中，主键 T_MinuteStore_ID 从最小值到160861，可以看出是被顺序插入的数据。
那么现在就好办了，说明从16081之后，有损坏的数据行。
下面作下插入数据测试，看看大约有多少行数据损坏。
insert into T_MinuteStore_BAK select * from T_MinuteStore where T_MinuteStore_ID>161000;
执行命令后，还是报错。
最后测试;
161500160861
此主键之间的数据，有损坏，其它数据恢复正常。总计100万行数据，只丢了几百行数据，完全可以承受。
3, 删除掉原表： drop table T_MinuteStore;注释掉innodb_force_recovery 之后，重启Mysql。
4，重命名 T_MinuteStore_BAK：

rename table T_MinuteStore_BAK to T_MinuteStore;
5，最后将表T_MinuteStore修改回存储引擎：

alter table T_MinuteStore engine = innodb;

最后将数据库数据导出，测试导出成功，未发现问题。备份好数据，然后更换好硬盘，重装好Mysql ,将数据导入。
测试程序，一切正常。

现在我们来展示一个使用tar工具来增量备份的例子。

一、增量备份

1、新建backup目录，里面新建file1,file2,file3文件

mkdir backup/
touch backup/{file1,file2,file3}
2、进行完整备份

tar -g tarinfo -czf backup-full.tar.gz backup/
3、新增文件到backup

touch backup/file4
4、进行增量备份

tar -g tarinfo -czf backup-incre1.tar.gz backup/
5、查看增量备份文件

tar -ztf backup-incre1.tar.gz
二、进行还原

1、删除backup目录

rm -rf backup/
2、执行还原操作

tar xzf backup-full.tar.gz
tar xzf backup-incre1.tar.gz
现在已经完成tar的还原操作。其它tar的增量备份只需要指定-g参数，tarinfo文件则是用来记录备份的一些信息。

开启配置HTTP压缩（GZip）

在IIS7中配置Gzip压缩相比IIS6来说实在容易了许多，而且默认情况下就是启用GZip压缩的。如果没有，则可以再功能视图下找到“压缩”项，进入之后就会看到“静态内容压缩”和“动态内容压缩”两个选项，勾上即可。

配置启用压缩的文件类型及其他选项

当开启GZip压缩之后，IIS并不是对所有内容都启用了压缩，而是有选择的进行压缩。遗憾的是，我们无法直接在IIS7管理器中配置这些压缩选项。我们首先需要在C:\Windows\System32\inetsrv\config文件夹下找到applicationhost.config文件，打开之后找到如下一节内容：

1

IIS实际上是根据MIME类型来决定是否启用HTTP压缩的，以及压缩比之类的选项。可以看出，图片默认情况下是不被压缩的，这是因为图片的压缩比太低了。

我们注意到，对于Javascript来说，上面对不同的mime类型配置了不同的压缩方式。Javascript有三种常见的Mime类型，text/javascript，application/x-javascript，application/javascript。这三种类型都是合法的，在现代浏览器中也不存在什么差别。但是由于IIS7中Js文件的mime类型默认被设置为application/x-javascript，也就是说对于js文件，使用的是动态内容压缩而不是静态内容压缩，因此会导致js文件有时经过压缩的，有时却没有压缩。

静态压缩及动态压缩的区别

IIS7中的HTTP压缩分为“静态内容压缩”和“动态内容压缩”，其实这两个名字第一次接触很费解。什么是动态内容什么又是静态内容？实际上，准确的翻译应该是“静态压缩”和“动态压缩”。这两个词反应了IIS的压缩行为。对于配置在staticTypes节中的mime类型，将会启用静态压缩，也就是说，当文件第一次被请求的时候，IIS会将其压缩，然后放入临时文件夹中，下次再有人请求此文件时直接从临时文件夹中取出压缩后的版本而不用重新执行压缩的过程。配置在dynamicTypes一节中的mime类型的http请求都将启用动态压缩，即每一次请求，主机都会对请求的内容——可能是存放在文件系统中的静态文件，也可能是ISAPI返回的内容——进行压缩，而不会对其进行缓存。这个压缩比率因主机性能不同而会有所调整，所以我们在请求js文件的时候才会发现js文件有时压缩有时不压缩的情况。

显而易见，静态压缩会占用一定的存储空间，但是速度快，而动态压缩不占用存储空间，但是占用CPU时间，而且压缩比不恒定。而对于经过ISAPI的请求，则不能使用静态压缩方式。例如对于WCF返回的内容。

一、目的

在使用CentOS6.3版本linux系统的时候，发现根目录(/)的空间不是很充足，而其他目录空间有很大的空闲，所以本文主要是针对现在已有的空间进行调整。首先，先来查看一下系统的空间分配情况：

1
2
3
4
5
6
7
8

[root@CentOS-78 /]# df -h  
Filesystem            Size  Used Avail Use% Mounted on  
/dev/mapper/vg_centos-lv_root  
                       50G   14G   34G  30% /  
tmpfs                 1.9G     0  1.9G   0% /dev/shm  
/dev/sda1             485M   37M  423M   8% /boot  
/dev/mapper/vg_centos-lv_home  
                      404G  670M  382G   1% /home

下面的详细步骤部分将从vg_centos-lv_home分区下取出100G的空间添加到/vg_centos-lv_root分区上去。
二、详细步骤
1、卸载vg_centos-lv_home分区

1
2
3
4
5
6
7
8
9
10
11
12

[root@CentOS-78 /]# umount /home  
 
[root@CentOS-78 /]# df -h  
Filesystem            Size  Used Avail Use% Mounted on  
/dev/mapper/vg_centos-lv_root  
                       50G   14G   34G  30% /  
tmpfs                 1.9G     0  1.9G   0% /dev/shm  
/dev/sda1             485M   37M  423M   8% /boot  
 
[root@CentOS-78 /]# resize2fs -p /dev/mapper/vg_centos-lv_home 282G  
resize2fs 1.41.12 (17-May-2010)  
Please run 'e2fsck -f /dev/mapper/vg_centos-lv_home' first.

这一步设定vg_home-lv_home大小没有成功，系统提示我们先运行下面的命令，操作如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

[root@CentOS-78 /]# e2fsck -f /dev/mapper/vg_centos-lv_home  
e2fsck 1.41.12 (17-May-2010)  
Pass 1: Checking inodes, blocks, and sizes  
Pass 2: Checking directory structure  
Pass 3: Checking directory connectivity  
Pass 4: Checking reference counts  
Pass 5: Checking group summary information  
/dev/mapper/vg_centos-lv_home: 1386/26836992 files (0.9% non-contiguous), 1855856/107344896 blocks  
 
[root@CentOS-78 /]# resize2fs -p /dev/mapper/vg_centos-lv_home 282G  
resize2fs 1.41.12 (17-May-2010)  
Resizing the filesystem on /dev/mapper/vg_centos-lv_home to 73924608 (4k) blocks.  
Begin pass 2 (max = 43)  
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  
Begin pass 3 (max = 3276)  
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  
Begin pass 4 (max = 266)  
Updating inode references     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  
The filesystem on /dev/mapper/vg_centos-lv_home is now 73924608 blocks long. 
 
[root@CentOS-78 /]# mount /home  
[root@CentOS-78 /]#  
[root@CentOS-78 /]# df -h  
Filesystem            Size  Used Avail Use% Mounted on  
/dev/mapper/vg_centos-lv_root  
                       50G   14G   34G  30% /  
tmpfs                 1.9G     0  1.9G   0% /dev/shm  
/dev/sda1             485M   37M  423M   8% /boot  
/dev/mapper/vg_centos-lv_home  
                      278G  663M  263G   1% /home  
[root@CentOS-78 /]#  
 
[root@CentOS-78 /]# lvreduce -L 282G /dev/mapper/vg_centos-lv_home  
  WARNING: Reducing active and open logical volume to 282.00 GiB  
  THIS MAY DESTROY YOUR DATA (filesystem etc.)  
Do you really want to reduce lv_home? [y/n]: y  
  Reducing logical volume lv_home to 282.00 GiB  
  Logical volume lv_home successfully resized  
[root@CentOS-78 /]#

查看一下lv目前的情况

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

[root@CentOS-78 /]# vgdisplay  
  --- Volume group ---  
  VG Name               vg_centos  
  System ID  
  Format                lvm2  
  Metadata Areas        1  
  Metadata Sequence No  5  
  VG Access             read/write  
  VG Status             resizable  
  MAX LV                0  
  Cur LV                3  
  Open LV               3  
  Max PV                0  
  Cur PV                1  
  Act PV                1  
  VG Size               465.27 GiB  
  PE Size               4.00 MiB  
  Total PE              119109  
  Alloc PE / Size       86472 / 337.78 GiB  
  Free  PE / Size       32637 / 127.49 GiB  
  VG UUID               1k4ooN-RFV9-uyf1-uMYf-aERG-YaGs-ZNoSD6

Free PE / Size指定的应该是现在可在分配的空间。
4、增加vg_centos-lv_root分区的大小
将可用的空间添加到vg_centos-lv_root分区上面：

1
2
3
4
5
6
7
8
9
10
11
12

[root@CentOS-78 /]# lvextend -L +127.40G /dev/mapper/vg_centos-lv_root  
  Rounding up size to full physical extent 127.40 GiB  
  Extending logical volume lv_root to 177.40 GiB  
  Logical volume lv_root successfully resized  
[root@CentOS-78 /]#  
 
[root@CentOS-78 /]# resize2fs -p /dev/mapper/vg_centos-lv_root  
resize2fs 1.41.12 (17-May-2010)  
Filesystem at /dev/mapper/vg_centos-lv_root is mounted on /; on-line resizing required  
old desc_blocks = 4, new_desc_blocks = 12  
Performing an on-line resize of /dev/mapper/vg_centos-lv_root to 46504960 (4k) blocks.  
The filesystem on /dev/mapper/vg_centos-lv_root is now 46504960 blocks long.

5、再次查看分区大小

1
2
3
4
5
6
7
8

[root@CentOS-78 /]# df -h  
Filesystem            Size  Used Avail Use% Mounted on  
/dev/mapper/vg_centos-lv_root  
                      175G   14G  153G   9% /  
tmpfs                 1.9G     0  1.9G   0% /dev/shm  
/dev/sda1             485M   37M  423M   8% /boot  
/dev/mapper/vg_centos-lv_home  
                      278G  663M  263G   1% /home

我们发现vg_centos-lv_root分区的空间已经增加了125G，之所以比lv_home减少的空间要多25G主要是由于我们把系统所有的可用的空间都加在了lv_root分区。
三、所遇到的问题
1、在卸载/home目录的时候失败
可先执行如下fuser命令，然后再umount即可：

1
2

[root@CentOS-78 /]# fuser -m /home  
[root@CentOS-78 /]#

2、设定完lv_home的大小，再次mount该分区时，发现用df命令无法看到给分区，此时只要在mount一次即可
3、在设定lv_root的大小时，不要把Free PE / Size的空间全部都用上，这很可能会出现Free PE空间不足的现象，建议保留一点Free PE的空间。

最近在研究一些深度学习框架和大数据可视化的应用，经常会编译一些文件，而yum的默认地址下载太慢，所以用国内比较稳定的阿里云源。

参考

http://mirrors.aliyun.com/help/centos?spm=5176.bbsr150321.0.0.d6ykiD

话不多说，上命令
1、备份
mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup

2、下载新的CentOS-Base.repo 到/etc/yum.repos.d/
CentOS 5

wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-5.repo
CentOS 6

wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-6.repo

CentOS 7

wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo

3、之后运行yum makecache生成缓存

option http-server-close
假设你有一台HAProxy前端与十个不同的后端通信，且这十个后端不支持HTTP keep-alive。这个设置让HAProxy在客户端和前端之间保持一个持久的连接，并在所有后端服务器之间轮询HTTP请求。当然，要发挥这个设置的功效的话需要客户端同样启用keep-alive。

timeout client 30s
timeout server 30s
这两个设置一起用来设置 HAProxy发送请求的超时时长。实际上，HAProxy等待服务器返回信息给客户端需要多久呢？大多数应用都有某种最大延迟时间，因此你需要添加超时时长。对我们来说，API等待响应的最长时间是30秒，所以每个内部服务根据自身的服务级等级协议（SLA）都应该设置低于30秒的超时时长。注意：如果服务器缓慢地以流的方式传输一个字节，也就是每29秒传输一个字节的话，你将不能触发读超时，所以你可能需要有一个单独的线程监控这样的请求，以保证在适当的时间内完成传输。你还应当把客户端和服务端的超时时长设置为相同的值-即套接口上所期望的读超时时长。

timeout connect 3100
这是一个不同于客户端和服务端超时时长的超时时长！它是HAProxy应当用来试图连接主机所花费的时长。在RWilio以前的日子里，它设置为与服务器超时时长30秒相同的值，因此如果主机宕机的话，HAProxy将试图连接同一个主机30秒。当服务器和客户端主机位于同一个机器上或者在同一个局域网内（或者AZ主机的附近）的时候，这样的连接通常发生在毫秒级。我们允许在进一步处理默认的重传窗口时等待3秒，并且允许有小量的缓冲。
不像服务器超时时长，连接超时时长隐含着客户端的重新连接请求是安全的这层意思。

retries 2
option redispatch
当我说30秒的连接超时时长意味着HAProxy将在30秒内试图进行一次未连接上的连接的时候，我撒谎了。实践证明： 默认情况下,HAProxy将试图进行3次连接请求。因此30秒的连接超时实际上是120秒的连接超时，这违反了服务级别协议，而且意味着我们给客户兑现的是空头支票。
如果第一台主机关机了，那么通常假设HAProxy自动给第二台主机发送请求。不过这仅仅在HAProxy对这个主机进行健康检查后并标记这台主机已经关机的情况下才是这样的。如果一台主机关机了而且对它的健康检查花费了20秒，那么这时你正在对这台主机进行可能的20秒的无效请求。重新分发选项让最终的连接请求发送给另一台下游主机上，因此不同主机发送各自的请求在某种程度上保护了已经不健康的主机。
这两个设置混合在一起缩减重试次数到2，并且这也意味着在放弃这个连接并对另一台主机进行连接之前，我们试图对这台主机进行连接的最大超时时长只有8秒。

option httpchk GET /healthcheck
默认情况下，HAProxy只是对主机打开了一个TCP连接来检查这台主机是否启动。这种ping只能检测这台主机是否关机，不过不能确定它是不健康的（磁盘损坏，网络连接不正常）。httpchk选项将给位于后端的终端节点发送HTTP请求。后端可以进行自检，并回答自身是否健康。注意健康检查应当是相当保守的一种做法，而且通常还扩大了单台主机健康的范围。健康检查未通过将使HAProxy给这台主机不发送任何包，而且如果所有的主机同时都“不健康”，那么你将没有任何后端可依赖了。 我希望这篇文章对你有帮助-我已经在 这儿发布了HAProxy配置的所有更新版本。至于其他问题， 可以阅读手册，这样可以让服务器在性能、可靠性、可用性和稳定性方面得到很大的提高。希望这篇概览能够节省你的时间。

解决断电或者其他原因导致系统默认自动进入修复模式，导致系统无法正常开机。

桌面右键新建一个文档文本，双击打开文件新建文本文档，
复制以下命令到文本里面!
bcdedit /set {default} bootstatuspolicy ignoreallfailures
bcdedit /set {current} recoveryenabled No

在界面的左上角点击“文件”“另存为”，打开保存界面。在“保存格式”一行中选择“所有文件”；再把“文件名称”改为“XXXX.bat”的格式，保存为一个可运行的bat文件

然后桌面就出现了一个bat文件，只要双击文件就可以运行，系统窗口会一闪而过，接着可以删除该bat文件,电脑以后就不会出现修复模式了。

HAProxy 表示 High Availability Proxy ，是开源的负载均衡与代理软件。GitHub，Imgur，Instagram，Twitter 都在用它，阿里云的 SLB 服务也是基于 HAProxy 做的。

虚拟机

balancer：192.168.33.60
web1：192.168.33.61
web2：192.168.33.62
database：192.168.33.63
安装 HAProxy

yum install haproxy -y
systemctl start haproxy
systemctl enable haproxy
HAProxy 配置

HAProxy 的配置文件分成了两大部分：

Global：设置进程范围的参数。
Proxies：defaults，listen，frontend，backend …
HAProxy 配置：Global

复制默认的 haproxy.cfg 文件：

cd /etc/haproxy; sudo cp haproxy.cfg haproxy.cfg.bak
打开 haproxy.cfg ：

vi /etc/haproxy/haproxy.cfg
你会看到这里已经定义了两个部分，global 还有 defaults 。

在 defaults 里面，查找：

mode http
option httplog
把 http 替换成 tcp ：

mode tcp
option tcplog
HAProxy 配置：Proxies

frontend www
bind 192.168.33.60:80
default_backend web-backend
然后继续添加：

backend web-backend
balance roundrobin
mode tcp
server web1 192.168.33.61:80 check
server web2 192.168.33.62:80 check
重启 HAProxy

systemctl restart haproxy

在给nginx 配置了一个超长的域名后，通过 /usr/local/nginx/sbin/ngnix -t 检查配置文件时出现一下错误：
. 代码如下:
could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32

解决办法是在nginx的配置文件的http段中增加如下配置：
. 代码如下:
server_names_hash_bucket_size 64;

如果已经存在，需要加大后面的数值，注意：该数值是32的倍数为宜。
下面是nginx官方文档：
. 代码如下:
如果定义了大量名字，或者定义了非常长的名字，那可能需要在http配置块中使用server_names_hash_max_size和server_names_hash_bucket_size指令进行调整。server_names_hash_bucket_size的默认值可能是32，或者是64，或者是其他值，取决于CPU的缓存行的长度。如果这个值是32，那么定义“too.long.server.name.example.org”作为虚拟主机名就会失败，而nginx显示下面错误信息：
could not build the server_names_hash,
you should increase server_names_hash_bucket_size: 32
出现了这种情况，那就需要将指令的值扩大一倍：
http {
server_names_hash_bucket_size 64;
…
如果定义了大量名字，得到了另外一个错误：
could not build the server_names_hash,
you should increase either server_names_hash_max_size: 512
or server_names_hash_bucket_size: 32
那么应该先尝试设置server_names_hash_max_size的值差不多等于名字列表的名字总量。如果还不能解决问题，或者服务器启动非常缓慢，再尝试提高server_names_hash_bucket_size的值。