mysql
1.如果只用redolog或者binlog 可以吗
什么是WAL
MySQL（innodb引擎)中的WAL技术的全称是Write-Ahead-Logging，它的关键点是先写日志，再写磁盘；
MySQL中更新一条语句的流程
（深色service层执行器，浅色存储引擎）
具体流程：
10server层中的执行器先找引擎取id=2这一行。id是主键，引擎直接用树搜索找到这一行。如果id=2这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回；
2.执行器拿到引擎给的行数据，对相应的值进行处理（加1），再调用引擎接口写入这行新数据；
3.引擎将这行新数据更新到内存中，同时将这个更新操作记录到redo log里面，此时redo log处于prepare状态。然后通知执行器执行完成了，随时可以提交事务；
4.执行器生成这个操作的binlog，并把binlog写入磁盘；
5执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成提交（commit）状态，完成更新；
6.（redo log的写入分成两个步骤prepare和commit，这就是两阶段提交)
两阶段提交中，MySQL异常重启（crash），是如何保证数据完整性的？
在上图时刻A中，也就是写入redo log处于prepare阶段以后、写binlog之前，发生了崩溃（crash）：由于此时binlog还没写，redo log也还没提交（commit），所以崩溃恢复的时候，这个事务会回滚。这时候，binlog还没写，所以也不会传到备库，数据一致；
在上图时刻B中，也就是写完binlog之后，发生crash：如果redo log里面的事务有commit标识（事务是完整的）则直接提交；如果redo log里面的事务只有prepare没有commit，则判断对应的事务在binlog是否存在并完整，完整则提交事务，否则回滚事务；
MySQL怎么知道binlog是完整的：一个事务的binlog是有完整格式的，statement格式（记录sql语句），最后会有个COMMIT; row格式（记录行的内容，记两条，更新前和更新后都有），最后会有个XID event
redo log和binlog是怎么关联起来的：他们有一个共同的数据字段XID。崩溃恢复的时候，会按顺序扫描redo log；上述第二点中的崩溃恢复场景（redo log里面的事务只有完整的prepare而没有commit），那么mysql就会拿着XID去binlog找是否存在对应的完整事务；
为什么不仅使用redo log，不要binlog可以吗？
如果只从崩溃恢复的角度来讲是可以的。可以把binlog关掉，但系统依然是crash-safe的；
但是binlog有着redo log无法替代的功能，binlog的主要作用是归档，redo log是循环写，写到末尾是要回到开头继续写的。
MySQL系统依赖于binlog，mysql系统高可用的基础就是依赖于binlog复制
redo log到底是什么，数据最终落盘，是从redo log更新来的吗？
redo log只是记录了数据页上的改动，并没有记录数据页的完整数据，所以redo log并没有能力更新磁盘数据；
脏页：正常运行的实例中，当数据页被修改之后，和磁盘的数据页不一致，称为脏页；
数据落盘指的就是把内存中的数据页（脏页）写入磁盘。这个过程，甚至与redo log毫无关系；
当然如果在崩溃恢复场景中，（脏页）从内存中丢失了更新，那么innodb就会将这个数据页读到内存中，然后通过redo log更新该数据页的内容（crash-safe）。更新完成后，这个数据页就变成了脏页；
redo log与binlog的区别
redo log是innodb引擎特有的，binlog是MySQL的Server层实现的，所有引擎都可以使用；
redo log是物理日志，记录的是“在某个数据页上做了什么修改”（数据页上某个偏移量的值）
binlog是逻辑日志，记录的是这个语句的原始逻辑（sql、数据行）
redo log是循环写的，空间固定会用完，用完就需要刷盘然后从头开始写；
binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
2.Xtrabackup是实现MYSQL的增量备份和全量备份
Xtrabackup简介
Percona XtraBackup是一个开源、免费的MySQL热备份软件,能够为InnoDB和XtraDB数据库执行非阻塞备份，特点如下：
1、快速、可靠的完成备份
2、备份期间不间断事务处理
3、节省磁盘空间和网络带宽
4、自动对备份文件进行验证
5、恢复快，保障在线运行时间持久性
它能增量备份MySQL数据库，通过流压缩备份MySQL数据到另外一台服务器，在线MySQL服务器之间进行表空间迁移，很easy的创建新的MySQL从服务器，并且备份MySQL数据库时不会带来额外的系统压力。
XtraBackup 有两个工具：xtrabackup 和 innobackupex：
xtrabackup 本身只能备份 InnoDB 和 XtraDB ，不能备份 MyISAM；
innobackupex 本身是 Hot Backup 脚本修改而来，同时可以备份 MyISAM 和 InnoDB，但是备份 MyISAM 需要加读锁。
为什么说Xtrabackup是针对InnoDB引擎的备份工具？
对于MyISAM表只能是温备，而且也不支持增量备份。而XtraBackup更多高级特性通常只能在innodb存储引擎上实现，而且高级特性还都依赖于mysql数据库对innodb引擎实现了单独表空间，否则没办法实现单表或单库导出，因此可以说Xtrabackup是为InnoDB而生也不为过！
**Xtrabackup备份原理 **
1、InnoDB的备份原理
在InnoDB内部会维护一个redo日志文件，我们也可以叫做事务日志文件。事务日志会存储每一个InnoDB表数据的记录修改。当InnoDB启动时，InnoDB会检查数据文件和事务日志，并执行两个步骤：它应用（前滚）已经提交的事务日志到数据文件，并将修改过但没有提交的数据进行回滚操作。
备份过程
Xtrabackup在启动时会记住log sequence number（LSN），并且复制所有的数据文件。复制过程需要一些时间，所以这期间如果数据文件有改动，那么将会使数据库处于一个不同的时间点。这时，xtrabackup会运行一个后台进程，用于监视事务日志，并从事务日志复制最新的修改。Xtrabackup必须持续的做这个操作，是因为事务日志是会轮转重复的写入，并且事务日志可以被重用。所以xtrabackup自启动开始，就不停的将事务日志中每个数据文件的修改都记录下来。
准备过程
上面就是xtrabackup的备份过程。接下来是准备（prepare）过程。在这个过程中，xtrabackup使用之前复制的事务日志，对各个数据文件执行灾难恢复（就像mysql刚启动时要做的一样）。当这个过程结束后，数据库就可以做恢复还原了。
2、MyISAM的备份原理
以上的过程在xtrabackup的编译二进制程序中实现。程序innobackupex可以允许我们备份MyISAM表和frm文件从而增加了便捷和功能。Innobackupex会启动xtrabackup，直到xtrabackup复制数据文件后，然后执行FLUSH TABLES WITH READ LOCK来阻止新的写入进来并把MyISAM表数据刷到硬盘上，之后复制MyISAM数据文件，最后释放锁。
备份MyISAM和InnoDB表最终会处于一致，在准备（prepare）过程结束后，InnoDB表数据已经前滚到整个备份结束的点，而不是回滚到xtrabackup刚开始时的点。这个时间点与执行FLUSH TABLES WITH READ LOCK的时间点相同，所以myisam表数据与InnoDB表数据是同步的。类似oracle的，InnoDB的prepare过程可以称为recover（恢复），myisam的数据复制过程可以称为restore（还原）。
Xtrabackup和innobackupex这两个工具都提供了许多前文没有提到的功能特点。手册上有对各个功能都有详细的介绍。简单介绍下，这些工具提供了如流（streaming）备份，增量（incremental）备份等，通过复制数据文件，复制日志文件和提交日志到数据文件（前滚）实现了各种复合备份方式。
什么是流备份？
流备份是指备份的数据通过标准输出STDOUT传输给tar程序进行归档，而不是单纯的将数据文件保存到指定的备份目录中，参数–stream=tar表示开启流备份功能并打包。同时也可以利用流备份到远程服务器上。
Xtrabackup实现细节
XtraBackup以read-write模式打开innodb的数据文件，然后对其进行复制。其实它不会修改此文件。也就是说，运行 XtraBackup的用户，必须对innodb的数据文件具有读写权限。之所以采用read-write模式是因为XtraBackup采用了其内置的 innodb库来打开文件，而innodb库打开文件的时候就是rw的。
XtraBackup要从文件系统中复制大量的数据，所以它尽可能地使用posix_fadvise()，来告诉OS不要缓存读取到的数据，从 而提升性能。因为这些数据不会重用到了，OS却没有这么聪明。如果要缓存一下的话，几个G的数据，会对OS的虚拟内存造成很大的压力，其它进程，比如 mysqld很有可能被swap出去，这样系统就会受到很大影响了。
在备份innodb page的过程中，XtraBackup每次读写1MB的数据，1MB/16KB=64个page。这个不可配置。读1MB数据之 后，XtraBackup一页一页地遍历这1MB数据，使用innodb的buf_page_is_corrupted()函数检查此页的数据是否正常，如果数据不正常，就重新读取这一页，最多重新读取10次，如果还是失败，备份就失败了，退出。在复制transactions log的时候，每次读写512KB的数据。同样不可以配置。
XtraBackup常用参数：
–user=USER 指定备份用户，不指定的话为当前系统用户
–password=PASSWD 指定备份用户密码
–port=PORT 指定数据库端口
–defaults-group=GROUP-NAME 在多实例的时候使用
–host=HOST 指定备份的主机，可以为远程数据库服务器
–apply-log 回滚日志
–database 指定需要备份的数据库，多个数据库之间以空格分开
–defaults-file 指定mysql的配置文件
–copy-back 将备份数据复制回原始位置
–incremental 增量备份，后面跟要增量备份的路径
–incremental-basedir=DIRECTORY 增量备份时使用指向上一次的增量备份所在的目录
–incremental-dir=DIRECTORY 增量备份还原的时候用来合并增量备份到全量，用来指定全备路径
–redo-only 对增量备份进行合并
–rsync 加快本地文件传输，适用于non-InnoDB数据库引擎。不与–stream共用
–safe-slave-backup
–no-timestamp 生成的备份文件不以时间戳为目录.
完全备份与恢复
完全备份目录：/data/backup/full
完全备份与增量备份每次命令操作成功的标志是，日志结尾处打印【completed OK!】
全量备份
innobackupex --user=root --password=passwd /data/backup/full
上个命令在我的 /data/backup/full/ 目录生成了一个文件夹【2017-01-20_10-52-43】
一般情况下，这个备份不能用于恢复，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务，此时数据文件处于不一致的状态
因此，我们现在就是要通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。
innobackupex --user=root --password --defaults-file=/data/mysql/my.cnf --apply-log /data/backup/full/2017-01-20_10-52-43
恢复操作演练 关掉服务，迁移已有的数据目录
service mysql stop
mv /data/mysql/data /data/mysql/data_old
mkdir -p /data/mysql/data
执行innobackupex恢复命令
innobackupex --defaults-file=/data/mysql/my.cnf --user=root --password=passwd --copy-back /data/backup/full/2017-01-20_10-52-43
对新目录执行赋权操作，此操作需在innobackupex恢复命令后
chown -R mysql.mysql /data/mysql/data
重启服务，并检查数据是否恢复
service mysqld start
备份方案的选择 常见的备份有全量备份、增量备份和差异备份。
首先需要弄明白增量备份和差异备份的区别:
增量备份：自从任意类型的上次备份后有所修改做的备份。
差异备份：自上次全备份后有所改变的部分而做的备份。
全量备份与差异备份结合
以每周数据备份计划为例，我们可以在周一进行完全备份，在周二至周日进行差异备份。如果在周日数据被破坏了，则你只需要还原周一的全量备份和周六的差异备份。这种策略备份数据需要时间较多，但还原数据使用时间较少。
全量备份与增量备份结合
以每周数据备份计划为例，我们可以在周一进行完全备份，在周二至周日进行增量备份。如果在周日数据被破坏了，则你需要还原周一的全量备份和从周二至周六的所有增量备份。这种策略备份数据需要时间较少，但还原数据使用时间较多。且周二至周六任何一个增量数据损坏，所有备份不可用。
全量备份、增量备份和差异备份结合
以每周数据备份计划为例，我们可以在周一进行完全备份，在周二至周日进行差异备份，并且每天针对当天的差异备份每隔一段时间（比如半小时）进行增量备份。如果在周日某个时间点数据被破坏了，则你需要还原周一的全量备份和周六的差异备份，然后再还原周日所做的所有增量备份。这种策略操作最复杂，但是数据库最多损失半个小时的数据。
iptables防止nmap扫描
Nmap在实际中应用场合如下：
通过对设备或者防火墙的探测来审计它的安全性
探测目标主机所开放的端口
通过识别新的服务器审计网络的安全性
探测网络上的主机
在Iptables上配置这些命令可以有效阻止nmap扫瞄
[root@bogon goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j REJECT
[root@bogon goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j REJECT
[root@bogon goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j REJECT
[root@bogon goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags ALL SYN -j REJECT
[root@bogon goaccess-1.5.4]# iptables -t filter -R INPUT 1 -s 192.168.80.138 -p tcp --dport 1: --tcp-flags ALL ACK -j REJECT
