32主从复制

职责
搭建主从复制，主从原理熟悉，主从的故障处理，主从延迟，主从的特殊架构的配置使用，主从架构的演变

主从复制介绍
主从复制基于binlog来实现的，主从发生新的操作，都会记录binlog，从库取得主库的binlog进行回放，主从复制的过程是异步
主从复制的前提(搭建主从复制)
2个或以上的数据库实例，主库需要开启二进制日志，server_id要不同，区分不同的节点，主库需要建立专用的复制用户(replication slave)，从库应该通过备份主库恢复的方法进行“补课”，人为告诉从库一些复制信息(ip port user pass 二进制起点)，从库应该开启专门的复制线程
主从复制搭建过程(生产)

准备多个实例
pkill mysqld
systemctl start mysqld3307
\rm -rf /data/3308/data/*
\rm -rf /data/3308/mysql-bin.*
mysqld --initialize-insecure --user=mysql --basedir=/application/mysql --datadir=/data/3308/data
systemctl start mysqld3308
mysql -S /data/3308/mysql.sock -e "select @@port";

检查配置文件
主库 二进制日志是否开启

两个节点 server_id
cat /data/3308/my.cnf
cat /data/3307/my.cnf

主库创建复制用户
mysql -uroot -p123 -S /data/3307/mysql.sock -e "grant replication slave on . to repl@'10.0.0.%' identified by '123'"
"补课"

主库备份
mysqldump -uroot -p123 -S /data/3307/mysql.sock -A --master-data=2 --single-transaction -R -E --triggers >/tmp/full.sql

从库
mysql -S /data/3308/mysql.sock
set sql_log_bin=0;
source /tmp/full.sql

告诉从库信息
mysql -S /data/3308/mysql.sock
vim /tmp/full.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000004', MASTER_LOG_POS=444;

从库开启复制线程(IO，SQL)
mysql -S /data/3308/mysql.sock
start slave;

检查主从复制状态
mysql -S /data/3308/mysql.sock
show slave status \G

主库
mysql -uroot -p123 -S /data/3307/mysql.sock -e "create database alexsb"

从库
mysql -S /data/3308/mysql.sock -e "show databases"

主从复制原理
主从复制中涉及的文件
主库 binlog
从库
relaylog 中继日志
master.info 主库信息文件
relaylog.info relaylog应用的信息

主从复制中涉及的线程
主库
Binlog_Dump Thread DUMP_T

从库
SLAVE_IO_THREAD IO_T
SLAVE_SQL_THREAD SQL_T

主从复制工作过程
从库执行change master to命令(主库的连接信息+复制的起点)
从库会将以上信息，记录到master.info文件
从库执行start slave命令，立即开启IO_T和SQL_T
从库IO_T，读取master.info文件中的信息，获取到IP，PORT，User，Pass，binlog的位置信息
从库IO_T请求连接主库，主库专门提供一个DUMP_T，负责和IO_T交互
IO_T根据binlog的位置信息(mysql-bin.000004，444)请求主库新的binlog
主库通过DUMP_T将最新的binlog，通过网络TP给从库IO_T
IO_T接收到新的binlog日志，存储到TCP/IP缓存，立即返回ACK给主库，并更新master.info
IO_T将TCP/IP缓存中数据，转储到磁盘relaylog中
SQL_T读取relay.info中的信息，获取到上次已经应用过的relaylog的位置信息
SQL_T会按照上次的位置点回放最新的relaylog，再次更新relay.info信息
从库会自动purge应用过relay进行定期清理
补充说明 一旦主从复制构建成功，主库当中发生了新的变化，都会通过dump_T发送信号给IO_T，增强了主从复制的实时性

主从复制监控
show slave status \G

主库有关的信息
从库relay应用信息有关的信息
从库线程运行状态
过滤复制有关信息
从库延时主库的时间
延时从库
GTID复制有关状态信息
主从复制故障

从库
IO线程故障
连接主库 网络，连接信息错误或变更了，防火请，连接数上限

排查思路 使用复制用户手工登录
请求binlog binlog没开，binlog损坏或不存在，reset master
存储binlog到relaylog
SQL线程故障
relay-log损坏

研究一条SQL语句为什么执行失败
处理方法 把握一个原则，一切以主库为准进行解决
为了最大程度避免SQL线程故障
从库只读，使用读写分离中间件

主从延时监控及原因
主库方面原因
binlog写入不及时
sync_binlog=1
默认情况下dump_t是串行传输binlog
在并发事务量大时或者大事务，由于dump_t是串行工作的，导致传送日志较慢
必须GTID，使用Group commit方式，可以支持DUMP_T并行
主库及其繁忙 慢语句，锁等待，从库个数较多

从库方面的原因
传统复制中
如果主库并发事务量很大，或者出现大事务
由于从库是单SQL线程，导致不管传的日志有多少，只能一次执行一个事务
5.6版本，有了GTID，可以实现多SQL线程，但是只能基于不同库的事务进行并发回放(database)
5.7版本中，有了增强的GTID，增加了seq_no，增加了新型的并发SQL线程模式(logical_lock)，MTS技术
主从硬件差异太大
主从的参数配置
从库和主库的索引不一致
主从版本有差异
主从延时的监控

主库方面原因的监控
show master status;

从库方面的原因
延时从库
SQL线程延时，数据已经写入relaylog中了，SQL线程"慢点"运行，一般企业建议3-6小时，具体看公司运维人员对于故障的反应时间

延时从库配置
stop slave;
CHANGE MASTER TO MASTER_DELAY=300;
start slave;
show slave status \G

延时从库处理逻辑故障
延时从库的恢复思路
监控到数据库逻辑故障

停从库SQL线程，记录已经回放的位置点(截取日志起点)
stop slave sql_thread;

截取relaylog
show slave status \G
show relaylog events in ''

模拟SQL线程回访日志
恢复业务
就一个库，从库替代主库工作
多个库，从库导出故障库，还原到主库中

故障演练
主库
create database delay charset utf8mb4;
use delay;
create table t1 (id int);
insert into t1 values(1),(2),(3);
commit;
drop database delay;

从库
停止从库SQL线程，截取relay的位置点
stop slave sql_thread;
show slave status \G

找到relay的截取终点
show relaylog events in 'db01-relay-bin.000002';

截取relay
cd /data/3308/data/
mysqlbinlog --start-position=626 --stop-position=1299 db01-relay-bin.000002 >/tmp/relay.sql

恢复relay到从库
mysql -uroot -p -S /data/3308/mysql.sock
set sql_log_bin=0;
source /tmp/relay.sql

过滤复制
快速恢复测试环境

从库
drop database delay;
stop slave;
reset slave all;

主库
reset master;
mysql -S /data/3308/mysql.sock

过滤复制应用
主库
show master status;

从库
show slave status \G

例子
vim /etc/my.cnf
replicate_do_db=repl
systemctl restart mysqld3308

GTID核心参数
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1

gtid-mode=on 启用gtid类型，否则就是普通的复制架构
enforce-gtid-consistency=true 强制GTID的一致性
log-slave-updates=1 更新是否记录日志

GTID复制
GTID是对于一个已提交事务的唯一编号，并且是一个全局(主从复制)唯一的编号
核心特性 全局唯一，具备幂等性

清理环境
pkill mysqld
\rm -rf /data/mysql/data/*
\rm -rf /data/binlog/*

准备配置文件
主库db01
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql/
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=51
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db01 [\dd]>
EOF

slave1
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql/
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=52
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db02 [\dd]>
EOF

slave2
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/application/mysql/
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=53
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db03 [\dd]>
EOF

初始化数据
mysqld --initialize-insecure --user=mysql --basedir=/application/mysql --datadir=/data/mysql/data

启动数据库
/etc/init.d/mysqld strat

构建主从
master:51
slave:52,53

51
grant replication slave on . to repl@'10.0.0.%' identified by '123';

52\53
change master to
master_host='10.0.0.51',
master_user='repl',
master_password='123',
MASTER_AUTO_POSITION=1;
start slave;

GTID复制和普通复制区别
非gtid
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=444,

gtid
MASTER_AUTO_POSITION=1;

在主从复制中，主库发生过事务，在全面局都是由唯一GTID记录，更方便Failover
额外功能参数(3个)
change master to的时候不再需要binlog文件名和position号，MASTER_AUTO_POSITION=1
在复制过程中，从库不再依赖master.info文件，而是直接读取最后一个relaylog的GTID号
mysqldump备份时，默认会将备份中包含的事务操作，以以下方式SET @@GLOBAL.GTID_PURGED='8c49d7ec-7e78-1le8-9638-000c29ca725d:1'，告诉从库，我的备份中已经有以上事务，你就不用运行了，直接从下一个GTID开始请求binlog就行了

半同步
解决主从复制数据一致性问题
ACK 从库relay落地，IO线程会返回一个ACK，主库的ACK_reciver，主库事务才能提交，如果一直ACK没收到，超过10秒钟会切换为异步复制。

MHK高可用
配置关键程序软链接
ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /application/mysql/bin/mysql /usr/bin/mysql

配置互信
db01
rm -rf /root.ssh
ssh-keygen
cd /root/.sh
mv id_rsa.pub authorized_keys
scp -r /root/.ssh 10.0.0.52:/root
scp -r /root/.ssh 10.0.0.53:/root

各节点验证
db01
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date

db02
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date

db03
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date

安装软件包(所有节点)
yum install perl-DBD-MySQL -y
rpm -ivh mha4mysql-node-0.56-0.e16.noarch.rpm

在db01主库中创建mha需要的用户
grant all privileges on . to mha@'10.0.0.%' identified by 'mha';

Manager软件安装(db03)
yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm

配置文件准备(db03)
创建配置文件目录
mkdir -p /etc/mha
创建日志目录
mkdir -p /var/log/mha/app1

编辑mha配置文件
cat /etc/mha/app1.cnf <<EOF
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog
user=mha
password=mha
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root
[server1]
hostname=10.0.0.51
port=3306
EOF

状态检查(db03)
masterha_check_ssh --conf=/etc/mha/app1.cnf 检查互信
masterha_check_repl --conf=/etc/mha/app1.cnf 检查主从状态

开启MHA(db03)
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover </dev/null >/var/log/mha/app1/manager.log 2>&1 &

查看MHA状态
masterha_check_status --conf=/etc/mha/app1.cnf
MHA架构软件结构说明

节点规划
manager端 db03
node端 db01，db02，db03

1主2从，独立数据库实例
MHA软件的构成
Manager工具包主要包括以下几个工具
mha4mysql-manager-0.56-0.el6.noarch.rpm
masterha_manager 启动MHA
masterha_check_ssh 检查MHA的SSH配置状态
masterha_check_repl 检查MySQL复制状态
masterha_master_monitor 检测master是否宕机
masterha_check_status 检测当前MHA运行状态
masterha_master_switch 控制故障转移(自动或者手动)
masterha_conf_host 添加或删除配置的server信息

Node工具包主要包括以下几个工具
这些工具通常由MHA Manager的脚本触发，无需人为操作
save_binary_logs 保存和复制master的二进制日志
apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs 清除中级日志(不会阻塞SQL线程)

FailOver过程 故障转移
主库宕机一直到业务恢复正常的处理过程(自动)
快速监控到主机宕机
选择新主
数据补偿
解除从库身份
剩余从库和新主库构建主从关系
应用透明
故障节点自愈
故障提醒

MHA的Failover实现过程
MHA通过masterha_manger脚本启动MHA的功能
在manager启动之前会自动检查ssh互信和主从状态
MHA-manager通过masterha_master_monitor脚本
masterha_master_monitor探测主库3次五心跳之后就认为主库宕机了

进行选主过程
算法1 读取配置文件是否有强制选主的参数
candidate_master=1
MHA+KeepAlive VIP(早期MHA架构)
多地多中心
check_repl_delay=0

算法2 自动判断所有从库的日志量，将接近主库数据的从库作为新主
算法3 按照配置文件先后顺序的进行选主

数据补偿
判断主库SSH的连通性
情况一：SSH能连
调用save_binary_logs脚本，立即保存缺失部分的binlog到各个从节点，恢复
情况二：SSH无法连接
调用apply_diff_relay_logs脚本，计算从库的relaylog的差异，恢复到2号从库
提供额外的数据补偿的功能(待开发)
解除从库身份
剩余从库和新主库构建主从关系
应用透明(待开发)
故障节点自愈(待开发)
故障提醒(待开发)
MHA应用透明(vip)

db03
cp /root/master_ip_failover.txt /usr/local/bin/master_ip_failover
vim /usr/local/bin/master_ip_failover
my $vip='10.0.0.55/24';
my $key='1';
my $ssh_start_vip="/sbin/ifconfig eth1:$key $vip";
my $ssh_stop_vip="/sbin/ifconfig eth1:$key down";
yum install -y dos2unix
dos2unix /usr/local/bin/master_ip_failover
chmod +x /usr/local/bin/master_ip_failover
vim /etc/mha/app1.cnf
master_ip_failover_script=/usr/local/bin/master_ip_failover

db01
ifconfig eth0:1 10.0.0.55/24 手工添加vip

db03 重启MHA
masterha_stop --conf=/etc/mha/wordpress.cnf
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover </dev/null >/var/log/mha/app1/manager.log 2>&1 &
masterha_check_status --conf=/etc/mha/app1.cnf

MHA故障提醒
cp -r email /usr/local/bin/
cd usr/local/bin/email/
chmod +x *
vim /etc/mha/app1.cnf
report_script=/usr/local/bin/email/send

重启MHA
masterha_stop --conf=/etc/mha/app1.cnf
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover </dev/null >/dev/null >/var/log/mha/app1/manager.log 2>&1 &

额外的数据补偿(binlog_server)
找一台额外的及其，必须要有5.6以上的版本，支持gtid开启，我们直接用的第二个slave(db03)
vim /etc/mha/app1.cnf

[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/mysql/binlog

创建必要目录
mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/*

修改完成后，将主库binlog拉过来(从000001开始拉，之后binlog会自动按顺序过来)
拉取主库binlog日志
cd /data/mysql/binlog 必须进入到自己创建好的目录
mysqlbinlog -R --host=10.0.0.52 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &

拉取日志的起点需要按照目前主库正在使用的binlog为起点
重启MHA-manager
masterha_stop --conf=/etc/mha/app1.cnf
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover </dev/null >/dev/null >/var/log/mha/app1/manager.log 2>&1 &

故障模拟及故障处理
宕掉db01数据库
/etc/init.d/mysqld stop
恢复故障
启动故障节点
/etc/init.d/mysqld start

恢复1主2从(db01)
grep "CHANGE MASTER TO" /var/log/mha/app1/manager
CHANGE MASTER TO MASTER_HOST='10.0.0.52',MASTER_PORT=3306,MASTER_AUTO_POSITION=1,MASTER_USER='repl',MASTER_PASSWORD='123';
start slave;

恢复配置文件(db03)
[server1]
hostname=10.0.0.51
port=3306
[server2]
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=3306
report_script=/usr/local/bin/send

启动mha
nohup masterha_manager --conf=/etc/mha/appl.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null >/var/log/mha/appl/manager.log 2>&1 &
masterha_status --conf=/etc/mha/appl.cnf

恢复binlogserver
cd /data/mysql/binlog
rm -rf /data/mysql/binlog/*
mysqlbinlog -R --host=10.0.0.51 --user=mha --password=mha --password=mha --raw --stop-nerver mysql-bin.000001 &

MHA的故障排查
搭建过程中排查

检查脚本
masterha_check_ssh --conf=/etc/mha/appl.cnf
masterha_check_repl --conf=/etc/mha/appl.cnf

1主2从复制环境
配置节点
节点地址，端口
vip和send脚本指定位置和权限
软连接
切换过程的问题
查看/etc/log/mha/appl
脚本问题比较多一些
恢复MHA故障
检查各个节点是否启动
找到主库是谁

恢复1主2从
CHANGE MASTER TO MASTER_HOST='10.0.0.51',MASTER_PORT=3306,MASTER_AUTO_POSITION=1,MASTER_USER='repl',MASTER_PASSWORD='123';
检查配置文件，恢复节点信息
[server1]
hostname=10.0.0.51
port=3306
[server2]
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=3306

检查vip和binlogserver
检查vip是否在主库，如果不在，手工调整到主库
重新启动binlogserver 拉取
mysqlbinlog -R --host=10.0.0.51 --user=mha --password=mha --raw --stop-nerver mysql-bin.000001 &
启动Mananer
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover </dev/null >/dev/null >/var/log/mha/app1/manager.log 2>&1 &

MHA配合Atlas实现读写分离
Atlas，Web平台部基础架构团队开发维护的一个基于SQL协议的数据中间层项目
Atlas只能安装运行在64位的系统上，Centos5.X安装Atlas-XX.e15.x86_64.rpm，Centos6.X安装Atlas-XX.e16.x86_64.rpm，后端mysql版本应大于5.1，建议使用Mysql5.6以上

安装配置
yum install -y Atlas*
cd /usr/local/mysql-proxy/conf
mv test.cnf test.cnf.bak
vim test.cnf
[mysql-proxy]
admin-username=user
admin-password=pwd
proxy-backend-addresses=10.0.0.55:3306
proxy-read-only-backend-addresses=10.0.0.51:3306,10.0.0.53:3306
pwds=repl:3yb5jEku5h4=,mha:O2jBXONX098=
daemon=true
keepalive=true
event-threads=8
log-level=message
log-path=/usr/local/mysql-proxy/log
sql-log=ON
proxy-address=0.0.0.0:33060
admin-address=0.0.0.0:2345
charset=utf8

启动atlas
/usr/local/mysql-proxy/bin/mysql-proxyd test start
ps -ef | grep proxy

Atlas功能测试
测试读操作
mysql -umha -pmha -h 10.0.0.53 -p 33060
db03 [(none)] >select @@server_id;

测试写操作
begin;select @@server_id;commit;

生产用户要求
开发人员申请一个应用用户app( select update insert) 密码123456，要通过10 网段登录
在主库中创建用户
grant select,update,insert on . to app@'10.0.0.%' identified by '123456';

在atlas中添加生产用户
/usr/local/mysql-proxy/bin/encrypt 123456 制作加密密码
vim test .cnf
/usr/local/mysql-proxy/bin/mysql-proxyd test restart
mysql -uapp -p1223456 -h 10.0.0.53 -P 33060

Atlas基本管理
连接管理接口
mysql -uuser -ppwd -h127.0.0.1 -P2345
select * from help;
select * from backends;
set offline 2;
set online 2;
remove backend 3;
add slave 10.0.0.53:3306
add pwd oldguo:123456;
save config;
grant all on . to oldguo@'10.0.0.%' identified by '123456';

MyCAT基础架构准备
环境准备
两台虚拟机 db01 db02
两台创建4个mysql实例 3307 3308 3309 3310

删除历史环境
pkill mysqld
rm -rf /data/330*
mv /etc/my.cnf /etc/my.cnf.bak

创建相关目录初始化数据
mkdir /data/33{07..10}/data -p
mysqld --initialize-insecure --user=mysql --datadir=/data/3307/data --basedir=/app/mysql
mysqld --initialize-insecure --user=mysql --datadir=/data/3308/data --basedir=/app/mysql
mysqld --initialize-insecure --user=mysql --datadir=/data/3309/data --basedir=/app/mysql
mysqld --initialize-insecure --user=mysql --datadir=/data/3310/data --basedir=/app/mysql

准备配置文件和启动脚本
db01
db02

修改权限，启动多实例
chown -R mysql.mysql /data/*
systemctl start mysqld3307
systemctl start mysqld3308
systemctl start mysqld3309
systemctl start mysqld3310
mysql -S /data/3307/mysql.sock -e "show variables like 'server_id'"
mysql -S /data/3308/mysql.sock -e "show variables like 'server_id'"
mysql -S /data/3309/mysql.sock -e "show variables like 'server_id'"
mysql -S /data/3310/mysql.sock -e "show variables like 'server_id'"

节点主从规划

箭头指向谁是主库
10.0.0.51:3307 <----> 10.0.0.52:3307
10.0.0.51:3309 ----> 10.0.0.51:3307
10.0.0.52:3309 ----> 10.0.0.52:3307
10.0.0.52:3308 <----> 10.0.0.51:3308
10.0.0.52:3310 ----> 10.0.0.52:3308
10.0.0.51:3310 ----> 10.0.0.51:3308

分片规划
shard1
Master:10.0.0.51:3307
slave1:10.0.0.51:3309
Standby Master:10.0.0.52:3307
slave2:10.0.0.52:3309

shard2:
Master:10.0.0.52:3308
slave1:10.0.0.52:3310
Standby Master:10.0.0.51:3308
slave2:10.0.0.51:3310

开始配置
shard1
10.0.0.51:3307 <----> 10.0.0.52:3307
10.0.0.51:3309 ----> 10.0.0.51:3307
10.0.0.52:3309 ----> 10.0.0.52:3307

shard2
10.0.0.52:3308 <----> 10.0.0.51:3308
10.0.0.52:3310 ----> 10.0.0.52:3308
10.0.0.51:3310 ----> 10.0.0.51:3308

检测主从状态
mysql -S /data/3307/mysql.sock -e "show slave status\G" | grep Yes
mysql -S /data/3308/mysql.sock -e "show slave status\G" | grep Yes
mysql -S /data/3309/mysql.sock -e "show slave status\G" | grep Yes
mysql -S /data/3310/mysql.sock -e "show slave status\G" | grep Yes

MyCAT安装
预先安装Java运行环境
yum install -y java

下载
Mycat-server-xxxxx.linux.tar.gz
http://dl.mycat.io/

解压文件
tar xf Mycat-server-1.6.7.1-release-20190627191042-linux.tar.gz

软件目录结构
ls
bin catlet conf lib logs version.txt
启动连接
配置环境变量
vim /etc/profile
export PATH=/application/mycat/bin:$PATH
source /etc/profile

启动
mycat start
连接mycat
mysql -uroot -p123456 -h 127.0.0.1 -P8066

数据库分布式架构方式
垂直拆分
水平拆分
范围 取模 枚举 哈希 时间等

Mcat应用
主要配置文件介绍
rule.xml 分片策略定义
schema.xml 主配置文件
server.xml mycat服务有关
log4j2.xml 记录日志有关

用户创建及数据库导入
db01:
mysql -S /data/3307/mysql.sock
grant all on . to root@'10.0.0.%' identified by '123';
source /root/world.sql
mysql -S /data/3308/mysql.sock
grant all on . to root@'10.0.0.%' identified by '123';
source /root/world.sql

配置文件结构介绍
cd /application/mycat/conf
vim schema.xml

逻辑库定义，数据节点定义，后端主机定义
mycat实现1主1从读写分离
vim schema.xml
mycat实现读写分离
vim schema

配置中的属性介绍
balance属性 负载均衡类型
balance="0" 不开启读写分离机制，所有读操作都发送到当前可用的writeHost上
balance="1" 全部的readHost与standby writeHost参与select语句的负载均衡，简单的说，当双主双从模式(M1->S1,M2->S2，并且M1与M2互为主备)，正常情况下，M2，S1，S2都参与select语句的负载均衡
balance="2" 所有读操作都随机的在writeHost，readhost上分发

writeType属性 负载均衡类型
writeType="0" 所有写操作发送到配置的第一个writeHost，第一个挂了切到还生存的第二个writeHost，重新启动后已切换后的为主，切换记录在配置文件中，dnindex.properties
writeType="1" 所有写操作都随机的发送到配置的writeHost，但不推荐使用

switchType属性
默认值1，自动切换
2 基于MySQL主从同步的状态决定是否切换，心跳语句为show slave status

datahost其他配置
maxCon=’1000“ 最大并发连接数
minCon="10" mycat在启动之后，会在后端节点上自动开启的连接线程
tempReadHostAvailabe="1" 这个1主1从时(1个writehost,1个readhost时)，可以开启这个参数

mycat高级应用 分布式解决方案
垂直分表，范围分片，取模分片，枚举分片