1.故障级别
S1 最严重的，影响30%的交易额持续15分钟以上，或者影响30%的用户正常访问，持续15分钟以上
S2 比较严重，影响15%的交易额15分钟以上
S3 严重故障，影响5%的交易额15分钟左右
S4 故障，影响1%的交易额
2.性能问题
Scale up：单台服务器的硬件升级来提高性能，容易达到极限
Scale out：增加服务器的数量，利用负载均衡，进行统一管理
3.mysql主从复制过程架构图
第一步：mysql将事务串行的写入二进制日志
第二步：slave通过I/O线程将master的二进制日志（binary log events）拷贝到自己的中继日志。
第三步：slave的SQL（从线程）从中继日志中读取事件，并重放其中的事件从而更新slave的数据，使其与master中的数据一致。
4.数据库主从架构复制（关selinux和iptables）
环境准备：一台做mysql主服务器，一台做mysql从服务器，时钟最好同步。
1）配置主master服务器
2）配置master主服务器
首先配置/etc/my.cnf文件
server-id=1 # 配置一个ID号，从而与其他的服务器区分开来
log-bin=mysql-bin #打开mysql日志，格式为二进制
接下来创建slave的账号
MariaDB [(none)]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO slave@'172.17.253.127' IDENTIFIED BY '123456';
查看主服务器状态
Show master status；
3）配置slave服务器
首先配置/etc/my.cnf文件
server-id=2 #配置ID号，从而与其他服务器区分开来
relay-log=mysql-relay-log #打开mysql日志，格式为二进制
read-only=1 #设置只读权限
log-bin=mysql-bin #开一从服务器二进制日志
log-slave-updates=1 #使更新的数据写进二进制日志中
接下来启动从服务器复制线程（与master需要一个网段内）
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='172.17.253.191', MASTER_USER='slave', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=419;
启动复制线程
Start slave;
查看服务器状态，有这两项则启动成功
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
4）在master上创建库，slave上可以查看到，结束！
5.mysql复制过滤器
概念：并不复制所有数据，而仅复制一个或几个数据库相关的数据，有两种实现思路。
一是在主服务器上设置，仅向二进制文件中记录有关特定数据库相关的写操作
Binlog_do_db= 仅仅做某个操作
Binlog_ignore_db= 除了设定的操作，其他的都做
二是在从服务器的设置，在SQL线程仅放关注的数据库或表相关的事件
Replicate_do_db= 仅读指定的数据
Replicate_ignore_db= 除了指定的数据，都读入
6.企业常见数据库架构
1）单一master和多个slave
实际中百分之90都是这样的架构，因为大部分情况下都是读访问比写访问要多的多，在这种情况下，对于数据实时性要求不是很高的话，单纯增加slave的数量，比较廉价而且效果很好。
2）两个master互为主从
Master-master复制的两台服务器，既是master，又是另一台的salve，这样，任何一方所做的变更，都会通过复制应用到另一方的数据库中。
# 172.17.253.191上进行如下操作
My.cnf配置文件中加入
auto_increment_offset=1
auto_increment_increment=2 ##使用奇数ID
进行数据库配置
MariaDB [LN]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO slave@'172.17.253.127' IDENTIFIED BY '123456';
MariaDB [LN]> CHANGE MASTER TO MASTER_HOST='172.17.253.127', MASTER_USER='slave', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000009', MASTER_LOG_POS=245;
Start slave；
Show status slave\G；IO和SQL为yes即可
172.17.253.127上进行如下操作
auto_increment_offset=2
auto_increment_increment=2##使用偶数ID
进行数据库配置
MariaDB [LN]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO slave@'172.17.253.191' IDENTIFIED BY '123456';
MariaDB [LN]> CHANGE MASTER TO MASTER_HOST='172.17.253.191', MASTER_USER='slave', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000009', MASTER_LOG_POS=245;
Start slave；
Show status slave\G；IO和SQL为yes即可
测验：
在191上创建表，并设置为自增长ID，检验效果
使用LN数据库
创建自增长ID表
在127上插入数据
查看表，成功
7.自增长ID，主键，外键，索引
自增长ID：对于某些唯一性的字段，例如一个班的学生的学号，可以通过设置自增长ID来实现，自增长ID的数据，代表这个表中存在一条唯一的记录，而且自增长ID是肯定不会重复的。
主键：关系型数据库的一条记录有若干个属性，若其中某一个属性组（注意是组）能唯一标识一条记录，该属性组就可以成为一个主键，如学生表（学号，姓名，性别，班级）中，学号就是一个主键
外键：例如成绩表（学号，课程号，成绩），学号和课程号合称为主键，因为单单一个学号或者课程号并不能标识一个学生的成绩，而在学生表（学号，姓名，性别，班级）中，学号是主键，此时成绩表中的学号就是学生表中的外键。
外键主要用来连表查询，即通过学号查询了相关信息后，再把学号映射到成绩表中，和课程号结合，可以查看成绩。
索引：快速搜索的关键，没有索引的话，查询的时候会全库查询，比较慢
8.复制策略:异步，全同步，半同步
异步：这是默认的复制策略，master在执行完客户端的请求后，会立即将结果返给客户端，并不关心slave是否已经接受并处理，这样就会带来一个问题，当master宕机时，master的数据可能还没有全部传输到slave上，如果此时，强行将slave提升为master，就会造成数据不完整。
全同步：当master执行完一个客户端的请求后，会等待所有的slave执行完数据复制后才将事务返还给客户端，然而这样性能会受到严重的影响。
半同步：介于上述两者之间，当master执行完客户端的请求后，会等待至少一台slave完成数据复制才会将事务返还给客户端，这样提高了数据的安全性，但是也造成了一定程度的延迟，所以，半同步最好在延迟低的网络中使用。
9.开启半同步复制
主上
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
SET GLOBAL rpl_semi_sync_master_enabled=ON;
SHOW GLOBAL VARIABLES LIKE 'rpl_semi%';
| rpl_semi_sync_master_enabled | ON |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_no_slave | ON |
+------------------------------------+-------+
从上
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
MariaDB [mydb]> STOP SLAVE IO_THREAD;
MariaDB [mydb]> SET GLOBAL rpl_semi_sync_slave_enabled = ON ;
MariaDB [mydb]> START SLAVE ;
MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE 'rpl_semi%';
查看是否生效
Tail -200 /var/log/mariadb/mariadb.log，有以下记录则生效
10.MHA
1）
是什么：（Master HA），即主高可用，它为mysql主从复制架构提供了自动成为主的功能，当master宕机的时候，mha会监控到故障的节点，并且提升拥有最新数 据的slave节点成为新的master，并且还会自动通过其他节点获得额外的信息来避免一致性方面的问题，mha还提供了master在线切换的功能，即按需要切换master/slave节点。
2）MHA工作原理总结
从宕机崩溃的master保存二进制日志事件
识别含有最新更新的slave
应用差异的中继日志到其他的slave
应用从master保存的二进制日志事件
提升一个slave为新的master
使用其他的slave连接新的master进行复制
11.Mysql高可用架构之MHA
1）环境准备
一台做manager节点，一台做master节点，一台以上的slave节点。
2）在各节点的/etc/hosts文件配置内容中添加：
172.17.253.25 node1.magedu.com node1
172.17.253.127 node2.magedu.com node2
172.17.253.191node3.magedu.com node3
这样做的目的是在今后的工作中，能够通过域名对应的编号更快速的找到故障的机器
3）matse节点配置
[mysqld]
Server-id=1
Log-bin=master-log
Relay-log=relay-log
Skip_name_resolve=ON
slave节点配置
[mysqld]
server-id = 12
relay-log = relay-log
log-bin = master-log
read_only = ON
relay_log_purge = 0
skip_name_resolve = YES
4)做好主从复制，确保slave和master工作正常，在slave上的IO和SQL线程正常链接（上面有）
5）准备基于ssh互相通信环境
ssh-keygen -t rsa #生成密钥
ssh-copy-id root@172.17.253.191 #将公钥传给需要面密码登陆的机器，输入yes和密码后，就成功了。
6)在master上安装
mha4mysql-manager-0.56-0.el6.noarch.rpm 和mha4mysql-node-0.56-0.el6.norch.rpm.
在master和所有slave节点上安装 mha4mysql-node-0.56-0.el6.norch.rpm.
7）定义mha的配置文件
8）在manager上检测各个节点之间的ssh通信是否OK
OK后检测复制集群的链接配置是否正常
如果有报错，就看报错提示的是什么，可能是权限问题，可能是防火墙问题，也可能是主从复制没有实现等等
9）启动mha
检测开启状态
10）模拟master故障，关掉master上的mariadb服务，检测manager.log日志查看是否master自动转移到了slave上面。
11）转移成功后，再将master和slave配置好，然后启动mha服务就OK了
