MySQL运维

日志

错误日志

存放目录 /var/log/mysqld.log

show variables like '%log_error%'

二进制日志

二进制日志（BINLOG）记录了所有的DDL语句和DML语句，但是不包括select、show语句

即这里记录了数据的变化。

主要作用：

• 灾难时数据恢复

• MySQL的主从复制

在MySQL中默认开启。

日志格式有三种

• statement

  • 基于SQL语句的日志记录，记录的是SQL语句。

• row

  • 基于行的日志记录，记录的是每一行的数据变更（默认）

• mixed

  • 混合上面两种，默认使用statement，在某些特殊情况下自动切换为ROW进行记录。

查询日志

查询日志中记录了客户端的所有操作语句，而二进制日志中不包含查询数据的SQL语句。默认是关闭的。

慢查询日志

（就是mysql性能分析里面的）

主从复制

主从复制是指讲主数据库的DDL和DML操作通过二进制日志传到从库服务器中，然后在从库上对这些日志重新执行（也叫重做），从而使得从库和主库的数据保持同步。

MySQL支持一台主库同时向多台从库进行辅助，从库同时也可以作为其他从服务器的主库，实现链状复制。

优势：

• 主库出现问题，可以快速切换到从库提供服务。

• 实现读写分离，降低主库的访问压力

• 可以在从库中执行备份，以避免备份期间影响主库服务。

原理

主库数据变更会写入到binlog中，从库会发送请求到主库，请求binlog，从库拿到后存储在本地的relay log中继日志中，然后本地读取中继日志，重做其中的数据变更。

读写分离

简单来说，就是把对数据的读和写分开。主数据库提供写操作，从数据库提供读操作，这样能够有效地减轻单台数据库的压力。

一主一从

配置好主从数据库，然后使用中间件处理对数据的操作，写操作分流到主主数据库，读操作分流到从数据库

缺点：

主节点宕机后，业务系统只能读不能写。即数据的高可用

双主双从

两个主数据库相互复制。这样就会有一个优先级，主写数据库和副写数据库。

分库分表

性能瓶颈：

• io，大量访问，会占用大量内存，内存不够时，会产生大量的磁盘IO

• cpu，各种查询会耗费CPU资源，请求太多，cpu出现瓶颈

中心思想：数据分散存储，使得单一数据库的数据量变小，从而缓解单库压力。

拆分策略

• 垂直拆分，

  • 垂直分表。以字段为依据，根据字段属性将不同的字段拆分到不同表中，不同的表可以存储在不同的数据库中。

  • 垂直分库，以表为依据，根据业务将不同表拆分到不同的库中。

• 水平拆分

  • 水平分库。将同一个数据库分为多个数据库存储，即每一个数据库仅存储全部数据的一部分，大家组合在一起才算全部的数据

  • 水平分表。将一个表分为多个数据库存储，即一个数据库服务器中存储一部分数据，大家合在一起才能得到而这个表的全部数据

注：水平拆分其实拆的是数据，垂直拆分拆的是结构

具体实现呢 采用一些中间件或者在原应用程序开发，自定义配置对本地sql进行拦截、解析、改写、路由等策略。

水平拆分规则和方法

范围拆分，根据指定字段及其配置的范围与数据节点的对应情况，来决定该数据属于哪一个分片。

取模分片，根据指定字段值与节点数量进行求模运算，按照运算结果，来决定该数据属于哪一个分片。

一致性hash：计算指定字段的hash值来确定数据数据哪一个分片。所谓一致性hash，相同的hash因子，计算值总是被划分到相同的分区表中。

枚举分片：通过在配置文件中配置可能的枚举值，指定数据分布到不同数据节点上，本规则适用于按照省份、性别、状态拆分。

应用指定：在运行阶段由应用自主决定路由到哪个分片，根据字符字串计算所在分区表。即比如0100000，0200000，030000，040000,类似情况。根据前两位数据来决定分区到哪个

固定分片Hash算法：取某个字段值（数）的二进制的一部分，比如低10位，然后与1111111111进行&运算，根据这个结果，来决定应该分区到哪个地方

字符串Hash解析：截取指定位置的子字符串，进行hash算法，算出应该分区到哪个地方。

按天分：可以指定某个时间周期（如10天），每一个周期内的数据放到同一个地方。并循环放置。

按自然月：按月为周期，一个月的数据存储在一个分区中。