Mysql architecture
- MySQL belonging to Client / Server structure, Server-side program to mysqld, after the service starts, Client-side program from the local or remote connection Server
- Common Client program, such as: mysql, mysqldump, mysqlshow, mysqlbinlog, also include various types of programming languages to connect to MySQLD by MySQL API and connectors
- mysqld program for the server process can be divided into the following three layers
- Connection layer: connection processing
- Layer SQL: SQL Query application process connected transmitted
- Memory layer: data storage processing, MySQL data may be stored in different formats and structures on different physical media, also referred to as a storage engine
- mysql connection layer
- Accept the connection request from the client through a variety of communication
- Including the following agreement
| fashion | type of connection | Supported Operating Systems |
| -------------- | ---------- | --------- ----- |
| TCP / IP | local, remote | all |
| UNIX socket file | only local | UNIX |
| shared memory | local-only | Windows |
| named pipes | only local | Windows |
- sql layer
- After the connection is established, MySQL server will handle the following tasks:
- Authorization and parser: parser validate the syntax is correct, then verify that authorized users are allowed to connect to run a specific query (whether permission has been verified by the user has access to the database object)
- Optimizer: Creates each query execution plan, which is about how the most optimal way to execute the query step by step instruction set; determine which index to use and in what order processing used in the table is the most important part of this step
- Query: complete execution plan for each query
- Query cache :( optional) configurable query cache that can be used to store (and return immediately) execute the query result set
- Query logging: You can enable execution of the query to track
- After the connection is established, MySQL server will handle the following tasks:
- Storage layer
- MySQLD可以支持不同类型的“存储引擎”来存储数据
- InnoDB 是默认存储引擎,支持事务、全文索引和外键约束,因此适用于各种混合查询
- 其他存储引擎包括:
- MyISAM:适用于频繁读取但很少更新的数据
- MEMORY:在内存中存储所有数据
- NDB (MySQL Cluster版支持):供 MySQL Cluster 用来为高可用性数据提供冗余的可伸缩拓扑
- ARCHIVE:适用于不更新偶尔查询的历史数据,提供压缩功能节约磁盘存储空间
- 常用存储引擎特点:
- INNODB引擎:
- 默认存储引擎
- 支持事务
- 支持行级锁
- 支持外键
- 适用于具有数据一致性要求和并发读写要求的通用性业务
- MyISAM引擎:
- MySQL早期版本默认存储引擎
- 读取(select)速度快
- 不支持事务和外键
- 适用于修改较少读取频繁且对数据一致性要求不高的业务
- Archive引擎:
- 数据压缩比非常高可以节约大量磁盘空间
- 不支持索引、事务和外键
- 支持insert、select不支持update和delete
适用于数据量大偶尔需要查询的历史归档业务数据
MySQL配置选项
- INNODB引擎:
MySQL提供几百个选项(参数)对数据库各个功能进行配置,并给定默认值,使数据库运行
查看所有选项
或
shell show variables; #数据库命令行查看 mysqld --verbose --help #系统命令查看
查看指定的选项
或
更改选项的值
或通过修改配置文件进行永久修改
- 选项优先级
- 命令行选项
- 配置文件
- 默认值
查看用户设置的选项
Mysql日志配置
- 常见日志分类
- 错误日志 (error log)
- 记录mysqld启动、运行和停止过程中遇到的问题
- 常规日志 (general query log)
- 记录客户端连接以及服务器从客户端收到的各类SQL语句
- 慢查询日志 (slow query log)
- 记录运行时间超过选项long_query_time设定阈值的查询语句
- 二进制日志 (binary log)
- 记录使数据库数据产生变化的各类语句
- 错误日志 (error log)
- 日志文件的特点
- 有可能会占用大量磁盘空间
- 通常存储在文件中
- 可以选择存储在mysql的表中,便于查询和分析
- 仅限于常规查询和慢查询日志
- 除了二进制日志,通常以文本格式记录数据
- mysql的错误日志
- 默认开启
- 查看错误日志存放位置
- 修改配置
- mysql常规日志
- 默认关闭
- 查看常规日志状态及存放位置
- 启用常规日志
或
- 测试
- mysql慢查询日志
- 默认关闭
- 查看慢查询日志状态及存放位置
- 查看慢查询时长
注:默认为10,(单位:秒),超过该时长的查询会被慢查询日志记录 - 启用慢查询日志
或
测试
select benchmark(1000000000,10*10); #benchmark(1000000000,10*10) 将10*10执行1000000000次
- mysql二进制日志Binlog
- 默认关闭
- 开启binlog后,所有导致数据库数据产生变化的操作会按照时间顺序以“事件”的形式记录到binlog二进制文件中
- 主要用途
- 数据库复制
- 数据恢复
- 查看binlog状态
开启binlog并指定存放路径
log_bin=/var/lib/mysql/mysql-bin #开启binlog并指定存放路径 server-id=1 #为binlog设置服务id号 #可以使用expire_logs_days参数指定定期清理的时间间隔(单位:天)
- 日志文件滚动(切换)
- MySQL启动或重启
- 日志量到达了max_binlog_size的设定值
- 执行flush logs;命令手动切换日志
- 测试
- binlog记录内容
binlog以紧凑的二进制方式存储
日志中包含数据和表结构更改事件及其时间戳
无法使用普通的文本查看软件查看其内容,mysql提供了mysqlbinlog工具将二进制数据转换为sql文件
查看
将binlog转换为sql文件
注:在binlog中保存每条记录的头注释
常用相关命令
root@localhost[(none)]>show binary logs; #查看所有日志文件 root@localhost[(none)]>show master status; #查看当前记录日志文件详情 root@localhost[(none)]>root@localhost[(none)]>show binlog events; #查看第一个binlog日志文件中的事件 root@localhost[(none)]>show binlog events in 'mysql-bin.000002'; #查看指定binlog中的事件 show binlog events in 'mysql-bin.000002' from 123; #查看指定binlog中指定起始头注释的事件 [root@tomcat mysql]# mysqlbinlog --start-position=4 --stop-position=123 /var/lib/mysql/mysql-bin.000002 #查看指定的起始头注释
数据库的备份与恢复
常见术语:
物理备份
- 生成数据库文件的完整副本(二进制),可以使用标准命令,如 cp、tar、xcopy、windows图形复制粘贴
- 要注意保持数据的一致性,对于默认引擎为innodb的数据库需要停止MySQL服务后再进行物理备份(冷备)
逻辑备份
- 将数据库和表转换为一个sql文本文件,里面包括可以重构数据库和表的SQL语句
可以使用该文本文件在运行不同体系结构的其他主机上重新装入数据库
- 要求 MySQL 服务器在备份期间运行 (不能冷备)
基于数据库复制的备份
- 创建一个主库的复制库从库,主库作为生产库,从库作为备份库
- 主库定期向从库传递binlog文件,并在从库应用保证从库和主库的一致性
- 从库也可以做物理备份或逻辑备份
完全备份
- 备份所有数据库文件:/var/lib/mysql/*
- 备份所有binlog文件: /var/lib/mysql/mysql-bin.*
- 备份选项文件: /etc/my.cnf
不完全备份
- 仅仅备份部分数据库的文件
- 热备
- 数据库不关闭,在仍然有用户读取或修改数据的过程中进行备份,热备不阻止用户正常的数据库操作,有些热备工具甚至能捕获备份进行期间发生的更改
- 并非所有引擎都支持热备,innodb引擎可以支持热备,但MyISAM引擎不能热备- 温备
- 数据库不关闭,处于只读模式,备份可以在用户读取数据时进行
- 温备优点是不必完全锁定数据库访问用户,其不足之处在于用户无法在进行备份时修改数据库的数据
冷备
- 关闭数据库,备份在用户不能访问数据时进行,因此用户无法读取或修改数据
- 冷备会阻止执行任何使用数据的活动,如果备份时间较长,会造成用户较长的时间里无法访问数据
- 关闭数据库,备份在用户不能访问数据时进行,因此用户无法读取或修改数据
物理备份
冷备
关闭数据库服务
使用cp命令备份整个数据库到指定目录下
温备
为数据库加表只读锁
复制数据库内容至备份目录(同上)
复制完成解锁
还原
清理已损坏的数据库文件
还原
使用mysqldump进行逻辑备份
属于mysql提供的逻辑备份工具
将数据库的内容转储到文本文件
可以指定所有数据库、特定数据库或特定表
可以备份本地或远程数据库
和存储引擎无关
适合数据量较小的数据库数据导出
不能关闭数据库,因此备份策略和时机可以灵活
语法:mysqldump -uUSERNAME -p --opt DB > FILENAME.sql
- --master-data=2 #备份过程锁住所有表,禁止执行select之外的所有语句
- --single-transaction #开启事务备份,确保数据库的一致性(热备)
- --lock-all-tables #对表加锁确保一致性(温备)
- --flush-logs #先对binlog进行切换再进行备份
- --add-drop-database #还原时先删除已有的数据库再创建新库
- --add-drop-table #还原时先删除已有的表在创建新表
- --routines #连通存储过程和函数一起备份
- --triggers #连通触发器一起备份
- --add-locks #还原时为insert语句添加独占锁
- --create-options #备份文件中添加create语句
- --quick #不把备份过程中的SQL语句放到查询缓冲区中,输出到标准输出
- --extended-insert #使用多行插入语法,例如:insert into t values(1),(2),(3)...
- --lock-tables #给备份过程中遇到的每个表加只读锁,备份时其他修改表的用户要等待该表备份完成
- --set-charset #添加set names default_character_set到输出文件
- --disable-keys #添加disable keys和enable keys到备份输出文件,还原插入记录时,插入完成后再建立索引提高还原效率
- --opt #相当于--add-drop-table 、--add-locks、--create-options 、--quick、 --extended-insert、--lock-tables 、--set-charset 、--disable-keys的组合
常用备份选项
mysqldump -uroot -p --all-databases --single-transaction --master-data=2 --routines --triggers --events --flush-logs > /backup/all-db.sql #备份所有数据库
mysqldump -uroot -p --databases demo test1 >/backup/dbs.sql #备份一个或多个数据库
mysqldump -uroot -p demo stu class bmi >/backup/db_demo_tables.sql #备份一个数据库中的一个或多个表
还原
[root@tomcat ~]# mysql -uroot -p demo < /backup/db_demo_tables.sql #恢复demo数据库 root@localhost[demo]>source /backup/db_demo_tables.sql; #数据库中使用source命令恢复数据
数据库恢复分类
- 完全恢复:从还原时的状态恢复到最后一个日志的最后一条语句
- 不完全恢复:从还原时的状态恢复到指定日志的某个位置
实验1--冷备不完全恢复
冷备数据库所有数据
重启虚拟机mysql服务然后连接
查看备份启动后binlog的编号
生成测试数据并切换binlog日志
插入新的数据,并删除数据库模拟误操作
View binlog find accidentally deleted the operating head Comment No.
Using binlog log generation to recover data sql statement
Restore data through another mysql server
sql statement to generate a full backup of data and upload to another server mysql (windows used here for recovery operations)
Close mysql service and introduced into the cold standby data directory
Note: Delete old files original data directory
Start mysql service and execute the sql file recovery data (using the backup database account password when logging)
cmd command is used to export to sql database accidentally deleted files (do not use powershell)
The resulting test1.sql deleted files uploaded to the library mysql database
Execute sql file recovery data