生产环境的数据库，哪些操作保证安全
业务性能
1、应用上线前审查业务新增的sql，分析sql执行计划。比如是否存在 select * ，索引建立是否合理等。
2、开启慢查询日志，定期分析慢查询日志。
3、监控CPU/内存利用率，读写、网关IO、流量带宽随着时间的变化统计图。
4、吞吐量QPS/TPS，一天内读写随着时间的变化统计图。
数据安全
1、短期增量备份，比如一周一次。 定期全量备份，比如一月一次。
2、检查是否有非授权用户，是否存在弱口令，网络防火墙检查。
3、导出数据是否进行脱敏处理，防止数据泄露或者黑产利用。
4、数据库全量操作日志审计，防止数据泄露。
5、数据库账号密码业务独立，权限独立控制，防止多库共用同个账号密码。
6、考虑主从架构，多机房部署。
MySQL常见日志
redo 重做日志
作用：确保事务的持久性，防止在发生故障，脏页未写入磁盘。重启数据库会进行redo log执行重做，到达事务一致性。
undo 回滚日志
作用：保证数据的原子性，记录事务发生之前的数据的一个版本，用于回滚。
innodb事务的可重复读和读取已提交 隔离级别就是通过mvcc+undo实现
errorlog 错误日志
作用：Mysql本身启动、停止、运行期间发生的错误信息。
slow query log 慢查询日志
作用：记录执行时间过长的sql，时间阈值可以配置，只记录执行成功。
binlog 二进制日志
作用：用于主从复制，实现主从同步。
relay log 中继日志
作用：用于数据库主从同步，将主库发送来的binlog先保存在本地，然后从库进行回放。
general log 普通日志
作用：记录数据库操作明细，默认关闭，开启会降低数据库性能。
数据库主从原理流程
搭建数据库主从复制的目的
1、容灾使用，用于故障切换；
2、业务需要，进行读写分离减少主库压力
主从数据库同步延迟问题
保证性能第一情况下，不能百分百解决主从同步延迟问题，只能增加缓解措施。
现象：主从同步，大数据量场景下，会发现写入主库的数据，在从库没找到。
原因：
1、主从复制是单线程操作，当主库TPS高，产生的超过从库sql线程执行能力；
2、从库执行了大的sql操作，阻塞等待；
3、服务器硬件问题，如磁盘，CPU，还有网络延迟等。
解决办法：
1、业务需要有一定的容忍度，程序和数据库直接增加缓存，降低读压力；
2、业务适合的话，写入主库后，再写缓存，读的时候可以读缓存，没命中再读从库；
3、读写分离，一主多从，分散主库和从库压力；
4、提高硬件配置，比如使用SSD固态硬盘、更好的CPU和网络；
5、进行分库分表，减少单机压力。
数据库主从复制数据一致性校验方案
主从数据不一致情况
1、本身复制延迟导致
2、主库宕机或者从库宕机都会导致复制中断
3、把一个从库提升为主库，可能导致从库和主库的数据不一致性
主从数据不一致修复
Mysql主从复制是基于binlog复制，难免出现复制数据不一致的风险，引起用户数据访问前后不一致的风险，所以要定期开展主从复制数据一致性的校验并修复，避免这些问题。
解决方案之一，使用Percona公司下的工具pt-table-checksum工具进行一致性校验
原理：主库利用表中的索引，将表的数据切割成一个个chunk(块)，然后进行计算得到checksum值。从库也执相应的操作，并在从库上计算相同数据块的checksum，然后对比主从中各个表的checksum是否一致并存储到数据库，最后通过存储校验结果的表就可以判断出哪些表的数据不一致。
pt-table-sync(在从库执行)工具进行修复不一致数据，可以修复主从结构数据的不一致，也可以修复非主从结构数据表的数据不一致。
原理：在主库上执行数据的更改，再同步到从库上，不会直接更改成从的数据。在主库上执行更改是基于主库现在的数据，也不会更改主库上的数据，可以同步某些表或整个库的数据，但它不同步表结构、索引，只同步不一致的数据。
注意：
1.默认主库要检查的表在从库都存在，并且同主库表有相同的表结构；
2.如果表中没有索引，pt-table-checksum将没法处理，一般要求最基本都要有主键索引；
3.pt-table-sync工具会修改数据，使用前最好备份下数据，防止误操作；
pt-table-checksum怎么保证某个chunk的时候checksum数据一致性？
当pt工具在计算主库上某chunk的checksum时，主库可能在更新且从库可能复制延迟，那该怎么保证主库与从库计算的是”同一份”数据，答案就是把要checksum的行加上for update锁并计算，这保证了主库的某个chunk内部数据的一致性。