MySQL --> MariaDB --> Percona-Server

MySQL: oracle ,
commutity : 社区版 5.5 5.6 5.7 8.0
MariaDB:
5.5 10.x
Percona:
Percona-Server
InnoDB --> XtraDB
Xtrabackup
percona-tools:

存储引擎：
引擎：也称为表类型，表级别概念，不建议在同一个库中的表上使用不同的ENGINE；
CREATE TABLE ... ENGINE STORAGE_ENGINE_NAME ...
SHOW TABLE STATUS

 常见的存储引擎： SHOW ENGINES; MyISAM, Aria, InnoDB, MRG_MYISAM, CSV, BLACKHOLE,... InnoDB : InnoBase Percona-XtraDB,Supports transactions , row-level locking, and foreign keys 数据存储于“表空间” 中： （1）所有数据库中的所有类型为InnoDB的表的数据和索引存储于同一个表空间中； 表空间文件：datadir定义的目录中，文件 ibdata1,ibdata2... (2) innodb_file_per_table=ON,意味着每表使用单独的表空间文件; 每表的数据文件（数据和索引，存储于数据库目录）存储于自己专用的表空间文件中，并存储于数据库目录下：tablename.ibd 表结构的定义：在数据库目录，tablename.frm 事务型存储引擎，适合对事物要求较高的场景中；但较适用于处理大量短期事务； 基于MVCC（Mutil Version Concurrency Control）支持高并发；支持四个隔离级别，默认级别为 REPETABLE-READ(可重读-幻读); 间隙锁以防止幻读：（MVCC多版本控制就是解决了幻读问题） 使用聚集索引（主键索引）；支持“自适应Hash索引”； 锁粒度： 行级锁，间隙锁 总结： 数据存储：表空间； 并发：MVCC，间隙锁，行级锁 索引：聚集索引、辅助索引； 性能：预读操作、内存数据缓冲、内存索引缓存、自适应Hash索引、插入操作缓存区； 备份：支持热备； SHOW ENGINE INNODB STATUS；

MyISAM：-> Aria

 支持全文索引（FULLTEXT index）、压缩、空间函数（GIS）； 不支持事务 锁粒度：表级锁 崩溃后无法保证表安全恢复 适用场景：只读或读多写少的场景、较小的表（以保证崩溃后恢复的时间较短）； 文件：每个表有三个文件，存储于数据库目录中 tbl_name.frm：表格式定义； tbl_name.MYD：数据文件； tbl_name.MYI：索引文件； 特性： 加锁和并发：表级锁； 修复：手动或自动修复、但可能会丢失数据； 索引：非聚集索引； 延迟索引更新； 表压缩；显示锁的使用： 1）LOCK TABLES LOCK TABLES tb1_name read|write... UNLOCK TABLES; 2）FLUSH TABLES; FLUSH TABLES tb1_name,.... [WITH READ LOCK]; UNLOCK TABLES; 3) SELECT cluase [FOR UPDATE | LOCK IN SHARE MODE]事务： 事务：一组原子性的SQL查询、或者是一个或多个SQL语句组成的独立工作 单元： 事务日志： innodb_log_files_in_group innodb_log_group_home_dir innodb_log_file_size innodb_mirrored_log_groups ACID测试： A：AUTOMICITY，原子性，整个事务中的所有操作要么全部成功执行，要么失败后回滚； C：CONSISTENCY，一致性，数据库总是应该从一个一致性状态转为另一个一致性状态； I：ISOLATION ,隔离性， 一个事务所做出的操作在提交之前，是否能为其他事务可见；处于保证并发操作之目的，隔离有多种级别； D：DURABILITY, 持久性； 事务一旦提交，其所做出的修改会永久保存；自动提交；单语句事务 mysql > SELECT @@autocommit; mysql > SET @@session.autocommit=0; 关闭当前会话自动提交手动控制事务： 启动：START TRANSACTION 提交：COMMIT 回滚：ROLLBACK 事务支持savepoints: SAVEPOINT identifier ROLLBACK [WORK] TO [SAVEPOINT] identifier RELEASE SAVEPOINT identifier事务隔离级别：完全理解 READ-UNCOMMITIED :读未提交 --> 脏读问题 READ-COMMITIED: 读提交 -->不可重复读； REPEATABLE-READ : 可重复度 --> 幻读问题； 默认级别 SERIALIZABLE :串行化； mysql > SELECT @@session.tx_isolation; mysql > SHOW ENGINE innodb STATUS; MySQL用户和权限管理 用户账号： user@host user : 账户名称； host : 此账户可通过哪些客户端主机请求创建连接线程； % ： 任意长度的任意字符； _ : 任意单个字符； skip_name_resolve=ON 重命名：RENAME USER RENAME USER old_user TO new_user [,old_user TO new_user] ... 删除用户： DROP USER ‘username‘@‘host‘ [,‘username1‘@‘host‘]... FLUSH PRIVILEGES; 修改用户密码： 1）SET PASSWORD [FOR ‘username‘@‘host‘] =PASSWORD(‘string‘); 2) UPDATE mysql.user SET password=PASSWORD(‘string‘) WHERE user=‘username‘ AND host=‘HOST‘; 3) mysqladmin -uUSERNAME -hHOST -p password ‘NEW_PASS‘ 4) FLUSH PRIVILEGES;

忘记管理员密码的解决办法：
1） 启动mysqld进程时，使用 --skip-grant-tables和--skip-networking选项
Centos 7 : mariadb.service
Centos 6 : /etc/init.d/mysqld
2) 通过UPDATE命令修改管理员密码；
3) 以正常方式启动mysqld进程；

查看授权： SHOW GRANTS; SHOW GRANTS [FOR ‘username‘@‘host‘ ];取消授权： REVOKE REVOKE priv_type on priv_level FROM ‘user‘@‘host‘ ... REVOKE ALL PRIVILEGES ,GRNAT OPTION FROM user..

查询缓存相关的服务器变量：
query_cache_limit : 能够缓存的最大查询结果；（单语句结果集大小上限）
有着较大结果集的语句：显示使用SQL_NO_CACHE，以避免先缓存再移出；
query_cache_min_res_unit :内存缓存块的最小分配单位；缓存过小的查询结果集会浪费内存空间；
较小的值会减少空间浪费，但是会导致更频繁的内存分配以及回收操作； 较大值的会带来空间浪费；
query_cache_size : 查询缓存空间的总共可用的大小；单位是字节, 必须是1024的整数倍；
query_cache_type: 缓存功能启用与否；
ON:启用； OFF ：禁用
DEMAND: 按需缓存，仅缓存SELECT语句中带SQL_CACHE的查询结果；
query_cache_wlock_invalidate : 如果某表被其他连接锁定，是否仍然可以从查询缓存中返回查询结果；默认为 OFF，表示可以；ON则表示不可以；

状态变量：

 mysql>SHOW GLOBAL STATUS LIKE ‘Qcache%‘; 命中率： Qcache_hits/Com_select

MySQL日志：

 1）二进制日志 用于记录引起数据改变或存在引起数据改变的潜在可能性的语句或改变后的结果，也可能是二者混合； 功用：重放 binlog_format=(STATEMENT|ROW|MIXED) STATEMENT: 语句； ROW : 行； MIXED: 混编； 查看二进制日志文件列表： SHOW MASTER|BINARY LOGS; 查看当前正在使用的二进制日志文件： SHOW MASTER STATUS; 查看二进制日志文件中的事件： SHOW BINLOG EVENTS [IN ‘log_name’] [FROM pos][LIMIT [offset,] row_count] 服务器变量： log_bin=/PATH/TO/BIN_LOG_FILE |OFF session.sql_log_bin={ON | OFF} 控制某会话中的“写‘’操作语句是否会被记录到二进制日志文件中； max_binlog_size= sync_binlog={1|0} ：默认是0，此时mysql性能最好，但是也是最危险的，一旦发生崩溃，存在内存缓存中的语句信息将丢失，1是最安全的也是最慢的，几乎将二进制内存缓存信息与磁盘实时同步刷新； 可以定义N次，每执行多少次事务后刷新缓存到磁盘中mysqlbinlog: 客户端程序 YYYY-MM-DD hh:mm:ss --start-datetime= --stop-datetime= -j, --start-position= --stop-position= --user, --host, --password

中继日志：从服务器上记录下来从主服务器的二进制日志文件同步过来的事件；

事务日志：事务型存储引擎innodb用于保证事务特性的日志文件
redo log
undo log

备份策略：
xtrabackup:
全量+差异+binlog
全量+增量+binlog
mysqldump:
全量+binlog

基于lvm2的备份：
前提：要求数据文件和事务日志位于同一个逻辑卷：
1）请求锁定所有表：
mysql > FLUSH TABLES WITH READ LOCK;
2) 记录二进制文件事件位置：
mysql > FLUSH LOGS;
mysql > SHOW MASTER STATUS;
mysql -e ‘SHOW MASTER STATUS;‘ >> /PATH/TO/SOME_POS_FILE

 3)创建快照卷 lvcreate -s -L 100M -p r -n SNAP-NAME /dev/VG-name/lv-name 4) 释放锁 mysql > UNLOCK TABLES; 5) 挂载快照卷，并执行备份，备份完成后删除快照卷； 6) 周期性备份二进制日志；

Xtrabackup:

 备份 --> 应用日志 --> 还原 应用日志： --apply-log 还原： --copy-back 完全备份： 完全+binlog(总结): 备份： 完全+增量+binlog... 准备： innobackupex --apply-log --redo-only BASEDIR innobackupex --apply-log --redo-only BASEDIR --incremental-dir=INCREMENTTAL-DIR 恢复： innobackupex --copy-back BASEDIR 备份单库： --databases; 总结： mysqldump+binlog lvm2+cp/tar+binlog xtrabackup(innodb)+binlog

实验【mysql主从复制架构与进阶】：

MySQL双主(master-master)+半同步(Semisync Replication)

一、环境
主机名 主机IP

mysqlA 172.18.252.221

mysqB 172.18.252.222

操作系统： CentOS 6.5 2.6.32-431.el6.x86_64

MySQL版本 mysql-community-server-5.7.5-0.6.m15.el6.x86_64

二、架构

1.mysqlA和mysqlB互为主备，即双主架构Master-Master