第二十六课堂笔记

 

3、MYCAT的主要作用是什么？

    数据库中间层是位于前端应用和后端数据库之间的一个层。

1. 传统Java项目使用数据库连接池的形式连接数据库，这样多个项目连接同一个数据库，冗余的连接会随着项目的增加而出现线性增长，这不利于数据库连接数量的控制，但是当使用中间层之后，前端应用统一通过中间层获取连接，将不用自己维护连接池，可避免连接数不断增加的问题。
2. 数据库中间层还可以屏蔽后端数据库的一些变更，使前台应用不受影响，例如对数据库进行了水平或者垂直切分。
3. MYCAT原生实现了对MySQL的支持，也可以通过jdbc形式连接其它关系型数据库 如 Oracle，Sqlserver，也可以连接非关系型数据库 如 mongodb，这个功能其他同类型产品没有。
4. 可实现数据库的读写分离，在后端的主从复制数据库集群中，通过MYCAT配置，将前台的写操作路由到主数据库中，将读操作路由到从数据库上。
5. MYCAT可以实现读写分离下的读操作负载均衡，将大量的读操作均衡到不同的从库上，主要出现在一主多从情形下。
6. MYCAT可实现数据库的高可用，在数据库主节点可用的情况下，配置一台可写从节点，这两个节点都配置在MYCAT中，当主节点宕机时，MyCAT会自动将写操作路由到备用节点上，但并不支持在切换之后的继续主从同步。
7. 当读写分离已经不能满足持续增加的访问量时，MYCAT可实现数据库的垂直拆分，将所有的数据库表按照模块划分，不同类型的表拆分到不同的数据库服务器。
8. 随着业务量的增长，垂直拆分之后如果又出现了数据库性能问题，则需要进行水平切分，这就是俗称的分库分表。将数据量很大的表数据切分到不同的服务器库中，表结构是一样的，而使用MYCAT实现水平切分，对前端应用是完全透明的，不用调整前台逻辑。

4、MYCAT使用场景

        当业务系统的读写操作都在一台数据库，数据库出现了性能问题，而且对数据库的所有操作中读负载明显高于写负载时，此时应使用MYCAT读写分离方案。

        当数据表数据量达到1000万以后，所有的优化操作都已经用完了，此时应使用MYCAT的分库分表功能。

        在统计报表系统中，也可以使用MYCAT加速数据的统计分析。

        MYCAT还可以使用在需要同时查询多种数据库的场景，MYCAT支持通过JDBC连接到不同类型的数据库。

5、MYCAT的优势

         MYCAT是基于阿里巴巴Cobar进行开发，经历了Alibaba大数据业务的考验。

         MYCAT是基于Java进行开发，开源免费，资料文档相对容易找到，跨平台移植更方便。

         MYCAT社区活跃，使用人数多，说明功能相对稳定。

         支持多种关系型和非关系性数据库。

6、MYCAT 其他概念

        逻辑库，逻辑库是存在于MYCAT中的一个数据库定义，相当于后端数据库分片之后的一个集合视图，前端应用只需要关注逻辑库而并不需要关注它的分片结构，MYCAT会保存逻辑库的定义，而不会保存逻辑库数据，同理的概念还有逻辑表，数据库表进行水平切分后分布在不同的服务器中，前端应用只需要对逻辑表进行操作。

         ER关系分片策略，在进行数据库表的垂直切分时，MYCAT可按照ER关系，将相互关联的表切分到相同的数据库中，提升查询效率。

         全局序列号，数据库分片之后，相同的表可能产生相同的ID，全局序列号可是提供跨分片的序列号。

公司里有两个mysql服务器做主从同步，某天Nagios发来报警短信，mysqla is down...赶紧联系机房，机房的人反馈来的信息是 HARDWARE ERROR 后面信息省略，让机房记下错误信息后让他们帮忙重启下看是不是能正常起来，结果竟然正常起来了，赶紧导出所有数据。
   问题又出现了，nagios 又报警，mysql_AB error，检查从库
show slave status \G; 果然 
Slave_IO_Running: Yes
Slave_SQL_Running: No
而且出现了1062错误，还提示 
Last_SQL_Error: Error 'Duplicate entry '1001-164761-0' for key 'PRIMARY'' on query. Default database: 'bug'. Query: 'insert into misdata (uid,mid,pid,state,mtime) values (164761,1001,0,-1,1262623560)'
很显然，由于主库重启导致 从库数据不同步而且主键冲突。查看error 日志发现error日志文件变得好大，比以前大了将近好几倍，
tail -f mysql_error.log 最开始查看到的是这条信息
发现这条信息
 [ERROR] Slave SQL: Error 'Duplicate entry '1007-443786-0' for key 'PRIMARY'' on query. Default database: 'ufo'. Query: 'insert into misdata (uid,mid,pid,sta
te,mtime) values (443786,1007,0,-1,1262598003)', Error_code: 1062
100104 17:39:05 [Warning] Slave: Duplicate entry '1007-443786-0' for key 'PRIMARY' Error_code: 1062
100104 17:39:05 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'ufolog.000058
8' position 55793296
报错和上面的意思差不多，

最先想到的就是首先手动同步一下，从库上首先 stop slave;停止同步
进入主库锁表，
FLUSH TABLES WITH READ LOCK；
mysql> show master status;
+-------------------+-----------+--------------+------------------+
| File              | Position  | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+-----------+--------------+------------------+
| ufo.000063 | 159164526 |              |                  |
+-------------------+-----------+--------------+------------------+
1 row in set (0.00 sec)
进入从库
mysql>change master to master_host='192.168.1.141', master_user='slave', 
master_password='xxx', 
master_port=3306, 
master_log_file='ufo.000063', 
master_log_pos=159164526;

完成上面这些后
start slave;
回到主库
unlock tables; 解锁

回到从库 查看
show slave status \G;
发现正常了，长处了一口气。可是还没过一分钟，发现又开始报错了，还是最开始那个错误，这是怎么回事...
于是又想到了跳过错误的办法，（不过我不太喜欢用这种方法）马上进入从库
stop slave; 
set global sql_slave_skip_counter=1; （1是指跳过一个错误）
slave start;
再show slave status \G;查看
还是报错 只不过 原来的 164761 变成了 165881，连续执行了几次后
除了上面的数值 在变，错误依然还在
郁闷了，看来只能先强制跳过 1062错误了，于是修改从库的/etc/my.cnf文件
在里面的[mysqld]下面加入了一行
slave-skip-errors = 1062 (忽略所有的1062错误)
重启下从库的mysql /etc/init.d/mysqld restart
再 show slave status \G;一下发现正常了，但是我知道这时的数据可能已经不同步了，
再次查看一下日志，让我感到意外的是tail -f mysql_error.log 出现大量的
.......
100106 16:54:21 [Warning] Statement may not be safe to log in statement format. Statement: delete from `system_message_1` where `to_uid` = 181464 ORDER BY `id` ASC LIMIT 1
.........
日志里面有大量的这种警告，意思应该是statement 格式不安全，用vim 打开他看了一下，发现好多这类警告，我说为什么错误日志怎么变这么大了呢！！
statement format 应该是 binlog的一种格式，进入从库查看一下
show global variables like 'binlog_format';
果然当前的格式为statement 

我需要把格式改为 mixed格式
修改从库的 my.cfg
在[mysqld]下面加入下面这行
binlog_format=mixed

然后重启mysql服务，发现错误日志里的 警告 都停止了。这回清静多了~~

我突然想起一件事，记得有朋友说过 RBR 模式可以解决很多因为主键冲突导致的主从无法同步情况，想到这里我就想要不要把 slave-skip-errors = 1062 去掉再试试，
于是就进入到my.cnf 里在注释掉了 slave-skip-errors = 1062
再次重新启动 mysql服务
进入从库
show slave status \G;
.........               
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
........

恢复了！！！有观察了一段时间没有出现问题这才放心，

看来导致 mysql 主从复制出错的原因还真不少修复的办法也不止一个，binlog的格式也是其中之一。
希望遇到和这次一样问题的朋友看到这篇文章后会得到 一些启发和解决问题的方法~~