背景：机房迁移，原机房的从Mysql不再需要，主服务器也不存在此IP了，取消从服务器同步配置并关闭从。
mysql正确关闭slave取消主从同步
mysql> stop slave;
Query OK, 0 rows affected (0.02 sec)
reset slave;
change master to master_host=' '; #master_host=' ' 里面必须有内容，即使为空，也应该用空格代替，而不能什么都不写。
实践如下：
参考：https://blog.csdn.net/guoshaoliang789/article/details/86217508
mysql正确关闭slave取消主从同步
mysql> stop slave;
Query OK, 0 rows affected (0.02 sec)
reset slave;
change master to master_host=' '; #master_host=' ' 里面必须有内容，即使为空，也应该用空格代替，而不能什么都不写。
实践如下：
参考：https://blog.csdn.net/guoshaoliang789/article/details/86217508
yum localinstall influxdb-1.7.9.x86_64.rpm -y
vim /etc/influxdb/influxdb.conf
systemctl start influxdb
netstat -nlpt
ps -ef | grep influxdb
netstat -nlpt
influx -precision rfc3339 # connect to http://localhost:8086: Get http://localhost:8086/ping: dial tcp 127.0.0.1:8086: connect
influx -precision rfc3339
Connected to http://localhost:8086 version 1.7.9
InfluxDB shell version: 1.7.9
显示数据库
show databases
新建数据库
create database jidan
删除数据库
drop database jidan
使用指定数据库
use jidan
2、InfluxDB数据表操作
在InfluxDB当中，并没有表（table）这个概念，取而代之的是MEASUREMENTS，MEASUREMENTS的功能与传统数据库中的表一致，因此我们也可以将MEASUREMENTS称为InfluxDB中的表。
显示所有表
SHOW MEASUREMENTS
新建表
InfluxDB中没有显式的新建表的语句，只能通过insert数据的方式来建立新表。
insert jidanwendu,hostname=jidanindex value=442221834240i
其中 jidanwendu 就是表名，hostname是索引（tag），value=xx是记录值（field），记录值可以有多个，系统自带追加时间戳
> use jidan
Using database jidan
> insert jidanwendu,hostname=jidanindex value=442221834240i
>多个记录值：https://www.cnblogs.com/bonelee/p/6811728.html
> use jidan
Using database jidan
> INSERT jidanwendu,host=serverA,region=us_west value=0.64
或者添加数据时，自己写入时间戳
insert jidanwendu,hostname=jidanindex value=442221834240i 1435362189575692182
删除表
drop measurement jidanwendu
3、数据保存策略（Retention Policies）
influxDB是没有提供直接删除数据记录的方法，但是提供数据保存策略，主要用于指定数据保留时间，超过指定时间，就删除这部分数据。
查看当前数据库Retention Policies
show retention policies on "db_name"
创建新的Retention Policies
create retention policy "rp_name" on "jidan" duration 3w replication 1 default
rp_name：策略名；
db_name：具体的数据库名；
3w：保存3周，3周之前的数据将被删除，influxdb具有各种事件参数，比如：h（小时），d（天），w（星期）；
replication 1：副本个数，一般为1就可以了；
default：设置为默认策略
修改Retention Policies
alter retention policy "rp_name" on "jidan" duration 30d default
删除Retention Policies
drop retention policy "rp_name" on "jidan"
> create retention policy "rp_name" on "jidan" duration 3w replication 1 default
> alter retention policy "rp_name" on "jidan" duration 30d default
> drop retention policy "rp_name" on "jidan"
4、连续查询（Continuous Queries）
InfluxDB的连续查询是在数据库中自动定时启动的一组语句，语句中必须包含 SELECT 关键词和 GROUP BY time() 关键词。
InfluxDB会将查询结果放在指定的数据表中。
目的：使用连续查询是最优的降低采样率的方式，连续查询和存储策略搭配使用将会大大降低InfluxDB的系统占用量。而且使用连续查询后，数据会存放到指定的数据表中，这样就为以后统计不同精度的数据提供了方便。
新建连续查询
CREATE CONTINUOUS QUERY <cq_name> ON <database_name>
[RESAMPLE [EVERY <interval>] [FOR <interval>]]
BEGIN SELECT <function>(<stuff>)[,<function>(<stuff>)] INTO <different_measurement>
FROM <current_measurement> [WHERE <stuff>] GROUP BY time(<interval>)[,<stuff>]
END
样例：
CREATE CONTINUOUS QUERY rp_name ON jidan BEGIN SELECT mean(connected_clients), MEDIAN(connected_clients), MAX(connected_clients), MIN(connected_clients) INTO redis_clients_30m FROM redis_clients GROUP BY ip,port,time(30m) END
在jidan库中新建了一个名为 wj_30m 的连续查询，每三十分钟取一个connected_clients字段的平均值、中位值、最大值、最小值 redis_clients_30m 表中。使用的数据保留策略都是 default。
不同database样例：
CREATE CONTINUOUS QUERY rp_name ON jidan BEGIN SELECT mean(connected_clients), MEDIAN(connected_clients), MAX(connected_clients), MIN(connected_clients) INTO jidan_30.autogen.redis_clients_30m FROM jidan.autogen.redis_clients GROUP BY ip,port,time(30m) END
实践：
> CREATE CONTINUOUS QUERY rp_name ON jidan BEGIN SELECT mean(connected_clients), MEDIAN(connected_clients), MAX(connected_clients), MIN(connected_clients) INTO redis_clients_30m FROM redis_clients GROUP BY ip,port,time(30m) END
ERR: retention policy not found: jidan.rp_name #刚删了策略
> create retention policy "rp_name" on "jidan" duration 3w replication 1 default
> CREATE CONTINUOUS QUERY rp_name ON jidan BEGIN SELECT mean(connected_clients), MEDIAN(connected_clients), MAX(connected_clients), MIN(connected_clients) INTO redis_clients_30m FROM redis_clients GROUP BY ip,port,time(30m) END
显示所有已存在的连续查询
SHOW CONTINUOUS QUERIES
删除Continuous Queries
DROP CONTINUOUS QUERY <cq_name> ON <database_name>
将influxdb中的所有的数据库都备份下来，不加任何的参数
influxd backup -portable /tmp/data/total
更多查询条件：https://www.jianshu.com/p/a1344ca86e9b
来自：https://www.cnblogs.com/shhnwangjian/p/6897216.html?utm_source=itdadao&utm_medium=referral
PHP调用查询：https://blog.csdn.net/weixin_41621706/article/details/100630332
vim /etc/influxdb/influxdb.conf
systemctl start influxdb
netstat -nlpt
ps -ef | grep influxdb
netstat -nlpt
influx -precision rfc3339 # connect to http://localhost:8086: Get http://localhost:8086/ping: dial tcp 127.0.0.1:8086: connect
influx -precision rfc3339
Connected to http://localhost:8086 version 1.7.9
InfluxDB shell version: 1.7.9
显示数据库
show databases
新建数据库
create database jidan
删除数据库
drop database jidan
使用指定数据库
use jidan
2、InfluxDB数据表操作
在InfluxDB当中，并没有表（table）这个概念，取而代之的是MEASUREMENTS，MEASUREMENTS的功能与传统数据库中的表一致，因此我们也可以将MEASUREMENTS称为InfluxDB中的表。
显示所有表
SHOW MEASUREMENTS
新建表
InfluxDB中没有显式的新建表的语句，只能通过insert数据的方式来建立新表。
insert jidanwendu,hostname=jidanindex value=442221834240i
其中 jidanwendu 就是表名，hostname是索引（tag），value=xx是记录值（field），记录值可以有多个，系统自带追加时间戳
> use jidan
Using database jidan
> insert jidanwendu,hostname=jidanindex value=442221834240i
>多个记录值：https://www.cnblogs.com/bonelee/p/6811728.html
> use jidan
Using database jidan
> INSERT jidanwendu,host=serverA,region=us_west value=0.64
或者添加数据时，自己写入时间戳
insert jidanwendu,hostname=jidanindex value=442221834240i 1435362189575692182
删除表
drop measurement jidanwendu
3、数据保存策略（Retention Policies）
influxDB是没有提供直接删除数据记录的方法，但是提供数据保存策略，主要用于指定数据保留时间，超过指定时间，就删除这部分数据。
查看当前数据库Retention Policies
show retention policies on "db_name"
创建新的Retention Policies
create retention policy "rp_name" on "jidan" duration 3w replication 1 default
rp_name：策略名；
db_name：具体的数据库名；
3w：保存3周，3周之前的数据将被删除，influxdb具有各种事件参数，比如：h（小时），d（天），w（星期）；
replication 1：副本个数，一般为1就可以了；
default：设置为默认策略
修改Retention Policies
alter retention policy "rp_name" on "jidan" duration 30d default
删除Retention Policies
drop retention policy "rp_name" on "jidan"
> create retention policy "rp_name" on "jidan" duration 3w replication 1 default
> alter retention policy "rp_name" on "jidan" duration 30d default
> drop retention policy "rp_name" on "jidan"
4、连续查询（Continuous Queries）
InfluxDB的连续查询是在数据库中自动定时启动的一组语句，语句中必须包含 SELECT 关键词和 GROUP BY time() 关键词。
InfluxDB会将查询结果放在指定的数据表中。
目的：使用连续查询是最优的降低采样率的方式，连续查询和存储策略搭配使用将会大大降低InfluxDB的系统占用量。而且使用连续查询后，数据会存放到指定的数据表中，这样就为以后统计不同精度的数据提供了方便。
新建连续查询
CREATE CONTINUOUS QUERY <cq_name> ON <database_name>
[RESAMPLE [EVERY <interval>] [FOR <interval>]]
BEGIN SELECT <function>(<stuff>)[,<function>(<stuff>)] INTO <different_measurement>
FROM <current_measurement> [WHERE <stuff>] GROUP BY time(<interval>)[,<stuff>]
END
样例：
CREATE CONTINUOUS QUERY rp_name ON jidan BEGIN SELECT mean(connected_clients), MEDIAN(connected_clients), MAX(connected_clients), MIN(connected_clients) INTO redis_clients_30m FROM redis_clients GROUP BY ip,port,time(30m) END
在jidan库中新建了一个名为 wj_30m 的连续查询，每三十分钟取一个connected_clients字段的平均值、中位值、最大值、最小值 redis_clients_30m 表中。使用的数据保留策略都是 default。
不同database样例：
CREATE CONTINUOUS QUERY rp_name ON jidan BEGIN SELECT mean(connected_clients), MEDIAN(connected_clients), MAX(connected_clients), MIN(connected_clients) INTO jidan_30.autogen.redis_clients_30m FROM jidan.autogen.redis_clients GROUP BY ip,port,time(30m) END
实践：
> CREATE CONTINUOUS QUERY rp_name ON jidan BEGIN SELECT mean(connected_clients), MEDIAN(connected_clients), MAX(connected_clients), MIN(connected_clients) INTO redis_clients_30m FROM redis_clients GROUP BY ip,port,time(30m) END
ERR: retention policy not found: jidan.rp_name #刚删了策略
> create retention policy "rp_name" on "jidan" duration 3w replication 1 default
> CREATE CONTINUOUS QUERY rp_name ON jidan BEGIN SELECT mean(connected_clients), MEDIAN(connected_clients), MAX(connected_clients), MIN(connected_clients) INTO redis_clients_30m FROM redis_clients GROUP BY ip,port,time(30m) END
显示所有已存在的连续查询
SHOW CONTINUOUS QUERIES
删除Continuous Queries
DROP CONTINUOUS QUERY <cq_name> ON <database_name>
将influxdb中的所有的数据库都备份下来，不加任何的参数
influxd backup -portable /tmp/data/total
更多查询条件：https://www.jianshu.com/p/a1344ca86e9b
来自：https://www.cnblogs.com/shhnwangjian/p/6897216.html?utm_source=itdadao&utm_medium=referral
PHP调用查询：https://blog.csdn.net/weixin_41621706/article/details/100630332
Centos下_MysqL5.7(Server version: 5.7.12-log)在使用mysqldump命令备份数据库报错：mysqldump: [Warning] Using a password on the command line interface can be insecure.
mysql -u zabbix -p'q1w2***4' -P 3306 -h 127.0.0.1 -e "show status like 'Threads_cached';"|grep -v Value |awk '{print $2}'
mysql: [Warning] Using a password on the command line interface can be insecure.
3
===========================================================================
一）Server version: 5.7.12-log Source distribution下用 2>/dev/null并不行：
mysql -u zabbix -*****' -P 3306 -h 127.0.0.1 -e "show s
tatus like 'Threads_cached';"|grep -v Value |awk '{print $2}' 2>/dev/null
mysql: [Warning] Using a password on the command line interface can be insecure.
二）export MYSQL_PWD=666666 也不行。
阅读全文
mysql -u zabbix -p'q1w2***4' -P 3306 -h 127.0.0.1 -e "show status like 'Threads_cached';"|grep -v Value |awk '{print $2}'
mysql: [Warning] Using a password on the command line interface can be insecure.
3
===========================================================================
一）Server version: 5.7.12-log Source distribution下用 2>/dev/null并不行：
mysql -u zabbix -*****' -P 3306 -h 127.0.0.1 -e "show s
tatus like 'Threads_cached';"|grep -v Value |awk '{print $2}' 2>/dev/null
mysql: [Warning] Using a password on the command line interface can be insecure.
二）export MYSQL_PWD=666666 也不行。
阅读全文
背景：辅库删除了一个用户，主库也删除了一个用户，于是出现辅库启动时候出现错误，show slave status少一个YES。
错误：2018-03-30T18:41:50.906499+08:00 10 [ERROR] Slave SQL for channel '': Error 'Can't find any matching row in the user table' on query. Default database: ''. Query: 'GRANT DELETE ON *.* TO 'mha_rep'@'10.70.%'', Error_code: 1133
跳过一次或跳过1133都可以，如下：
mysql主从复制，经常会遇到错误而导致slave端复制中断，这个时候一般就需要人工干预，跳过错误才能继续
跳过错误有两种方式：
1.跳过指定数量的事务：
mysql>slave stop;
mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 #跳过一个事务
mysql>slave start
2.修改mysql的配置文件，通过slave_skip_errors参数来跳所有错误或指定类型的错误
vi /etc/my.cnf
[mysqld]
#slave-skip-errors=1062,1053,1146 #跳过指定error no类型的错误
#slave-skip-errors=all #跳过所有错误
来源：https://blog.csdn.net/seteor/article/details/17264633
错误：2018-03-30T18:41:50.906499+08:00 10 [ERROR] Slave SQL for channel '': Error 'Can't find any matching row in the user table' on query. Default database: ''. Query: 'GRANT DELETE ON *.* TO 'mha_rep'@'10.70.%'', Error_code: 1133
跳过一次或跳过1133都可以，如下：
mysql主从复制，经常会遇到错误而导致slave端复制中断，这个时候一般就需要人工干预，跳过错误才能继续
跳过错误有两种方式：
1.跳过指定数量的事务：
mysql>slave stop;
mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 #跳过一个事务
mysql>slave start
2.修改mysql的配置文件，通过slave_skip_errors参数来跳所有错误或指定类型的错误
vi /etc/my.cnf
[mysqld]
#slave-skip-errors=1062,1053,1146 #跳过指定error no类型的错误
#slave-skip-errors=all #跳过所有错误
来源：https://blog.csdn.net/seteor/article/details/17264633
mysql> RESET SLAVE ALL ;
Query OK, 0 rows affected (0.01 sec)
mysql> show slave status\G
Empty set (0.00 sec)
摘自 ：
执行reset slave;
mysql> stop slave;
Query OK, 0 rows affected (0.04 sec)
mysql> reset slave;
Query OK, 0 rows affected (0.02 sec)
在次执行会发现还是会有剩余配置信息
mysql> show slave status\G
最后，
执行reset slave all这个命令看看结果
mysql> reset slave all;
Query OK, 0 rows affected (0.00 sec)
mysql> show slave status\G
Empty set (0.00 sec)
果然没有了.reset slave执行的时候会删除master.info和relay-log.info但是同步信息会保留.要想彻底清除可以使用reset slave all.^_^,今天先到这里了.
Query OK, 0 rows affected (0.01 sec)
mysql> show slave status\G
Empty set (0.00 sec)
摘自 ：
执行reset slave;
mysql> stop slave;
Query OK, 0 rows affected (0.04 sec)
mysql> reset slave;
Query OK, 0 rows affected (0.02 sec)
在次执行会发现还是会有剩余配置信息
mysql> show slave status\G
最后，
执行reset slave all这个命令看看结果
mysql> reset slave all;
Query OK, 0 rows affected (0.00 sec)
mysql> show slave status\G
Empty set (0.00 sec)
果然没有了.reset slave执行的时候会删除master.info和relay-log.info但是同步信息会保留.要想彻底清除可以使用reset slave all.^_^,今天先到这里了.
今天在使用冷备份文件重做从库时遇到一个报错，值得研究一下。
版本：MySQL5.6.27
一、报错现象
dba:(none)> start slave;
ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository
这个时候查看error.log:
2017-07-17 16:19:02 9022 [ERROR] Failed to open the relay log './tjtx-96-67-relay-bin.017814' (relay_log_pos 172582079).
2017-07-17 16:19:02 9022 [ERROR] Could not find target log file mentioned in relay log info in the index file './tjtx135-1-95-relay-bin.index' during relay log initialization.
2017-07-17 16:19:02 9022 [ERROR] Failed to initialize the master info structure
2017-07-17 16:19:02 9022 [Note] Check error log for additional messages. You will not be able to start replication until the issue is resolved and the server restarted.
2017-07-17 16:19:02 9022 [Note] Event Scheduler: Loaded 0 events
2017-07-17 16:19:02 9022 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
Version: '5.6.27-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL)
2017-07-17 16:19:06 9022 [ERROR] Slave SQL: Slave failed to initialize relay log info structure from the repository, Error_code: 1872
从报错上看，意思是启动slave时，使用repository中信息初始化relay log结构失败了。为什么失败了？原来是从tjtx135-1-95-relay-bin.index文件中找不到tjtx-96-67-relay-bin.017814文件。到这里，答案就很清楚了，由于我使用的是冷备份文件恢复的实例，在mysql库中的slave_relay_log_info表中依然保留之前relay_log的信息，所以导致启动slave报错。
那如何解决呢？先来简单的了解MySQL Relay log的基础知识：
二、MySQL Relay log介绍
在MySQL复制结构下，Slave服务器会产生三种日志文件，用来保存主库的二进制日志事件以及relay log已执行到的位置和状态。
1、relay log 文件：由IO thread线程从主库读取的二进制日志事件组成，该日志被Slave上的SQL thread线程执行，从而实现数据的复制。
2、master info log：该文件保存slave连接master的状态以及配置信息，如用户名，密码，日志执行的位置等。在5.6版本之前，都是使用master.info文件，从5.6开始，通过在my.cnf 中配置 --master-info-repository=TABLE。这些信息会被写入mysql.slave_master_info 表中，代替原来的master.info文件了。
3、relay log info log：该文件保存slave上relay log的执行位置。在5.6版本之前，都是使用relay-log.info文件，从5.6开始，通过在my.cnf中配置 --relay-log-info-repository=TABLE，使用mysql.slave_relay_log_info表代替原来的文件。每次当slave上执行start slave时，就会读取该表中的位置信息。
新版本使用表来代替原来的文件，主要为了crash-safe replication，从而大大提高从库的可靠性。为了保证意外情况下从库的可靠性，mysql.slave_master_info和mysql.slave_relay_log_info表必须为事务性的表，从5.6.6起，这些表默认使用InnoDB存储引擎。在5.6.5及之前的版本默认使用MyISAM引擎，可用下面语句进行转换：
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
【注意】不要试图手工的更新、插入、删除以上两个表的内容，以免出现意料不到的问题。
三、问题解决
通过上面的报错以及relay log介绍，很容易知道由于mysql.slave_relay_log_info表中保留了以前的复制信息，导致新从库启动时无法找到对应文件，那么我们清理掉该表中的记录不就可以了。再次提醒，不要手动删该表数据，MySQL已经提供工具给我们了：reset slave：
reset slave干的那些事：
1、删除slave_master_info ，slave_relay_log_info两个表中数据；
2、删除所有relay log文件，并重新创建新的relay log文件；
3、不会改变gtid_executed 或者 gtid_purged的值
下面解决问题：
dba:(none)> reset slave;
Query OK, 0 rows affected (0.00 sec)
1
dba:(none)> change master to ......
1
2
dba:(none)> start slave;
Query OK, 0 rows affected (0.00 sec)
到这里问题解决了。
来自：https://www.cnblogs.com/mysql-dba/p/7201513.html
【经验】：以后用冷备份恢复实例后，在启动slave前，先进行reset slave清空下以前的旧信息。
【参考资料】：https://dev.mysql.com/doc/refman/5.6/en/slave-logs.html
https://dev.mysql.com/doc/refman/5.6/en/reset-slave.html
版本：MySQL5.6.27
一、报错现象
dba:(none)> start slave;
ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository
这个时候查看error.log:
2017-07-17 16:19:02 9022 [ERROR] Failed to open the relay log './tjtx-96-67-relay-bin.017814' (relay_log_pos 172582079).
2017-07-17 16:19:02 9022 [ERROR] Could not find target log file mentioned in relay log info in the index file './tjtx135-1-95-relay-bin.index' during relay log initialization.
2017-07-17 16:19:02 9022 [ERROR] Failed to initialize the master info structure
2017-07-17 16:19:02 9022 [Note] Check error log for additional messages. You will not be able to start replication until the issue is resolved and the server restarted.
2017-07-17 16:19:02 9022 [Note] Event Scheduler: Loaded 0 events
2017-07-17 16:19:02 9022 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
Version: '5.6.27-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL)
2017-07-17 16:19:06 9022 [ERROR] Slave SQL: Slave failed to initialize relay log info structure from the repository, Error_code: 1872
从报错上看，意思是启动slave时，使用repository中信息初始化relay log结构失败了。为什么失败了？原来是从tjtx135-1-95-relay-bin.index文件中找不到tjtx-96-67-relay-bin.017814文件。到这里，答案就很清楚了，由于我使用的是冷备份文件恢复的实例，在mysql库中的slave_relay_log_info表中依然保留之前relay_log的信息，所以导致启动slave报错。
那如何解决呢？先来简单的了解MySQL Relay log的基础知识：
二、MySQL Relay log介绍
在MySQL复制结构下，Slave服务器会产生三种日志文件，用来保存主库的二进制日志事件以及relay log已执行到的位置和状态。
1、relay log 文件：由IO thread线程从主库读取的二进制日志事件组成，该日志被Slave上的SQL thread线程执行，从而实现数据的复制。
2、master info log：该文件保存slave连接master的状态以及配置信息，如用户名，密码，日志执行的位置等。在5.6版本之前，都是使用master.info文件，从5.6开始，通过在my.cnf 中配置 --master-info-repository=TABLE。这些信息会被写入mysql.slave_master_info 表中，代替原来的master.info文件了。
3、relay log info log：该文件保存slave上relay log的执行位置。在5.6版本之前，都是使用relay-log.info文件，从5.6开始，通过在my.cnf中配置 --relay-log-info-repository=TABLE，使用mysql.slave_relay_log_info表代替原来的文件。每次当slave上执行start slave时，就会读取该表中的位置信息。
新版本使用表来代替原来的文件，主要为了crash-safe replication，从而大大提高从库的可靠性。为了保证意外情况下从库的可靠性，mysql.slave_master_info和mysql.slave_relay_log_info表必须为事务性的表，从5.6.6起，这些表默认使用InnoDB存储引擎。在5.6.5及之前的版本默认使用MyISAM引擎，可用下面语句进行转换：
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
【注意】不要试图手工的更新、插入、删除以上两个表的内容，以免出现意料不到的问题。
三、问题解决
通过上面的报错以及relay log介绍，很容易知道由于mysql.slave_relay_log_info表中保留了以前的复制信息，导致新从库启动时无法找到对应文件，那么我们清理掉该表中的记录不就可以了。再次提醒，不要手动删该表数据，MySQL已经提供工具给我们了：reset slave：
reset slave干的那些事：
1、删除slave_master_info ，slave_relay_log_info两个表中数据；
2、删除所有relay log文件，并重新创建新的relay log文件；
3、不会改变gtid_executed 或者 gtid_purged的值
下面解决问题：
dba:(none)> reset slave;
Query OK, 0 rows affected (0.00 sec)
1
dba:(none)> change master to ......
1
2
dba:(none)> start slave;
Query OK, 0 rows affected (0.00 sec)
到这里问题解决了。
来自：https://www.cnblogs.com/mysql-dba/p/7201513.html
【经验】：以后用冷备份恢复实例后，在启动slave前，先进行reset slave清空下以前的旧信息。
【参考资料】：https://dev.mysql.com/doc/refman/5.6/en/slave-logs.html
https://dev.mysql.com/doc/refman/5.6/en/reset-slave.html
interactive_timeout ：连接空闲超时时间。与服务器端无交互状态的连接，直到被服务器端强制关闭而等待的时间。
interactive_timeout和wait_timeout意义虽然相同，但是有使用对象有本质的区别。interactive_timeout针对交互式连接（比如通过mysql客户端连接数据库），wait_timeout针对非交互式连接（比如一般在PHP中使用PDO连接数据库，当然你可以设置CLIENT_INTERACTIVE选项来改变）。所谓的交互式连接，即在mysql_real_connect()函数中使用了CLIENT_INTERACTIVE选项。
wait_timeout：连接空闲超时时间。与服务器端无交互状态的连接，直到被服务器端强制关闭而等待的时间。可以认为是服务器端连接空闲的时间，空闲超过这个时间将自动关闭。
交互连接：
interactive_timeout 需在mysql_connect()设置CLIENT_INTERACTIVE选项后起作用，并被赋值为wait_timeout； #Mysql自己的客户端mysql命令。
mysql>set global wait_timeout = 60; 对当前交互链接有效； (由于mysql的BUG所有这边必须加global)
mysql>set global interactive_timeout = 60; 对后续起的交互链接有效；
解决MySQL server has gone away
应用程序（比如PHP）长时间的执行批量的MYSQL语句。最常见的就是采集或者新旧数据转化。
解决方案：
在my.cnf文件中添加或者修改以下两个变量：
wait_timeout=2880000
interactive_timeout = 2880000
关于两个变量的具体说明可以google或者看官方手册。如果不能修改my.cnf，则可以在连接数据库的时候设置CLIENT_INTERACTIVE，比如：
sql = "set interactive_timeout=24*3600";
mysql_real_query(...)
wait_timeout过大有弊端，其体现就是MySQL里大量的SLEEP进程无法及时释放，拖累系统性能，不过也不能把这个指设置的过小，否则你可能会遭遇到“MySQL has gone away”之类的问题，通常来说，我觉得把wait_timeout设置为10是个不错的选择，但某些情况下可能也会出问题，比如说有一个CRON脚本，其中两次SQL查询的间隔时间大于10秒的话，那么这个设置就有问题了（当然，这也不是不能解决的问题，你可以在程序里时不时mysql_ping一下，以便服务器知道你还活着，重新计算wait_timeout时间）
本质：
变量wait_timeout：服务器关闭非交互连接之前等待活动的秒数。也就是说你PHP获取一次数据后作计算了，并没有释放Mysql连接句柄，而你处理完后，继续获取数据，这个中间等待的秒数。 为了防止出现这个问题，用了mysql_ping:https://mo2g.com/view/128/
问题：这个秒数，DBA一般写10秒，能否突破和Mysql的Client一样，让它的值和interactive_timeout一样呢？
From:http://www.04007.cn/article/292.html
============================================================================================
总之，Mysql的原生客户端，在设置其wait_timeout的值时不受全局的设置限制，均等于全局（/etc/my.cnf）interactive_timeout的值,而PHP则并不改变全局的值，而是里面配置wait_timeout多少，此次连接就是多少，当然，也提供了类似Mysql自带客户端的参数。
阅读全文
interactive_timeout和wait_timeout意义虽然相同，但是有使用对象有本质的区别。interactive_timeout针对交互式连接（比如通过mysql客户端连接数据库），wait_timeout针对非交互式连接（比如一般在PHP中使用PDO连接数据库，当然你可以设置CLIENT_INTERACTIVE选项来改变）。所谓的交互式连接，即在mysql_real_connect()函数中使用了CLIENT_INTERACTIVE选项。
wait_timeout：连接空闲超时时间。与服务器端无交互状态的连接，直到被服务器端强制关闭而等待的时间。可以认为是服务器端连接空闲的时间，空闲超过这个时间将自动关闭。
交互连接：
interactive_timeout 需在mysql_connect()设置CLIENT_INTERACTIVE选项后起作用，并被赋值为wait_timeout； #Mysql自己的客户端mysql命令。
mysql>set global wait_timeout = 60; 对当前交互链接有效； (由于mysql的BUG所有这边必须加global)
mysql>set global interactive_timeout = 60; 对后续起的交互链接有效；
解决MySQL server has gone away
应用程序（比如PHP）长时间的执行批量的MYSQL语句。最常见的就是采集或者新旧数据转化。
解决方案：
在my.cnf文件中添加或者修改以下两个变量：
wait_timeout=2880000
interactive_timeout = 2880000
关于两个变量的具体说明可以google或者看官方手册。如果不能修改my.cnf，则可以在连接数据库的时候设置CLIENT_INTERACTIVE，比如：
sql = "set interactive_timeout=24*3600";
mysql_real_query(...)
wait_timeout过大有弊端，其体现就是MySQL里大量的SLEEP进程无法及时释放，拖累系统性能，不过也不能把这个指设置的过小，否则你可能会遭遇到“MySQL has gone away”之类的问题，通常来说，我觉得把wait_timeout设置为10是个不错的选择，但某些情况下可能也会出问题，比如说有一个CRON脚本，其中两次SQL查询的间隔时间大于10秒的话，那么这个设置就有问题了（当然，这也不是不能解决的问题，你可以在程序里时不时mysql_ping一下，以便服务器知道你还活着，重新计算wait_timeout时间）
本质：
变量wait_timeout：服务器关闭非交互连接之前等待活动的秒数。也就是说你PHP获取一次数据后作计算了，并没有释放Mysql连接句柄，而你处理完后，继续获取数据，这个中间等待的秒数。 为了防止出现这个问题，用了mysql_ping:https://mo2g.com/view/128/
问题：这个秒数，DBA一般写10秒，能否突破和Mysql的Client一样，让它的值和interactive_timeout一样呢？
From:http://www.04007.cn/article/292.html
============================================================================================
总之，Mysql的原生客户端，在设置其wait_timeout的值时不受全局的设置限制，均等于全局（/etc/my.cnf）interactive_timeout的值,而PHP则并不改变全局的值，而是里面配置wait_timeout多少，此次连接就是多少，当然，也提供了类似Mysql自带客户端的参数。
阅读全文
The MySQL server is running with the --read-only option so it cannot execute
解决办法：
mysql> set global read_only=0;
（关掉新主库的只读属性）
flush privileges;
set global read_only=1;(读写属相)
flush privileges;
出现：
The MySQL server is running with the --read-only option so it cannot execute
来自：http://www.cnblogs.com/xionghui/archive/2013/03/01/2939342.html
解决办法：
mysql> set global read_only=0;
（关掉新主库的只读属性）
flush privileges;
set global read_only=1;(读写属相)
flush privileges;
出现：
The MySQL server is running with the --read-only option so it cannot execute
来自：http://www.cnblogs.com/xionghui/archive/2013/03/01/2939342.html
问题：redis-3.0.7升级到redis-3.2.10，之前的数据文件/data/redis/6379/dump.rdb 没有删除，service redis start会报错，如下：
当前版本的redis无法处理version=7的RDB格式，这才明白是兼容性问题，但这种“向前兼容”一般很难做到的。
解决办法：删除rdb文件/var/lib/redis/6379/dump.rdb，重启redis就行了。
如果能解决掉Slave没有问题，那么， 线上坏了一台Slave的Redis可以直接替换掉即可：
在RPM打包发现：redis-3.0.7（线上）升级到redis-3.2.10的旧版本的dump.rdb格式无法启动如下：
但是经测试可以做Slave同步，现在CentOS6和CentOS7均升级至和epll仓库一样版本redis-3.2.10。
当前版本的redis无法处理version=7的RDB格式，这才明白是兼容性问题，但这种“向前兼容”一般很难做到的。
解决办法：删除rdb文件/var/lib/redis/6379/dump.rdb，重启redis就行了。
如果能解决掉Slave没有问题，那么， 线上坏了一台Slave的Redis可以直接替换掉即可：
在RPM打包发现：redis-3.0.7（线上）升级到redis-3.2.10的旧版本的dump.rdb格式无法启动如下：
但是经测试可以做Slave同步，现在CentOS6和CentOS7均升级至和epll仓库一样版本redis-3.2.10。
背景：就是想把博文里的一些链接给批量替换一下，如：justwinit.cn 替换为jackxiang.com, 这样式的。
二）如对博客里涉及到的HostIP进行替换：
遇到这么个情况：
比如：
Msql里面的某个表的某个字段里面存储的是一个人的地址，有一天这个地址的里面的某个地
名变了，那么他的地址也就要变：
比如：
原来是：
现在这个成都市变为了 “天府”市···
所以，addr字段里面的所有的值，都要把成都市改为 天府市
解决方法：
sql语句：
[sql] view plain copy
update 表名 set 字段名=REPLACE (字段名,'原来的值','要修改的值')
当然，也可以添加条件：
最后的效果：
[sql] view plain copy
number addr
01 四川省天府市XXXXXX街道05号
02 四川省天府市XXXXXX街道07号
03 四川省天府市XXXXXX街道09号
04 四川省天府市XXXXXX街道04号
来自：http://blog.csdn.net/yuekunge/article/details/14170055
二）如对博客里涉及到的HostIP进行替换：
遇到这么个情况：
比如：
Msql里面的某个表的某个字段里面存储的是一个人的地址，有一天这个地址的里面的某个地
名变了，那么他的地址也就要变：
比如：
原来是：
现在这个成都市变为了 “天府”市···
所以，addr字段里面的所有的值，都要把成都市改为 天府市
解决方法：
sql语句：
[sql] view plain copy
update 表名 set 字段名=REPLACE (字段名,'原来的值','要修改的值')
当然，也可以添加条件：
最后的效果：
[sql] view plain copy
number addr
01 四川省天府市XXXXXX街道05号
02 四川省天府市XXXXXX街道07号
03 四川省天府市XXXXXX街道09号
04 四川省天府市XXXXXX街道04号
来自：http://blog.csdn.net/yuekunge/article/details/14170055
lam是用php写的，所以使用时需要php支持很多模块，像对ldap的支持,对zip的支持。
php安装模块见http://fffo.blog.163.com/blog/static/211913068201401464238334/
1、官网下载
wget http://prdownloads.sourceforge.net/lam/ldap-account-manager-4.3.tar.bz2?download
2、解压
tar -xjf ldap-account-manager-4.3.tar.bz2
3、直接移动到apache 根目录
mv ldap-account-manager-4.3 /usr/local/apache/htdocs/lam
4、给它可以访问的权限
chmod 777 -R /usr/local/apache/htdocs/lam
5、进入配置目录
cd /usr/local/apache/htdocs/lam/config
6、创建主参数文件
cp config.cfg_sample config.cfg
7、创建连接ldap服务器参数文件
cp lam.conf_sample lam.conf
vim lam.conf
修改 所有的dc=1v,dc=cn
8、web访问
http://203.195.187.200/lam/templates/login.php
上面的模式是只限管理员登录模式。现在切换到用户登录模式
点击LAM配置——>编辑服务器配置文件——>默认密码是lam（可修改）——>通用设置——>安全设定
From:http://blog.csdn.net/u012461550/article/details/42608781
我的是在：
/usr/local/lam/etc/unix.conf
php安装模块见http://fffo.blog.163.com/blog/static/211913068201401464238334/
1、官网下载
wget http://prdownloads.sourceforge.net/lam/ldap-account-manager-4.3.tar.bz2?download
2、解压
tar -xjf ldap-account-manager-4.3.tar.bz2
3、直接移动到apache 根目录
mv ldap-account-manager-4.3 /usr/local/apache/htdocs/lam
4、给它可以访问的权限
chmod 777 -R /usr/local/apache/htdocs/lam
5、进入配置目录
cd /usr/local/apache/htdocs/lam/config
6、创建主参数文件
cp config.cfg_sample config.cfg
7、创建连接ldap服务器参数文件
cp lam.conf_sample lam.conf
vim lam.conf
修改 所有的dc=1v,dc=cn
8、web访问
http://203.195.187.200/lam/templates/login.php
上面的模式是只限管理员登录模式。现在切换到用户登录模式
点击LAM配置——>编辑服务器配置文件——>默认密码是lam（可修改）——>通用设置——>安全设定
From:http://blog.csdn.net/u012461550/article/details/42608781
我的是在：
/usr/local/lam/etc/unix.conf
MySQL 5.6 警告信息 command line interface can be insecure 修复
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
在命令行输入密码，就会提示这些安全警告信息。
Warning: Using a password on the command line interface can be insecure.
注: mysql -u root -pPASSWORD 或 mysqldump -u root -pPASSWORD 都会输出这样的警告信息.
1、针对mysql
mysql -u root -pPASSWORD 改成mysql -u root -p 在输入密码即可.
2、mysqldump就比较麻烦了，通常都写在scripts脚本中。
解决方法：
对于 mysqldump 要如何避免出现(Warning: Using a password on the command line interface can be insecure.) 警告信息呢?
vim /etc/mysql/my.cnf
[mysqldump]
user=your_backup_user_name
password=your_backup_password
修改完配置文件后, 只需要执行mysqldump 脚本就可以了。备份脚本中不需要涉及用户名密码相关信息。
来自：http://880314.blog.51cto.com/4008847/1348413
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
在命令行输入密码，就会提示这些安全警告信息。
Warning: Using a password on the command line interface can be insecure.
注: mysql -u root -pPASSWORD 或 mysqldump -u root -pPASSWORD 都会输出这样的警告信息.
1、针对mysql
mysql -u root -pPASSWORD 改成mysql -u root -p 在输入密码即可.
2、mysqldump就比较麻烦了，通常都写在scripts脚本中。
解决方法：
对于 mysqldump 要如何避免出现(Warning: Using a password on the command line interface can be insecure.) 警告信息呢?
vim /etc/mysql/my.cnf
[mysqldump]
user=your_backup_user_name
password=your_backup_password
修改完配置文件后, 只需要执行mysqldump 脚本就可以了。备份脚本中不需要涉及用户名密码相关信息。
来自：http://880314.blog.51cto.com/4008847/1348413
MySQL 5.6 警告信息 command line interface can be insecure 修复
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
在命令行输入密码，就会提示这些安全警告信息。
Warning: Using a password on the command line interface can be insecure.
注: mysql -u root -pPASSWORD 或 mysqldump -u root -pPASSWORD 都会输出这样的警告信息.
1、针对mysql
mysql -u root -pPASSWORD 改成mysql -u root -p 在输入密码即可.
2、mysqldump就比较麻烦了，通常都写在scripts脚本中。
解决方法：
对于 mysqldump 要如何避免出现(Warning: Using a password on the command line interface can be insecure.) 警告信息呢?
vim /etc/mysql/my.cnf
[mysqldump]
user=your_backup_user_name
password=your_backup_password
修改完配置文件后, 只需要执行mysqldump 脚本就可以了。备份脚本中不需要涉及用户名密码相关信息。
来自：http://880314.blog.51cto.com/4008847/1348413
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
在命令行输入密码，就会提示这些安全警告信息。
Warning: Using a password on the command line interface can be insecure.
注: mysql -u root -pPASSWORD 或 mysqldump -u root -pPASSWORD 都会输出这样的警告信息.
1、针对mysql
mysql -u root -pPASSWORD 改成mysql -u root -p 在输入密码即可.
2、mysqldump就比较麻烦了，通常都写在scripts脚本中。
解决方法：
对于 mysqldump 要如何避免出现(Warning: Using a password on the command line interface can be insecure.) 警告信息呢?
vim /etc/mysql/my.cnf
[mysqldump]
user=your_backup_user_name
password=your_backup_password
修改完配置文件后, 只需要执行mysqldump 脚本就可以了。备份脚本中不需要涉及用户名密码相关信息。
来自：http://880314.blog.51cto.com/4008847/1348413
问题现象：在tail -f /data/logs/mysql/error.log日志中出现大量的如下信息(web用的是Zabbix，设置连接超时时间为100秒)：
' host: 'localhost' (Got timeout reading communication packets)
2017-02-05T15:30:19.272811+08:00 28546 [Note] Aborted connection 28546 to db: 'zabbix' user: 'zabbix' host: 'localhost' (Got timeout reading communication packets)
2017-02-05T15:30:22.388624+08:00 28547 [Note] Aborted connection 28547 to db: 'zabbix' user: 'zabbix' host: 'localhost' (Got timeout reading communication packets)
2017-02-05T15:30:27.119216+08:00 28554 [Note] Aborted connection 28554 to db: 'zabbix' user: 'zabbix' host: 'localhost' (Got timeout reading communication packets)
解决办法：
修改[root@lovebuy114 ~]# grep timeout /etc/my.cnf
interactive_timeout = 120
wait_timeout = 120
log_warnings=1 //注意，我这里原来是2。修改成1后，问题现象果然但是已经不存在了。
在命令行中可以这样修改：
mysql>set global log_warning=1;
mysql>set global interactive_timeout = 120;
mysql>set global wait_timeout = 120;
参数简要说明：
1)interactive_timeout:
参数含义：服务器关闭交互式连接前等待活动的秒数。交互式客户端定义为在mysql_real_connect()中使用CLIENT_INTERACTIVE选项的客户端。
参数默认值：28800秒（8小时）
解决无Notice的办法：
grep timeout /etc/my.cnf innodb_lock_wait_timeout = 60
interactive_timeout = 28800
wait_timeout = 22
grep log_warnings /etc/my.cnflog_warnings=2
From:http://blog.csdn.net/jamesyao008/article/details/45098073
修改后，无效，原因是现在是变成了Notice，不是警告：
tail -f /data/logs/mysql/error.log
2017-02-05T15:38:19.678134+08:00 128 [Note] Aborted connection 128 to db: 'zabbix' user: 'zabbix' host: 'localhost' (Got timeout reading communication packets)
2017-02-05T15:38:22.452504+08:00 131 [Note] Aborted connection 131 to db: 'zabbix' user: 'zabbix' host: 'localhost' (Got timeout reading communication packets)
' host: 'localhost' (Got timeout reading communication packets)
2017-02-05T15:30:19.272811+08:00 28546 [Note] Aborted connection 28546 to db: 'zabbix' user: 'zabbix' host: 'localhost' (Got timeout reading communication packets)
2017-02-05T15:30:22.388624+08:00 28547 [Note] Aborted connection 28547 to db: 'zabbix' user: 'zabbix' host: 'localhost' (Got timeout reading communication packets)
2017-02-05T15:30:27.119216+08:00 28554 [Note] Aborted connection 28554 to db: 'zabbix' user: 'zabbix' host: 'localhost' (Got timeout reading communication packets)
解决办法：
修改[root@lovebuy114 ~]# grep timeout /etc/my.cnf
interactive_timeout = 120
wait_timeout = 120
log_warnings=1 //注意，我这里原来是2。修改成1后，问题现象果然但是已经不存在了。
在命令行中可以这样修改：
mysql>set global log_warning=1;
mysql>set global interactive_timeout = 120;
mysql>set global wait_timeout = 120;
参数简要说明：
1)interactive_timeout:
参数含义：服务器关闭交互式连接前等待活动的秒数。交互式客户端定义为在mysql_real_connect()中使用CLIENT_INTERACTIVE选项的客户端。
参数默认值：28800秒（8小时）
解决无Notice的办法：
grep timeout /etc/my.cnf innodb_lock_wait_timeout = 60
interactive_timeout = 28800
wait_timeout = 22
grep log_warnings /etc/my.cnflog_warnings=2
From:http://blog.csdn.net/jamesyao008/article/details/45098073
修改后，无效，原因是现在是变成了Notice，不是警告：
tail -f /data/logs/mysql/error.log
2017-02-05T15:38:19.678134+08:00 128 [Note] Aborted connection 128 to db: 'zabbix' user: 'zabbix' host: 'localhost' (Got timeout reading communication packets)
2017-02-05T15:38:22.452504+08:00 131 [Note] Aborted connection 131 to db: 'zabbix' user: 'zabbix' host: 'localhost' (Got timeout reading communication packets)
当开启MySQL数据库主从时，会产生大量如mysql-bin.00000* log的文件，这会大量耗费您的硬盘空间。
mysql-bin.000001
mysql-bin.000002
mysql-bin.000003
mysql-bin.000004
mysql-bin.000005
…
有三种解决方法：1.关闭mysql主从，关闭binlog；2.开启mysql主从，设置expire_logs_days；3.手动清除binlog文件，> PURGE MASTER LOGS TO ‘MySQL-bin.010′;
实现：
1.关闭mysql主从，关闭binlog
# vim /etc/my.cnf //注释掉log-bin,binlog_format # Replication Master Server (default) # binary logging is required for replication # log-bin=mysql-bin # binary logging format - mixed recommended # binlog_format=mixed
然后重启数据库
2.重启mysql,开启mysql主从，设置expire_logs_days
# vim /etc/my.cnf //修改expire_logs_days,x是自动删除的天数，一般将x设置为短点，如10 expire_logs_days = x //二进制日志自动删除的天数。默认值为0,表示“没有自动删除”
此方法需要重启mysql，附录有关于expire_logs_days的英文说明
当然也可以不重启mysql,开启mysql主从，直接在mysql里设置expire_logs_days
> show binary logs; > show variables like '%log%'; > set global expire_logs_days = 10;
3.手动清除binlog文件
# /usr/local/mysql/bin/mysql -u root -p > PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY); //删除10天前的MySQL binlog日志,附录2有关于PURGE MASTER LOGS手动删除用法及示例 > show master logs;
也可以重置master，删除所有binlog文件：
# /usr/local/mysql/bin/mysql -u root -p > reset master; //附录3有清除binlog时，对从mysql的影响说明
附录：
1.expire_logs_days英文说明
Where X is the number of days you’d like to keep them around. I would recommend 10, but this depends on how busy your MySQL server is and how fast these log files grow. Just make sure it is longer than the slowest slave takes to replicate the data from your master.
Just a side note: You know that you should do this anyway, but make sure you back up your mysql database. The binary log can be used to recover the database in certain situations; so having a backup ensures that if your database server does crash, you will be able to recover the data.
2.PURGE MASTER LOGS手动删除用法及示例,MASTER和BINARY是同义词
> PURGE {MASTER | BINARY} LOGS TO 'log_name' > PURGE {MASTER | BINARY} LOGS BEFORE 'date'
删除指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件中的清单中被删除MySQL BIN-LOG 日志，这样被给定的日志成为第一个。
实例：
> PURGE MASTER LOGS TO 'MySQL-bin.010'; //清除MySQL-bin.010日志 > PURGE MASTER LOGS BEFORE '2008-06-22 13:00:00'; //清除2008-06-22 13:00:00前binlog日志 > PURGE MASTER LOGS BEFORE DATE_SUB( NOW, INTERVAL 3 DAY); //清除3天前binlog日志BEFORE，变量的date自变量可以为'YYYY-MM-DD hh:mm:ss'格式。
3.清除binlog时，对从mysql的影响
如果您有一个活性的从属服务器，该服务器当前正在读取您正在试图删除的日志之一，则本语句不会起作用，而是会失败，并伴随一个错误。不过，如果从属服务器是休止的，并且您碰巧清理了其想要读取的日志之一，则从属服务器启动后不能复制。当从属服务器正在复制时，本语句可以安全运行。您不需要停止它们。
来自：http://m.toutiao.com/i6371662680515674625/?tt_from=copy_link&utm_campaign=client_share&app=news_article&utm_source=copy_link&iid=6966412074&utm_medium=toutiao_ios
我的这种是因为Mysql正在运行，然后又启动时会出现这个问题，直接pkill -9 mysql:
手工运行：
服务器症状：
今天网站web页面提交内容到数据库，发现出错了，一直提交不了，数找了下原因，发现数据写不进去！第一反应，重启mysql数据库，一直执行中，停止不了也启动不了，直觉告诉我磁盘满了 ！用df命令查了下，果然磁盘满了，因为当时分区采用系统默认，不知道为什么不能自动扩容！以后在处理这个问题！如图所示：
[root@rekfan ~]# df
文件系统 1K-块 已用 可用 已用% 挂载点
/dev/mapper/vg_rekfan-lv_root
51606140 47734848 1249852 100% /
tmpfs 1953396 88 1953308 1% /dev/shm
/dev/sda1 495844 37062 433182 8% /boot
/dev/mapper/vg_rekfan-lv_home
229694676 191796 217835016 1% /home
[root@rekfan ~]#
删除了些没用的日志后，重新启动数据库还是出错。http://blog.rekfan.com/?p=186
[root@rekfan mysql]# service mysql restart
MySQL server PID file could not be found![失败]
Starting MySQL...The server quit without updating PID file (/usr/local/mysql/data/rekfan.pid).[失败]
google了下 ，问题可能的原因有多种，具体什么原因最好的办法是先查看下错误日志：
1.可能是/usr/local/mysql/data/rekfan.pid文件没有写的权限
解决方法 ：给予权限，执行 “chown -R mysql:mysql /var/data” “chmod -R 755 /usr/local/mysql/data” 然后重新启动mysqld！
2.可能进程里已经存在mysql进程
解决方法：用命令“ps -ef|grep mysqld”查看是否有mysqld进程，如果有使用“kill -9 进程号”杀死，然后重新启动mysqld！
3.可能是第二次在机器上安装mysql，有残余数据影响了服务的启动。
解决方法：去mysql的数据目录/data看看，如果存在mysql-bin.index，就赶快把它删除掉吧，它就是罪魁祸首了。本人就是使用第三条方法解决的 ！http://blog.rekfan.com/?p=186
4.mysql在启动时没有指定配置文件时会使用/etc/my.cnf配置文件，请打开这个文件查看在[mysqld]节下有没有指定数据目录(datadir)。
解决方法：请在[mysqld]下设置这一行：datadir = /usr/local/mysql/data
5.skip-federated字段问题
解决方法：检查一下/etc/my.cnf文件中有没有没被注释掉的skip-federated字段，如果有就立即注释掉吧。
6.错误日志目录不存在
解决方法：使用“chown” “chmod”命令赋予mysql所有者及权限
7.selinux惹的祸，如果是centos系统，默认会开启selinux
解决方法：关闭它，打开/etc/selinux/config，把SELINUX=enforcing改为SELINUX=disabled后存盘退出重启机器试试。
来自：http://blog.rekfan.com/articles/186.html
手工运行：
服务器症状：
今天网站web页面提交内容到数据库，发现出错了，一直提交不了，数找了下原因，发现数据写不进去！第一反应，重启mysql数据库，一直执行中，停止不了也启动不了，直觉告诉我磁盘满了 ！用df命令查了下，果然磁盘满了，因为当时分区采用系统默认，不知道为什么不能自动扩容！以后在处理这个问题！如图所示：
[root@rekfan ~]# df
文件系统 1K-块 已用 可用 已用% 挂载点
/dev/mapper/vg_rekfan-lv_root
51606140 47734848 1249852 100% /
tmpfs 1953396 88 1953308 1% /dev/shm
/dev/sda1 495844 37062 433182 8% /boot
/dev/mapper/vg_rekfan-lv_home
229694676 191796 217835016 1% /home
[root@rekfan ~]#
删除了些没用的日志后，重新启动数据库还是出错。http://blog.rekfan.com/?p=186
[root@rekfan mysql]# service mysql restart
MySQL server PID file could not be found![失败]
Starting MySQL...The server quit without updating PID file (/usr/local/mysql/data/rekfan.pid).[失败]
google了下 ，问题可能的原因有多种，具体什么原因最好的办法是先查看下错误日志：
1.可能是/usr/local/mysql/data/rekfan.pid文件没有写的权限
解决方法 ：给予权限，执行 “chown -R mysql:mysql /var/data” “chmod -R 755 /usr/local/mysql/data” 然后重新启动mysqld！
2.可能进程里已经存在mysql进程
解决方法：用命令“ps -ef|grep mysqld”查看是否有mysqld进程，如果有使用“kill -9 进程号”杀死，然后重新启动mysqld！
3.可能是第二次在机器上安装mysql，有残余数据影响了服务的启动。
解决方法：去mysql的数据目录/data看看，如果存在mysql-bin.index，就赶快把它删除掉吧，它就是罪魁祸首了。本人就是使用第三条方法解决的 ！http://blog.rekfan.com/?p=186
4.mysql在启动时没有指定配置文件时会使用/etc/my.cnf配置文件，请打开这个文件查看在[mysqld]节下有没有指定数据目录(datadir)。
解决方法：请在[mysqld]下设置这一行：datadir = /usr/local/mysql/data
5.skip-federated字段问题
解决方法：检查一下/etc/my.cnf文件中有没有没被注释掉的skip-federated字段，如果有就立即注释掉吧。
6.错误日志目录不存在
解决方法：使用“chown” “chmod”命令赋予mysql所有者及权限
7.selinux惹的祸，如果是centos系统，默认会开启selinux
解决方法：关闭它，打开/etc/selinux/config，把SELINUX=enforcing改为SELINUX=disabled后存盘退出重启机器试试。
来自：http://blog.rekfan.com/articles/186.html
