数据库查询多节点
多节点数据库查询的益处：
1.特性高些，根据负载均衡提升网络服务器的负荷
2.安全隐患，如果有多节点，一个数据库查询服务器宕机也有另一个数据库查询能够浏览
或是假如由于服务器宕机造成一个数据库查询的内容丢失，还能够有别的数据库查询的备份数据，这一称为缓存溢出。
主从复制便是数据库查询多节点的在其中一个方式：
它取决于binlog日志
主从复制的应用情景：
二种：数据备份 和 读写分离
完成读写分离，进而提升数据库查询的特性，例如有两部网络服务器，一台主连接点，一台从连接点，在主库开展删改改，因此 主库要开事务管理，实际操作起來较慢。而从库只开展载入，读是可以不加上事务管理的，会快许多，我们可以布署几台从库开展载入，只需数据信息写进了主库，全部的从库都是会开展升级。
并且完成了缓存溢出，提升了安全系数。
主从复制的基本原理：
假定现在有一台主连接点，四台从连接点。主库专业承担写，从库只承担读。
主库开事务管理，从库不动。
当主库插入了一条数据信息，那麼这一插进实际操作会被纪录到主库的日志文档，而从库会载入主库的日志文档里边的实际操作，并实行一遍，那样从库也会造成那么一条数据信息。这一日志便是binlog日志
从连接点不可以过多，不然这种从库都去载入日志文档并同歩便会造成同歩的廷时难题，从连接点们间的数据信息就很有可能不一致。
假如从连接点过多，大家就需要在业务流程上开展改进了。
===================== =================================
binlog日志：
在这儿顺带说一下，MySQL有什么日志：
Error log 不正确日志
General query log 一般查看日志
Slow query log 慢日志文档
binary log 二进制日志
binary log 便是个二进制文件，纪录着数据库查询全部DML和DDL实际操作，他的功效有两个：
1.增量备份
2.主从复制
大家应用mysqldump开展备份数据的情况下，一般是备份数据全部数据库查询，可是会造成较为大的数据信息，假如期待只备份数据新造成的值，就必须采用二进制日志，载入里边的实际操作。
mysql默认设置不打开binlog的。
show variables like "%log_bin%"
--------------------------------- -------
| Variable_name | Value |
--------------------------------- -------
| log_bin | OFF |
| log_bin_trust_function_creators | OFF |
| sql_log_bin | ON |
--------------------------------- -------
打开binlog
进到my.cnf
vi /etc/my.cnf
在[mysqld]下添加二行（在别的地区加失效）：
server-id = 1
log-bin=/var/lib/mysql/mysql-bin #特定二进制文件的文件夹名称的basename
重新启动
这时/var/lib/mysql会出現2个文档
mysql-bin.000001 #二进制文件
mysql-bin.index #二进制数据库索引文档
怎么查看二进制日志內容：
mysqlbinlog 二进制文件名途径
或是 先登陆手机客户端，随后
show binglog events in "日志文件夹名称"
二进制日志一部分內容以下：
# at 59484
#200113 9:14:45 server id 1 end_log_pos 59591 Query thread_id=461 exec_time=0 error_code=0
use `test`/*!*/;
SET TIMESTAMP=1578878085/*!*/;
create table test1(id int,name varchar(100))
/*!*/;
# at 59591
#200113 9:15:15 server id 1 end_log_pos 59659 Query thread_id=461 exec_time=0 error_code=0
SET TIMESTAMP=1578878115/*!*/;
BEGIN
/*!*/;
# at 59659
#200113 9:15:15 server id 1 end_log_pos 59756 Query thread_id=461 exec_time=0 error_code=0
SET TIMESTAMP=1578878115/*!*/;
insert into test1 values (1,"zbp")
/*!*/;
# at 59756
#200113 9:15:15 server id 1 end_log_pos 59783 Xid = 25496
COMMIT/*!*/;
上边从 # at xxx 到 /*!*/;是一个详细的一部分，这些称为事情，事情包含两一部分：
事情头 是该实际操作的一些信息内容，如实际操作在二进制日志的逐渐部位 "# at 59591"，实行时的時间 "SET TIMESTAMP=1578878115"，实行所变化的的時间“exec_time=0” 等
事情体 实际的实际操作句子 如 “insert into test1 values (1,"zbp")”
因此 依据二进制日志，我们可以做一些修复实际操作。
show binglog events; # 只表明mysql-bin.000001的內容，假如想查询别的日志文档內容就需要特定日志文件夹名称
*************************** 593. row ***************************
Log_name: mysql-bin.000001
Pos: 58929
Event_type: Query
Server_id: 1
End_log_pos: 59099
Info: use `zbpblog`; UPDATE `blogs` SET `real_click` = `real_click` 1 WHERE `create_time` <= 1578876263 AND `id` = '26'
*************************** 594. row ***************************
Log_name: mysql-bin.000001
Pos: 59099
Event_type: Query
Server_id: 1
End_log_pos: 59171
Info: COMMIT
*************************** 595. row ***************************
Log_name: mysql-bin.000001
Pos: 59171
Event_type: Query
Server_id: 1
End_log_pos: 59242
Info: BEGIN
*************************** 596. row ***************************
Log_name: mysql-bin.000001
Pos: 59242
Event_type: Query
Server_id: 1
End_log_pos: 59412
Info: use `zbpblog`; UPDATE `blogs` SET `real_click` = `real_click` 1 WHERE `create_time` <= 1578876861 AND `id` = '32'
*************************** 597. row ***************************
Log_name: mysql-bin.000001
Pos: 59412
Event_type: Query
Server_id: 1
End_log_pos: 59484
Info: COMMIT
每一次重启服务器，会新创建一个binlog日志（根据flush logs指令），那麼这有哪些好处呢呢：
例如昨日有一个binlog文件，今日有一个binlog日志，今日发觉昨日有一个操作失误，要修复，就可以对于昨日的日志文档来做修复。并且那样也不会让一个binlog文件很大。
二进制实际操作：
flush logs # 更新日志文档
show binlog events in "xxx" #查询日志文档內容
show master status # 查询当今应用的日志的情况
show master logs # 查询全部日志文档（等同于查询日志数据库索引文档）
reset master # 清除全部日志文档（十分风险，不建议）
# 怎么使用二进制文件恢复数据库（此方式只适用修复小量数据信息）
mysqlbinlog mysql-bin.000001 | mysql -uroot -p
该指令(应用了管路符)会将mysql-bin.000001中全部的MySQL实际操作都实行一遍；
可是大家的操作失误为：
delete from user where id = 56;
这时我们要修复的数据信息仅有一条，不太可能为了更好地修复一条数据信息而将一全部日志文档都实行一遍。
这时大家就需要找到 id为56的这一条数据信息时在什么时候建立的，随后寻找相对的binlog日志文档，应用 mysqlbinlog 文件夹名称 去查询创建id为56的数据信息的起止和完毕部位（便是 #at xxx ,完毕部位便是下一个事情的起止部位），倘若这一部位是 123 166
实行：
mysqlbinlog mysql-bin.000001 --start-position 123 --stop-position 166 | mysql -uroot -p
就可以；
还能够应用 –start-datetime=xxx 和 –stop-datetime=xxx 依据时间格式范畴去修复，自然還是要查询二进制文件，看这个事情是啥時间建立的数据信息。
因此 二进制日志文件找回数据信息是有局限性的：
假如删掉的是很悠久的数据信息，要寻找这一数据信息建立或是改动实际操作确实哪一个二进制日志的哪一个部位，很不便。
假如删掉的数据信息不只是一条，也要找好几条数据信息的建立是在哪些日志的什么部位。
因此 该方式适用刚产生的或几日内产生的，并且是小量数据信息的操作失误的修复。
如果是很多数据信息的误删，大家只有根据平常备份数据来修复。因此 平常多做备份数据才是硬道理。
PS：二进制日志只纪录删改改，不容易查询记录句子
有关二进制日志的三种方式(文件格式):
mysql拷贝关键有三种方法：根据SQL句子的拷贝(statement-based replication, SBR)，根据行的拷贝(row-based replication, RBR)，混合模式拷贝(mixed-based replication, MBR)。
相匹配的，binlog的文件格式也是有三种：STATEMENT，ROW，MIXED。
① STATEMENT方式（SBR）
每一条会改动数据信息的sql语句会纪录到binlog中。优势是并不一定纪录每一条sql语句和每一行的数据信息转变 ，降低了binlog日志量，节省IO，提升特性。缺陷是在一些状况下能造成master-slave中的数据信息不一致(如sleep()涵数， last_insert_id()，及其user-defined functions(udf)待会出現难题)
② ROW方式（RBR）
不纪录每条sql语句的前后文信息内容，仅需纪录哪一条数据信息被改动了，改动成哪些了。并且不容易出現一些特殊状况下的sql语句、或function、或trigger的启用和开启没法被恰当拷贝的难题。缺陷是会造成很多的日志，尤其是alter table的情况下会让日志疯涨。
③ MIXED方式（MBR）
之上二种方式的混和应用，一般的拷贝应用STATEMENT方式储存binlog，针对STATEMENT方式无法复制的实际操作应用ROW方式储存binlog，MySQL会依据实行的SQL句子挑选日志储存方法。
SBR 的优势：
有悠久的历史，技术性完善
binlog文件较小
binlog中包括了全部数据库查询变更信息内容，能够由此来审批数据库查询的安全性等状况
binlog能够用以即时的复原，而不仅用以拷贝
主从关系版本号能够不一样，从服务器版本号能够比主网络服务器版本号高
SBR 的缺陷：
非是全部的UPDATE句子都能被拷贝，尤其是包括不确定性实际操作的情况下。
启用具备不确定因素的 UDF 时拷贝也很有可能出难题
应用下列涵数的句子也没法被拷贝：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非是启动开启了 –sysdate-is-now 选择项)
INSERT … SELECT 会造成比 RBR 大量的行级锁
拷贝必须开展全表扫描仪(WHERE 句子中沒有应用到数据库索引)的 UPDATE 时，必须比 RBR 要求大量的行级锁
针对有 AUTO_INCREMENT 字段名的 InnoDB表来讲，INSERT 句子会堵塞别的 INSERT 句子
针对一些繁杂的句子，在从服务器上的耗資源状况会更比较严重，而 RBR 方式下，总是对那一个产生变化的纪录造成危害
储存涵数(并不是sql语句)在被启用的另外也会实行一次 NOW() 涵数，这一能够说成错事也可能是好事儿
明确了的 UDF 也必须在从服务器上实行
数据分析表务必基本上和主网络服务器保持一致才行，不然很有可能会造成拷贝打错
实行繁杂句子假如打错得话，会耗费大量資源
RBR 的优势：
一切状况都能够被拷贝，这对拷贝而言是最可以信赖的
和别的大部分数据库管理的数据存储方式一样
大部分状况下，从服务器上的表如果有主键得话，拷贝便会快了许多
拷贝下列几类句子时的行锁越来越少：
* INSERT … SELECT
* 包括 AUTO_INCREMENT 字段名的 INSERT
* 沒有附带条件或是并沒有改动许多纪录的 UPDATE 或 DELETE 句子
实行 INSERT，UPDATE，DELETE 句子时锁越来越少
从服务器上选用线程同步来实行拷贝变成很有可能
RBR 的缺陷：
binlog 变大许多
繁杂的回退时 binlog 中会包括很多的数据信息
主网络服务器上实行 UPDATE 句子时，全部产生变化的纪录都是会写到 binlog 中，而 SBR 总是写一次，这会造成经常产生 binlog 的高并发写难题
UDF 造成的大 BLOB 会造成拷贝减缓
没法从 binlog 中见到都拷贝了写什么句子
如在非事务管理表里实行一段沉积的SQL句子时，最好是选用 SBR 方式，不然非常容易造成主从关系网络服务器的数据信息不一致状况产生
此外，对于系统库 mysql 里边的表产生变化时的解决标准以下：
如果是选用 INSERT，UPDATE，DELETE 立即实际操作表的状况，则日志文件格式依据 binlog_format 的设置而纪录
如果是选用 GRANT，REVOKE，SET PASSWORD 等管理方法句子来做得话，那麼不管怎样都选用 SBR 方式纪录
注：选用 RBR 方式后，能处理许多原来出現的主键反复难题。
因此 假如要开展主从复制得话,最好设置binlog的文件格式为mixed,能够避免 由于binlog文件格式和mysql版本号不一致造成的同歩sql不成功
只需在环境变量中加上:
binlog_format=mixed # 默认设置是statement文件格式
就可以；
============================================
MySQL主从复制：
倘若有一个主连接点 一个从节 点（一个从连接点和好几个从连接点的实际操作同样）
流程以下：
1.配备主连接点：
建立客户授予管理权限
打开binlog日志
2.配备从连接点
配备同歩主连接点日志
特定主连接点的ip，端口号，客户
运行从连接点
配备主连接点的流程
建立客户：
最先我们要建立客户，特定求助者的IP，特定该客户的管理权限
如今大家特定客户名叫repl，登陆密码 repl，到访ip为 192.168.153.%,即这一子网的IP都能浏览
如今大家给该客户授予管理权限
grant replication slave on *.* to "repl"@"192.168.153.%" identified by "repl";
意思是对repl这一客户授予主从复制的管理权限，范畴是全部库和表
打开binlog日志
server-id = 1
log-bin=/var/lib/mysql/mysql-bin #特定二进制文件的文件夹名称的basename
配备从连接点的流程
配备同歩日志：
server-id=10
relay-log=/var/lib/mysql/relay-bin #同歩日志文档的途径
relay-log-index=/var/lib/mysql/relay-bin.index #同歩日志文档数据库索引的途径
留意，同歩日志和从服务器自身的二进制日志是两码事，同歩日志只承担纪录主连接点的日志內容（主连接点的实际操作），不容易纪录从连接点自身的实际操作
特定主连接点的ip，端口号，客户：
change master to master_host="主连接点主机ip",master_port=3306,master_user="客户",master_password="客户登陆密码",master_log_file="mysql-bin.000001",master_log_pos=0;
# 在其中 master_log_file="mysql-bin.000001",master_log_pos=0 这两项并不是随意填的，只是要在主连接点实行show master status 来查询主连接点当今应用的二进制文件名和最终的部位pos
运行从连接点:
start slave
查询从连接点情况：
show slave status
要是没有配备取得成功，看里边的Last_IO_Error这一字段名，他会对你说不正确缘故
这时你很可能发觉主连接点连不上，这是由于服务器防火墙及其数据库查询中环境变量限制了bind-address=127.0.0.1 ，也就是主连接点只容许该设备联接。
如果是服务器防火墙的难题，关闭防火墙，随后再从服务器中stop slave 再start slave
如果是只容许该设备联接，则在bind-address中加上一条从服务器的IP
bind-address=127.0.0.1 从服务器IP
设置bind-address=0.0.0.0 表明容许一切ip联接主网络服务器，可是这一个人行为很危险，假如你的数据库查询设置密码的简单的话很可能被侵入数据库查询。（改动环境变量后还记得重新启动服务项目）
下面应用PHP完成主从关系连接点读写分离：
构思非常简单:
1.界定好承担写的主连接点的ip和诸多从连接点的ip
2.依据sql语句分辨是select還是删改改实际操作
3.如果是删改改则联接主连接点实行实际操作,不然联接从连接点开展实际操作
4.联接从连接点的情况下是遵照任意分派,应用mt_rand()涵数就可以
如果是应用TP5得话更简易,只必须开展配备就可以。
==============================================
主主拷贝：
有两个主连接点A B，都是有binlog日志，我们可以对A写和读，还可以对B写和读，不象主从复制，主连接点承担写，诸多从连接点承担读。
对连接点A写，连接点B能够同歩连接点A的数据信息，相反也是
换句话说A是主连接点也是以连接点，B也是主连接点也是以连接点；
因此 ，大家只必须将上边的主从复制的流程开展二遍就可以：
假定如今早已配备取得成功主主拷贝了，会出現那么一个难题：
假定A连接点往一个空的表 t1 插进5条数据信息（t1表只有一个主键字段名id）:
insert into t1 (id) value (null); # 实行5次
那麼B连接点也会全自动插进5条数据信息，假定id为1，2，3，4，5；
如今我往B连接点插进一条数据信息
insert into t1 (id) value (null);
这时便会出错说主键反复。
大家查询一下2个主连接点的建表语句中的自增id
show create table t1
发觉A连接点的auto_increment=6
B连接点的auto_increment=1
换句话说B连接点会拷贝A连接点的数据信息却无法复制A连接点的自升值。如果是在mysql 5.7，那麼不会有这个问题，主连接点中间会在同歩数据信息的情况下也同歩自增。
假如版本号小于5.7 那麼能够根据下列方式处理：
设置 A连接点设定自增的步幅为2，自增id从1逐渐
在环境变量中：
auto_increment_increment=2 #步幅
auto_increment_offset=1 #从1逐渐
# 重新启动服务项目
设置 B连接点设定自增的步幅为2，自增id从4开始
在环境变量中：
auto_increment_increment=2 #步幅
auto_increment_offset=2 #从4开始
# 重新启动服务项目
自然，一开始数据信息会为空，从空表逐渐。
这么一来，假如从A的t1表持续插进2条数据信息，他的id是1，3
这时B的t1也是1，3
再在B插进2条数据信息，这时查看表获得1，2，3，4
如果有3个主服务器虚拟机主主拷贝得话，那麼步幅要设定为3，而offset各自为1，2，3
假如3台连接点全是mysql 5.7 版本号的，那麼就无需那么设定。如果有一台是小于5.7版本号的，就需要那么设定。
自然,如果是主从复制是不容易出現这个问题的,由于从连接点只承担读,不承担载入。
PS：因为二进制日志不查询记录句子，因此 对表A查看不容易造成在表B又查看一次，因此 主主拷贝也是能够开展负载均衡的。
下一节将具体步骤主从复制和主主拷贝。
