mysql,redis

一、搭建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

一、查询日志

记录查询语句，日志存储位置：

文件：file

表：table (mysql.general_log)

general_log={ON|OFF}

general_log_file=HOSTNAME.log

log_output={FILE|TABLE|NONE}

二、慢查询日志

慢查询：运行时间超出指定时长的查询；

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

三、错误日志

记录信息：

(1) mysqld启动和关闭过程 输出的信息；

(2) mysqld运行中产生的错误信息；

(3) event scheduler运行时产生的信息；

(4) 主从复制架构中，从服务器复制线程启动时产生的日志；

log_error=

/var/log/mariadb/mariadb.log|OFF

log_warnings={ON|OFF}

四、二进制日志

用于记录引发数据改变或存在引发数据改变的潜在可能性的语句（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；

一、数据不一致；

二、自动增加id；

定义一个节点使用奇数id

auto_increment_offset=1

auto_increment_increment=2

另外一个节点使用偶数id

auto_increment_offset=2

auto_increment_increment=2

配置：

一、server_id必需要使用不一样值；

二、均启用binlog和relay log；

三、存在自动增加id的表，为了使得id不相冲突，须要定义其自动增加方式；

服务启动后执行以下两步：

四、都受权有复制权限的用户帐号；

五、各把对方指定为主节点；

复制时应该注意的问题：

一、从服务设定为“只读”；

在从服务器启动read_only，但仅对非SUPER权限的用户有效；

阻止全部用户：

mysql> FLUSH TABLES WITH READ LOCK;

二、尽可能确保复制时的事务安全

在master节点启用参数：

sync_binlog = ON

若是用到的是InnoDB存储引擎：

innodb_flush_logs_at_trx_commit=ON

innodb_support_xa=ON

三、从服务器意外停止时尽可能避免自动启动复制线程

四、从节点：设置参数

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；

一、数据不一致；

二、自动增加id；

定义一个节点使用奇数id

auto_increment_offset=1

auto_increment_increment=2

另外一个节点使用偶数id

auto_increment_offset=2

auto_increment_increment=2

配置：

一、server_id必需要使用不一样值；

二、均启用binlog和relay log；

三、存在自动增加id的表，为了使得id不相冲突，须要定义其自动增加方式；

服务启动后执行以下两步：

四、都受权有复制权限的用户帐号；

五、各把对方指定为主节点；

复制时应该注意的问题：

一、从服务设定为“只读”；

在从服务器启动read_only，但仅对非SUPER权限的用户有效；

阻止全部用户：

mysql> FLUSH TABLES WITH READ LOCK;

二、尽可能确保复制时的事务安全

在master节点启用参数：

sync_binlog = ON

若是用到的是InnoDB存储引擎：

innodb_flush_logs_at_trx_commit=ON

innodb_support_xa=ON

三、从服务器意外停止时尽可能避免自动启动复制线程

四、从节点：设置参数

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

}

)

二、搭建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

还原

 

 

三、使用xtrabackup实现彻底备份，增量备份，并还原

使用Xtrabackup进行MySQL备份：

1、安装

一、简介

Xtrabackup是由percona提供的mysql数据库备份工具，据官方介绍，这也是世界上唯一一款开源的可以对innodb和xtradb数据库进行热备的工具。特色：

(1)备份过程快速、可靠；

(2)备份过程不会打断正在执行的事务；

(3)可以基于压缩等功能节约磁盘空间和流量；

(4)自动实现备份检验；

(5)还原速度快；

二、安装

其最新版的软件可从 http://www.percona.com/software/percona-xtrabackup/ 得到。本文基于RHEL5.8的系统，所以，直接下载相应版本的rpm包安装便可，这里再也不演示其过程。

2、备份的实现

一、彻底备份

# 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目录来存储备份数据。

二、准备(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的过程，以提升其完成速度。

 

三、从一个彻底备份中恢复数据

注意：恢复不用启动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

 

四、搭建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的几个配置段

配置和使用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；

 

五、搭建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 写入配置文件完成永久有效

 

 

 

六、搭建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