标签：插件 exp 说明 ora 时间 support loaded 大于 nal
1、搭建mysql服务器，并实现主主复制、半同步复制
存储引擎：
表类型：也称为“表类型”，表级别概念，不建议在同一个库中的表上使用不同的ENGINE；
CREATE TABLE ... ENGINE[=]STORAGE_ENGINE_NAME ...
SHOW TABLE STATUS
常见的存储引擎：
MyISAM, Aria, InnoDB, MRG_MYISAM, CSV, BLACKHOLE, MEMORY, PERFORMANCE_SCHEMA, ARCHIVE, FEDERATED
InnoDB：InnoBase
Percona-XtraDB, Supports transactions, row-level locking, and foreign keys
数据存储于“表空间(table space)"中：
(1) 所有数据库中的所有类型为InnoDB的表的数据和索引存储于同一个表空间中；
表空间文件：datadir定义的目录中
文件：ibdata1, ibdata2, ...
(2) innodb_file_per_table=ON，意味着每表使用单独的表空间文件；
每表的数据文件（数据和索引，存储于数据库目录）存储于自己专用的表空间文件中，并存储于数据库目录下: tbl_name.ibd
表结构的定义：在数据库目录，tbl_name.frm
事务型存储引擎，适合对事务要求较高的场景中；但较适用于处理大量短期事务；
基于MVCC（Mutli Version Concurrency Control）支持高并发；支持四个隔离级别，默认级别为REPEATABLE-READ；间隙锁以防止幻读；
使用聚集索引（主键索引）；
支持”自适应Hash索引“；
锁粒度：行级锁；间隙锁；
总结：
数据存储：表空间；
并发：MVCC，间隙锁，行级锁；
索引：聚集索引、辅助索引；
性能：预读操作、内存数据缓冲、内存索引缓存、自适应Hash索引、插入操作缓存区；
备份：支持热备；
MyISAM：
支持全文索引（FULLTEXT index）、压缩、空间函数（GIS）；
不支持事务
锁粒度：表级锁
崩溃无法保证表安全恢复
适用场景：只读或读多写少的场景、较小的表（以保证崩溃后恢复的时间较短）；
文件：每个表有三个文件，存储于数据库目录中
tbl_name.frm：表格式定义；
tbl_name.MYD：数据文件；
tbl_name.MYI：索引文件；
特性：
加锁和并发：表级锁；
修复：手动或自动修复、但可能会丢失数据；
索引：非聚集索引；
延迟索引更新；
表压缩；
行格式：
{DEFAULT|DYNAMIC|FIXED|COMPRESSED|REDUNDANT|COMPACT}
其它的存储引擎：
CSV：将CSV文件（以逗号分隔字段的文本文件）作为MySQL表文件；
MRG_MYISAM：将多个MyISAM表合并成的虚拟表；
BLACKHOLE：类似于/dev/null，不真正存储数据；
MEMORY：内存存储引擎，支持hash索引，表级锁，常用于临时表；
FEDERATED: 用于访问其它远程MySQL服务器上表的存储引擎接口；
MariaDB额外支持很多种存储引擎：
OQGraph、SphinxSE、TokuDB、Cassandra、CONNECT、SQUENCE、...
搜索引擎：
lucene, sphinx
lucene：Solr, ElasticSearch
并发控制：
锁：Lock
锁类型 ：
读锁：共享锁，可被多个读操作共享；
写锁：排它锁，独占锁；
锁粒度：
表锁：在表级别施加锁，并发性较低；
行锁：在行级别施加锁，并发性较高；维持锁状态的成本较大；
锁策略：在锁粒度及数据安全性之间寻求一种平衡机制；
存储引擎：级别以及何时施加或释放锁由存储引擎自行决定；
MySQL Server：表级别，可自行决定，也允许显式请求；
锁类别：
显式锁：用户手动请求的锁；
隐式锁：存储引擎自行根据需要施加的锁；
显式锁的使用：
(1) LOCK TABLES
LOCK TABLES tbl_name read|write, tbl_name read|write, ...
UNLOCK TABLES
(2) FLUSH TABLES
FLUSH TABLES tbl_name,... [WITH READ LOCK];
UNLOCK TABLES;
(3) SELECT cluase
[FOR UPDATE | LOCK IN SHARE MODE]
show processlist; #查看线程列表
手动控制事务：
启动：START TRANSACTION
提交：COMMIT
回滚：ROLLBACK
事务支持savepoints：
SAVEPOINT identifier
ROLLBACK [WORK] TO [SAVEPOINT] identifier
RELEASE SAVEPOINT identifier
事务隔离级别：
READ-UNCOMMITTED：读未提交 --> 脏读；
READ-COMMITTED：读提交--> 不可重复读；
REPEATABLE-READ：可重复读 --> 幻读；
SERIALIZABLE：串行化；
mysql> SELECT @@session.tx_isolation;
+----------------------------------+
| @@session.tx_isolation |
+----------------------------------+
| REPEATABLE-READ |
+----------------------------------+
查看InnoDB存储引擎的状态信息：
SHOW ENGINE innodb STATUS;
日志：
查询日志：general_log
慢查询日志：log_slow_queries
错误日志：log_error， log_warnings
二进制日志：binlog
中继日志：relay_log
事务日志：innodb_log
1、查询日志
记录查询语句，日志存储位置：
文件：file
表：table (mysql.general_log)
general_log={ON|OFF}
general_log_file=HOSTNAME.log
log_output={FILE|TABLE|NONE}
2、慢查询日志
慢查询：运行时间超出指定时长的查询；
long_query_time
存储位置：
文件：FILE
表：TABLE，mysql.slog_log
log_slow_queries={ON|OFF}
slow_query_log={ON|OFF}
slow_query_log_file=
log_output={FILE|TABLE|NONE}
log_slow_filter=admin,filesort,filesort_on_disk,full_join,full_scan,query_cache,query_cache_miss,tmp_table,tmp_table_on_disk
log_slow_rate_limit
log_slow_verbosity
3、错误日志
记录信息：
(1) mysqld启动和关闭过程 输出的信息；
(2) mysqld运行中产生的错误信息；
(3) event scheduler运行时产生的信息；
(4) 主从复制架构中，从服务器复制线程启动时产生的日志；
log_error=
/var/log/mariadb/mariadb.log|OFF
log_warnings={ON|OFF}
4、二进制日志
用于记录引起数据改变或存在引起数据改变的潜在可能性的语句（STATEMENT）或改变后的结果（ROW），也可能是二者混合；
功用：“重放”
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
只读变量；
session.sql_log_bin={ON|OFF}
控制某会话中的“写”操作语句是否会被记录于日志文件中；
max_binlog_size=1073741824
sync_binlog={1|0}
mysqlbinlog：
YYYY-MM-DD hh:mm:ss
--start-datetime=
--stop-datetime=
-j, --start-position=#
--stop-position=#
--user, --host, --password
二进制日志事件格式：
# at 553
#160831 9:56:08 server id 1 end_log_pos 624 Query thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1472608568/*!*/;
BEGIN
/*!*/;
事件的起始位置：# at 553
事件发生的日期时间：#160831 9:56:08
事件发生的服务器id：server id 1
事件的结束位置：end_log_pos 624
事件的类型：Query
事件发生时所在服务器执行此事件的线程的ID： thread_id=2
语句的时间戳与将其写入二进制日志文件中的时间差：exec_time=0
错误代码：error_code=0
事件内容：SET TIMESTAMP=1472608568/*!*/;
中继日志：
从服务器上记录下来从主服务器的二进制日志文件同步过来的事件；
事务日志：
事务型存储引擎innodb用于保证事务特性的日志文件：
redo log
undo log
主/从架构：
异步复制：
半同步复制：
一主多从；
一从一主；
级联复制；
循环复制；
双主复制；
一从多主：
每个主服务器提供不同的数据库；
配置：
时间同步；
复制的开始位置：
从0开始；
从备份中恢复到从节点后启动的复制，复制的起始点备份操作时主节点所处的日志文件及其事件位置；
主从服务器mysqld程序版本不一致？
从的版本号高于主的版本号；
主服务器：
配置文件my.cnf
server_id=#
log_bin=log-bin
启动服务：
mysql> GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO ‘USERNAME‘@‘HOST‘ IDENTIFIED BY ‘YOUR_PASSWORD‘;
mysql> FLUSH PRIVILEGES;
从服务器：
配置文件my.cnf
server_id=#
relay_log=relay-log
read_only=ON
启动服务：
mysql> CHANGE MASTER TO MASTER_HOST=‘HOST‘,MASTER_USER=‘USERNAME‘,MASTER_PASSWORD=‘YOUR_PASSWORD‘,MASTER_LOG_FILE=‘BINLOG‘,MASTER_LOG_POS=#;
mysql> START SLAVE [IO_THREAD|SQL_THREAD];
mysql> SHOW SLAVE STATUS;
课外作业：基于SSL的复制的实现；
主主复制：
互为主从：两个节点各自都要开启binlog和relay log；
1、数据不一致；
2、自动增长id；
定义一个节点使用奇数id
auto_increment_offset=1
auto_increment_increment=2
另一个节点使用偶数id
auto_increment_offset=2
auto_increment_increment=2
配置：
1、server_id必须要使用不同值；
2、均启用binlog和relay log；
3、存在自动增长id的表，为了使得id不相冲突，需要定义其自动增长方式；
服务启动后执行如下两步：
4、都授权有复制权限的用户账号；
5、各把对方指定为主节点；
复制时应该注意的问题：
1、从服务设定为“只读”；
在从服务器启动read_only，但仅对非SUPER权限的用户有效；
阻止所有用户：
mysql> FLUSH TABLES WITH READ LOCK;
2、尽量确保复制时的事务安全
在master节点启用参数：
sync_binlog = ON
如果用到的是InnoDB存储引擎：
innodb_flush_logs_at_trx_commit=ON
innodb_support_xa=ON
3、从服务器意外中止时尽量避免自动启动复制线程
4、从节点：设置参数
sync_master_info=ON
sync_relay_log_info=ON
半同步复制
支持多种插件：/usr/lib64/mysql/plugins/
需要安装方可使用：
mysql> INSTALL PLUGIN plugin_name SONAME ‘shared_library_name‘;
半同步复制：
semisync_master.so
semisync_slave.so
主节点：
INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so‘;
MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE ‘rpl_semi%‘;
+------------------------------------+-------+
| Variable_name | Value |
+------------------------------------+-------+
| rpl_semi_sync_master_enabled | OFF |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_no_slave | ON |
+------------------------------------+-------+
MariaDB [mydb]> SET GLOBAL rpl_semi_sync_master_enabled=ON;
从节点：
INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so‘;
MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE ‘rpl_semi%‘;
+---------------------------------+-------+
| Variable_name | Value |
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled | OFF |
| rpl_semi_sync_slave_trace_level | 32 |
+---------------------------------+-------+
MariaDB [mydb]> STOP SLAVE IO_THREAD;
MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE ‘rpl_semi%‘;
MariaDB [mydb]> START SLAVE IO_THREAD;
判断方法：
主节点：
MariaDB [mydb]> SELECT @@global.rpl_semi_sync_master_clients；
复制过滤器：
仅复制有限一个或几个数据库相关的数据，而非所有；由复制过滤器进行；
有两种实现思路：
(1) 主服务器
主服务器仅向二进制日志中记录有关特定数据库相关的写操作；
问题：其它库的time-point recovery将无从实现；
binlog_do_db=
binlog_ignore_db=
(2) 从服务器
从服务器的SQL THREAD仅重放关注的数据库或表相关的事件，并将其应用于本地；
问题：网络IO和磁盘IO；
Replicate_Do_DB=
Replicate_Ignore_DB=
Replicate_Do_Table=
Replicate_Ignore_Table=
Replicate_Wild_Do_Table=
Replicate_Wild_Ignore_Table=
主从架构
修改配置文件。
加入server-id。开启二进制日志
将二进制日志目录所有者更改为mysql
从节点修改配置文件，启用中继日志，将会把主节点二进制日志复制过来
mkdir /data/mysql
[root@centos7 ~]# chown -R mysql.mysql /data/mysql/
MariaDB [(none)]> grant replication slave,replication client on *.* to ‘repluser‘@‘192.168.1.%‘ identified by ‘123456‘; #主节点创建复制账号赋予复制权限
skip_name_resolve=ON #避免mysql将ip地址解析为主机名，这里可以跳过解析，在配置文件中加入此行
change master to master_host=‘192.168.1.196‘,master_port=3306,master_user=‘repluser‘,master_password=‘123456‘,master_log_file=‘mysql-bin.000001‘,master_log_pos=245;
在从节点配置连接信息。
master_host=‘192.168.1.196‘#主节点主机。master_log_file=‘mysql-bin.000001‘#指定从哪个二进制文件开始复制,master_log_pos=245;#从二进制文件中的哪个位置复制
start slave；备用节点开启复制
查看同步状态
主主复制：
互为主从：两个节点各自都要开启binlog和relay log；
1、数据不一致；
2、自动增长id；
定义一个节点使用奇数id
auto_increment_offset=1
auto_increment_increment=2
另一个节点使用偶数id
auto_increment_offset=2
auto_increment_increment=2
配置：
1、server_id必须要使用不同值；
2、均启用binlog和relay log；
3、存在自动增长id的表，为了使得id不相冲突，需要定义其自动增长方式；
服务启动后执行如下两步：
4、都授权有复制权限的用户账号；
5、各把对方指定为主节点；
复制时应该注意的问题：
1、从服务设定为“只读”；
在从服务器启动read_only，但仅对非SUPER权限的用户有效；
阻止所有用户：
mysql> FLUSH TABLES WITH READ LOCK;
2、尽量确保复制时的事务安全
在master节点启用参数：
sync_binlog = ON
如果用到的是InnoDB存储引擎：
innodb_flush_logs_at_trx_commit=ON
innodb_support_xa=ON
3、从服务器意外中止时尽量避免自动启动复制线程
4、从节点：设置参数
sync_master_info=ON
sync_relay_log_info=ON
修改配置文件，启用二进制日志和中继日志
serverid区别开来
GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO repluser@‘192.168.1.%‘ IDENTIFIED BY ‘123456‘;
在两边节点都需要创建复制账号
在复制时要指定对方当前的二进制日志记录点，
change MASTER TO MASTER_HOST=‘192.168.1.196‘,MASTER_USER=‘repluser‘,MASTER_PASSWORD=‘123456‘,MASTER_LOG_FILE=‘mysql-bin.000001‘,MASTER_LOG_POS=245;
change MASTER TO MASTER_HOST=‘192.168.1.198‘,MASTER_USER=‘repluser‘,MASTER_PASSWORD=‘123456‘,MASTER_LOG_FILE=‘mysql-bin.000003‘,MASTER_LOG_POS=418;
半同步复制
支持多种插件：/usr/lib64/mysql/plugins/
需要安装方可使用：
mysql> INSTALL PLUGIN plugin_name SONAME ‘shared_library_name‘;
半同步复制：
semisync_master.so
semisync_slave.so
主节点：
INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so‘;
MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE ‘rpl_semi%‘;
+------------------------------------+-------+
| Variable_name | Value |
+------------------------------------+-------+
| rpl_semi_sync_master_enabled | OFF |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_no_slave | ON |
+------------------------------------+-------+
MariaDB [mydb]> SET GLOBAL rpl_semi_sync_master_enabled=ON;
从节点：
INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so‘;
MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE ‘rpl_semi%‘;
+---------------------------------+-------+
| Variable_name | Value |
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled | OFF |
| rpl_semi_sync_slave_trace_level | 32 |
+---------------------------------+-------+
MariaDB [mydb]> STOP SLAVE IO_THREAD;
MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE ‘rpl_semi%‘;
MariaDB [mydb]> START SLAVE IO_THREAD;
判断方法：
主节点：
MariaDB [mydb]> SELECT @@global.rpl_semi_sync_master_clients；
复制过滤器：
仅复制有限一个或几个数据库相关的数据，而非所有；由复制过滤器进行；
有两种实现思路：
(1) 主服务器
主服务器仅向二进制日志中记录有关特定数据库相关的写操作；
问题：其它库的time-point recovery将无从实现；
binlog_do_db=
binlog_ignore_db=
(2) 从服务器
从服务器的SQL THREAD仅重放关注的数据库或表相关的事件，并将其应用于本地；
问题：网络IO和磁盘IO；
Replicate_Do_DB= #白名单
Replicate_Ignore_DB=#黑名单
Replicate_Do_Table= #表白名单
Replicate_Ignore_Table=#表黑名单
Replicate_Wild_Do_Table=#表通配符白名单
Replicate_Wild_Ignore_Table=
复制的监控和维护：
(1) 清理日志：PURGE
PURGE { BINARY | MASTER } LOGS { TO ‘log_name‘ | BEFORE datetime_expr };
(2) 复制监控
MASTER:
SHOW MASTER STATUS;
SHOW BINLOG EVENTS;
SHOW BINARY LOGS;
SLAVE:
SHOW SLAVE STATUS;
判断从服务器是否落后于主服务器：
Seconds_Behind_Master: 0
(3) 如何确定主从节点数据是否一致？
通过表的CHECKSUM检查；
使用percona-tools中pt-table-checksum；
(4) 主从数据不一致时的修复方法？
重新复制；
mysql 读写分离器
proxysql
vi /etc/yum.repos.d/proxysql.repo
[proxysql_repo]
name= ProxySQL YUM repository
baseurl=https://repo.proxysql.com/ProxySQL/proxysql-2.0.x/centos/latest
gpgcheck=1
gpgkey=https://repo.proxysql.com/ProxySQL/repo_pub_key
yum install proxysql
ProxySQL：
配置示例：
datadir="/var/lib/proxysql"
admin_variables=
{
admin_credentials="admin:admin"
mysql_ifaces="127.0.0.1:6032;/tmp/proxysql_admin.sock"
}
mysql_variables=
{
threads=4
max_connections=2048
default_query_delay=0
default_query_timeout=36000000
have_compress=true
poll_timeout=2000
interfaces="0.0.0.0:3306;/tmp/mysql.sock"
default_schema="information_schema"
stacksize=1048576
server_version="5.5.30"
connect_timeout_server=3000
monitor_history=600000
monitor_connect_interval=60000
monitor_ping_interval=10000
monitor_read_only_interval=1500
monitor_read_only_timeout=500
ping_interval_server=120000
ping_timeout_server=500
commands_stats=true
sessions_sort=true
connect_retries_on_failure=10
}
mysql_servers =
(
{
address = "172.18.0.67" # no default, required . If port is 0 , address is interpred as a Unix Socket Domain
port = 3306 # no default, required . If port is 0 , address is interpred as a Unix Socket Domain
hostgroup = 0 # no default, required
status = "ONLINE" # default: ONLINE
weight = 1 # default: 1
compression = 0 # default: 0
},
{
address = "172.18.0.68"
port = 3306
hostgroup = 1
status = "ONLINE" # default: ONLINE
weight = 1 # default: 1
compression = 0 # default: 0
},
{
address = "172.18.0.69"
port = 3306
hostgroup = 1
status = "ONLINE" # default: ONLINE
weight = 1 # default: 1
compression = 0 # default: 0
}
)
mysql_users:
(
{
username = "root"
password = "mageedu"
default_hostgroup = 0
max_connections=1000
default_schema="mydb"
active = 1
}
)
mysql_query_rules:
(
)
scheduler=
(
)
mysql_replication_hostgroups=
(
{
writer_hostgroup=0
reader_hostgroup=1
}
)
2、搭建mysql服务器，并用mysqldump实现备份还原
备份工具：
mysqldump：mysql服务自带的备份工具；逻辑备份工具；#将表查出来，转换为insert语句，还原时在表插入数据
完全、部分备份；
InnoDB：热备；
MyISAM：温备；
cp/tar
lvm2：快照（请求一个全局锁），之后立即释放锁，达到几乎热备的效果；物理备份；
注意：不能仅备份数据文件；要同时备份事务日志；
前提：要求数据文件和事务日志位于同一个逻辑卷；
xtrabackup：
由Percona提供，开源工具，支持对InnoDB做热备，物理备份工具；
完全备份、部分备份；
完全备份、增量备份；
完全备份、差异备份；
mysqlhotcopy
select：
备份：SELECT cluase INTO OUTFILE ‘FILENAME‘;
恢复：CREATE TABLE
导入：LOAD DATA
mysqldump：
逻辑备份、完全备份、部分备份；
二次封装工具：
mydumper
phpMyAdmin
Usage:
mysqldump [OPTIONS] database [tables]
OR mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...]
OR mysqldump [OPTIONS] --all-databases [OPTIONS]
mysqldump mydb：表级别备份
mysqldump --databases mydb：库级别备份
MyISAM存储引擎：支持温备，备份时要锁定表；
-x, --lock-all-tables：锁定所有库的所有表，读锁；
-l, --lock-tables：锁定指定库所有表；
InnoDB存储引擎：支持温备和热备；
--single-transaction：创建一个事务，基于此快照执行备份；
其它选项：
-R, --routines：存储过程和存储函数；
--triggers
-E, --events
--master-data[=#]
1：记录为CHANGE MASTER TO语句，此语句不被注释；
2：记录为CHANGE MASTER TO语句，此语句被注释；
--flush-logs：锁定表完成后，即进行日志刷新操作；
mysqldump -uroot --all-databases -x -E --master-data=2 --flush-logs > /root/alldb-`date +%F`.sql
备份之后插入数据到表中
保存二进制日志，删库
还原
查表
mysql -uroot < alldb-2019-09-29.sql
还原
3、使用xtrabackup实现完全备份，增量备份，并还原
使用Xtrabackup进行MySQL备份：
一、安装
1、简介
Xtrabackup是由percona提供的mysql数据库备份工具，据官方介绍，这也是世界上惟一一款开源的能够对innodb和xtradb数据库进行热备的工具。特点：
(1)备份过程快速、可靠；
(2)备份过程不会打断正在执行的事务；
(3)能够基于压缩等功能节约磁盘空间和流量；
(4)自动实现备份检验；
(5)还原速度快；
2、安装
其最新版的软件可从 http://www.percona.com/software/percona-xtrabackup/ 获得。本文基于RHEL5.8的系统，因此，直接下载相应版本的rpm包安装即可，这里不再演示其过程。
二、备份的实现
1、完全备份
# innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/
如果要使用一个最小权限的用户进行备份，则可基于如下命令创建此类用户：
mysql> CREATE USER ’bkpuser’@’localhost’ IDENTIFIED BY ’s3cret’;
mysql> REVOKE ALL PRIVILEGES, GRANT OPTION FROM ’bkpuser’;
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO ’bkpuser’@’localhost’;
mysql> FLUSH PRIVILEGES;
使用innobakupex备份时，其会调用xtrabackup备份所有的InnoDB表，复制所有关于表结构定义的相关文件(.frm)、以及MyISAM、MERGE、CSV和ARCHIVE表的相关文件，同时还会备份触发器和数据库配置信息相关的文件。这些文件会被保存至一个以时间命名的目录中。
备份的目录以当前时间点为目录名，二进制日志记录点为000003 pos为245,表示备份的节点，以后可以基于这个节点往后利用二进制日志还原
在备份的同时，innobackupex还会在备份目录中创建如下文件：
(1)xtrabackup_checkpoints —— 备份类型（如完全或增量）、备份状态（如是否已经为prepared状态）和LSN(日志序列号)范围信息；
每个InnoDB页(通常为16k大小)都会包含一个日志序列号，即LSN。LSN是整个数据库系统的系统版本号，每个页面相关的LSN能够表明此页面最近是如何发生改变的。
(2)xtrabackup_binlog_info —— mysql服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置。
(3)xtrabackup_binlog_pos_innodb —— 二进制日志文件及用于InnoDB或XtraDB表的二进制日志文件的当前position。
(4)xtrabackup_binary —— 备份中用到的xtrabackup的可执行文件；
(5)backup-my.cnf —— 备份命令用到的配置选项信息；
在使用innobackupex进行备份时，还可以使用--no-timestamp选项来阻止命令自动创建一个以时间命名的目录；如此一来，innobackupex命令将会创建一个BACKUP-DIR目录来存储备份数据。
2、准备(prepare)一个完全备份
一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件仍处理不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。
innobakupex命令的--apply-log选项可用于实现上述功能。如下面的命令：
# innobackupex --apply-log /path/to/BACKUP-DIR
如果执行正确，其最后输出的几行信息通常如下：
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
120407 9:01:36 InnoDB: Starting shutdown...
120407 9:01:40 InnoDB: Shutdown completed; log sequence number 92036620
120407 09:01:40 innobackupex: completed OK!
在实现“准备”的过程中，innobackupex通常还可以使用--use-memory选项来指定其可以使用的内存的大小，默认通常为100M。如果有足够的内存可用，可以多划分一些内存给prepare的过程，以提高其完成速度。
删库
innobackupex --apply-log . #对当前目录执行指定应用日志
一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件仍处理不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。
innobakupex命令的--apply-log选项可用于实现上述功能。如下面的命令：
# innobackupex --apply-log /path/to/BACKUP-DIR
如果执行正确，其最后输出的几行信息通常如下：
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
120407 9:01:36 InnoDB: Starting shutdown...
120407 9:01:40 InnoDB: Shutdown completed; log sequence number 92036620
120407 09:01:40 innobackupex: completed OK!
在实现“准备”的过程中，innobackupex通常还可以使用--use-memory选项来指定其可以使用的内存的大小，默认通常为100M。如果有足够的内存可用，可以多划分一些内存给prepare的过程，以提高其完成速度。
3、从一个完全备份中恢复数据
注意：恢复不用启动MySQL
innobackupex命令的--copy-back选项用于执行恢复操作，其通过复制所有数据相关的文件至mysql服务器DATADIR目录中来执行恢复过程。innobackupex通过backup-my.cnf来获取DATADIR目录的相关信息。
# innobackupex --copy-back /path/to/BACKUP-DIR
如果执行正确，其输出信息的最后几行通常如下：
innobackupex: Starting to copy InnoDB log files
innobackupex: in ‘/backup/2012-04-07_08-17-03‘
innobackupex: back to original InnoDB log directory ‘/mydata/data‘
innobackupex: Finished copying back files.
120407 09:36:10 innobackupex: completed OK!
innobackupex --copy-back /data/backup/2019-09-29_22-51-00/
当数据恢复至DATADIR目录以后，还需要确保所有数据文件的属主和属组均为正确的用户，如mysql，否则，在启动mysqld之前还需要事先修改数据文件的属主和属组。如：
# chown -R mysql:mysql /mydata/data/
要实现第一次增量备份，可以使用下面的命令进行：
# innobackupex --incremental /backup --incremental-basedir=BASEDIR
其中，BASEDIR指的是完全备份所在的目录，此命令执行结束后，innobackupex命令会在/backup目录中创建一个新的以时间命名的目录以存放所有的增量备份数据。另外，在执行过增量备份之后再一次进行增量备份时，其--incremental-basedir应该指向上一次的增量备份所在的目录。
需要注意的是，增量备份仅能应用于InnoDB或XtraDB表，对于MyISAM表而言，执行增量备份时其实进行的是完全备份。
“准备”(prepare)增量备份与整理完全备份有着一些不同，尤其要注意的是：
(1)需要在每个备份(包括完全和各个增量备份)上，将已经提交的事务进行“重放”。“重放”之后，所有的备份数据将合并到完全备份上。
(2)基于所有的备份将未提交的事务进行“回滚”。
于是，操作就变成了：
# innobackupex --apply-log --redo-only BASE-DIR
接着执行：
# innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-1
而后是第二个增量：
# innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-2
innobackupex --copy-back ./
其中BASE-DIR指的是完全备份所在的目录，而INCREMENTAL-DIR-1指的是第一次增量备份的目录，INCREMENTAL-DIR-2指的是第二次增量备份的目录，其它依次类推，即如果有多次增量备份，每一次都要执行如上操作；
增量备份
innobackupex --incremental /data/backup/ --incremental-basedir=/data/backup2019-09-29_23-21-27
删除表操作
MariaDB [mydb]> delete from tb1 where id=1;
增量备份完之后在删除一次表，利用二进制日志还原
delete from tb1 where id=2;
查看完全备份二进制日志记录点
将记录点往后的记录导出
mysqlbinlog -j 1178 /data/mysql/mysql-bin.000001 > /root/xtraback-binlog.sql
然后删库
[root@centos7 2019-09-29_23-21-27]$ innobackupex --apply-log --redo-only . #第一次提交
innobackupex --apply-log --redo-only . --incremental-dir=/data/backup/2019-09-29_23-33-16 #将增量备份也应用至第一次的完备，然后合并日志
[root@centos7 2019-09-29_23-21-27]$innobackupex --copy-back ./ . #然后合并应用日志
innobackupex --copy-back ./ #还原需要修改权限
set sql_log_bin=OFF; #关闭
source /tmp/xtraback-binlog.sql #在还原xtrabackup
4、搭建redis，并说明redis持久化原理
程序环境：
配置文件：/etc/redis.conf
主程序：/usr/bin/redis-server
6379/tcp
客户端：/usr/bin/redis-cli
Unit File:/usr/lib/systemd/system/redis.service
数据目录：/var/lib/redis
安装：
$ wget http://download.redis.io/releases/redis-5.0.5.tar.gz
$ tar xzf redis-5.0.5.tar.gz
$ cd redis-5.0.5
$ make
$ src/redis-server
$ src/redis-cli
redis> set foo barOK
redis> get foo"bar"
配置和使用Redis：
基本配置项
网络配置项
持久化相关配置
复制相关的配置
安全相关配置
Limit相关的配置
SlowLog相关的配置
INCLUDES
Advanced配置
网络配置项：
bind IP
port PORT
protected-mode
tcp-backlog
unixsocket
timeout：连接的空闲超时时长；
安全配置：
requirepass <PASSWORD>
rename-command <COMMAND> <NEW_CMND_NAME>
在AOF或Replication环境中，不推荐使用；
Limits相关的配置：
maxclients
maxmemory <bytes>
maxmemory-policy noeviction
淘汰策略：volatile-lru, allkeys-lru, volatile-random, allkeys-random, volatile-ttl, noeviction
maxmemory-samples 5
淘汰算法运行时的采样样本数；
SlowLog相关的配置:
slowlog-log-slower-than 10000
单位是微秒；
slowlog-max-len 128
SlowLog记录的日志最大条目；
Redis的持久化:
RDB：snapshotting, 二进制格式；按事先定制的策略，周期性地将数据从内存同步至磁盘；数据文件默认为dump.rdb；
客户端显式使用SAVE或BGSAVE命令来手动启动快照保存机制；
SAVE：同步，即在主线程中保存快照，此时会阻塞所有客户端请求；
BGSAVE：异步；
AOF：Append Only File, fsync
记录每次写操作至指定的文件尾部实现的持久化；当redis重启时，可通过重新执行文件中的命令在内存中重建出数据库；
BGREWRITEAOF：AOF文件重写；
不会读取正在使用AOF文件，而是通过将内存中的数据以命令的方式保存至临时文件中，完成之后替换原来的AOF文件；
RDB相关的配置：
*save <seconds> <changes>
save 900 1
save 300 10
save 60 10000
表示：三个策略满足其中任意一个均会触发SNAPSHOTTING操作；900s内至少有一个key有变化，300s内至少有10个key有变化，60s内至少有1W个key发生变化；
stop-writes-on-bgsave-error yes
dump操作出现错误时，是否禁止新的写入操作请求；
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb：指定rdb文件名
*dir /var/lib/redis：rdb文件的存储路径
AOF相关的配置
*appendonly no
appendfilename "appendonly.aof"
*appendfsync
Redis supports three different modes:
no：redis不执行主动同步操作，而是OS进行；
everysec：每秒一次；
always：每语句一次；
no-appendfsync-on-rewrite no
是否在后台执行aof重写期间不调用fsync，默认为no，表示调用；
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
上述两个条件同时满足时，方会触发重写AOF；与上次aof文件大小相比，其增长量超过100%，且大小不少于64MB;
aof-load-truncated yes
注意：持久机制本身不能取代备份；应该制订备份策略，对redis库定期备份；
RDB与AOF同时启用：
(1) BGSAVE和BGREWRITEAOF不会同时进行；
(2) Redis服务器启动时用持久化的数据文件恢复数据，会优先使用AOF；
5、搭建redis，并实现主从复制
复制：
特点：
一个Master可以有多个slave主机，支持链式复制；
Master以非阻塞方式同步数据至slave主机；
配置slave节点：
redis-cli> SLAVEOF <MASTER_IP> <MASTER_PORT>
redis-cli> CONFIG SET masterauth <PASSWORD>
配置参数：
*slaveof
*masterauth
slave-serve-stale-data yes
slave-read-only yes
*repl-diskless-sync no
no, Disk-backed, Diskless
新的从节点或某较长时间未能与主节点进行同步的从节点重新与主节点通信，需要做“full synchronization"，此时其同步方式有两种style：
Disk-backend：主节点新创建快照文件于磁盘中，而后将其发送给从节点；
Diskless：主节占新创建快照后直接通过网络套接字文件发送给从节点；为了实现并行复制，通常需要在复制启动前延迟一个时间段；
repl-diskless-sync-delay 5
repl-ping-slave-period 10
*repl-timeout 60
repl-disable-tcp-nodelay no
repl-backlog-size 1mb
*slave-priority 100
复制集群中，主节点故障时，sentinel应用场景中的主节点选举时使用的优先级；数字越小优先级越高，但0表示不参与选举；
min-slaves-to-write 3：主节点仅允许其能够通信的从节点数量大于等于此处的值时接受写操作；
min-slaves-max-lag 10：从节点延迟时长超出此处指定的时长时，主节点会拒绝写入操作；
在从节点上修改配置文件，增加主节点ip端口，验证密码
Server相关的命令：
CLIENT GETNAME
*CLIENT KILL
CLIENT KILL [ip:port] [ID client-id] [TYPE normal|master|slave|pubsub] [ADDR ip:port] [SKIPME yes/no]
*CLIENT LIST
CLIENT PAUSE
CLIENT PAUSE timeout
CLIENT REPLY
CLIENT SETNAME：Set the current connection name
SHUTDOWN [NOSAVE|SAVE]
CONFIG GET #查询配置文件中的配置段
CONFIG RESETSTAT
CONFIG REWRITE #将命令行中保存的配置写入配置文件
CONFIG SET #在命令行中修改配置文件中的配置
INFO：服务器状态信息查看；分为多个secion；
INFO [section]
在命令行中直接配置从节点加入主节点复制
配置完成后，使用config rewrite 写入配置文件完成永久有效
6、搭建redis集群
sentinel：https://redis.io/topics/sentinel #官方文档
主要完成三个功能：监控、通知、自动故障转移
选举：流言协议、投票协议
配置项：
port 26379
sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel auth-pass <master-name> <password>
<quorum>表示sentinel集群的quorum机制，即至少有quorum个sentinel节点同时判定主节点故障时，才认为其真的故障；
s_down: subjectively down
o_down: objectively down
sentinel down-after-milliseconds <master-name> <milliseconds>
监控到指定的集群的主节点异常状态持续多久方才将标记为“故障”；
sentinel parallel-syncs <master-name> <numslaves>
指在failover过程中，能够被sentinel并行配置的从节点的数量；
sentinel failover-timeout <master-name> <milliseconds>
sentinel必须在此指定的时长内完成故障转移操作，否则，将视为故障转移操作失败；
sentinel notification-script <master-name> <script-path>
通知脚本，此脚本被自动传递多个参数；
redis-cli -h SENTINEL_HOST -p SENTINEL_PORT
redis-cli>
SENTINEL masters
SENTINEL slaves <MASTER_NAME>
SENTINEL failover <MASTER_NAME>
SENTINEL get-master-addr-by-name <MASTER_NAME>
vim /etc/redis-sentinel.conf #修改配置文件
port 26379
bind 0.0.0.0
sentinel monitor mymaster 192.168.1.196 6379 2 #添加监控主节点ip及端口，以及投票权重
sentinel auth-pass mymaster 123456 #密码
sentinel down-after-milliseconds mymaster 5000 #超时时长
sentinel parallel-syncs mymaster 1 #几路并发时间
sentinel failover-timeout mymaster 180000 #sentinel必须在此指定的时长内完成故障转移操作，否则，将视为故障转移操作失败；
复制至其他节点。
systemctl start redis-sentinel #在其他节点启动sentinel服务即可
会自动记录主从节点
redis cluster
修改配置文件。
vim /etc/redis.conf
cluster-enabled yes #启用集群
cluster-config-file cluster.conf #集群配置文件
cluster-node-timeout 15000 #超时时长
cluster-slave-validity-factor 10 #主从判断因子
将配置文件复制至其他集群节点
rm -rf /var/lib/redis/dump.rdb #这里我删除之前配置的数据。
redis-cli -a 123456 -c cluster addslots {0..5500}
启动redis后为每个节点分配slots； cluster addslots
每个slot要独立创建，可用范围为0-16383，共16384个；
redis-cli -h 192.168.1.198 -a 123456 -c cluster addslots {5501..11000}
redis-cli -h 192.168.1.202 -a 123456 -c cluster addslots {11001..16385}
设定集群成员关系；cluster meet
cluster info;
集群建立成功后每个slots都为16384
标签：插件 exp 说明 ora 时间 support loaded 大于 nal
原文地址：https://www.cnblogs.com/woaiyitiaochai/p/11757986.html
