mycat

mycat事务超时

谁说我不能喝 提交于 2019-12-01 15:23:18
问题 项目里面使用的是 mycat 进行分库分表,但在最近一个系统更新后出现数据库事务锁超时的问题,如下面的错误: 1 Caused by: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction 分析 先在网上搜索了一下之后,发现大多数说的都不是什么好的解决方案,手动kill掉事务,把事务超时时间加长,这些对我现在这个项目都不实际,还是自己分析吧。 对数据库的配置检查了一番,没什么问题,并没有什么更新,然后就对程序进行分析,这个错误是在一次系统更新后才出现的,对这次更新进行了分析,发现频繁超时的那个更新操作去掉了一个分片id参数,比如之前是这样: 1 update update_date = now() where xxx_id = 123 and sharding_id = 23; 这次更新后的操作就是这样子了: 1 update update_date = now() where xxx_id = 123; 分析了一下这个操作, xxx_id 只是一个普通的字段,然而这个操作会锁住所有分片下的表,而加了分片id之后只是锁住了指定分片的那张表。我们使用的是MySQL innoDB引擎,所以,把这个操作变成行锁就好了。 解决方案 MySQL innoDB引擎行锁是建立在索引上的

MyCat数据库的基础配置及使用

假如想象 提交于 2019-12-01 14:45:32
一、为什么需要分布式数据据库 随着计算机和信息技术的迅猛发展,行业应用系统的规模迅速扩大,行业应用所产生的数据量呈爆炸式增长,动辄达到数百TB甚至数百PB的规模,已远远超出传统计算技术和信息系统的处理能力,集中式数据库面对大规模数据处理逐渐表现出其局限性。因此,人们希望寻找一种能快速处理数据和及时响应用户访问的方法,也希望对数据进行集中分析、管理和维护。这已经成为迫切需求。 分布式数据库是在集中式数据库的基础上发展起来的,是计算机技术和网络技术结合的产物。分布式数据库是指数据在物理上分布而在逻辑上集中管理的数据库系统。物理上分布是指数据分布在物理位置不同并由网络连接的节点或站点上;逻辑上集中是指各数据库节点之间的逻辑上是一个整体,并由统一的数据库管理系统管理。不同的节点分布可以跨不同的机房、城市甚至国家。 二、分布式数据库的特点 分布式数据库具有透明性、数据冗余性、易于扩展性、自治性等特点,还具有经济、性能优越、响应速度更快、灵活的体系结构、易于集成现有系统等特点。 分布式数据库尽管有着天生的高贵血统,但它依赖调整网络,对事务的处理远没有传统数据库成熟,在很长一段时间内分布式数据存储将与传统数据存储共存。 三、MyCat数据库中间件简介 MyCat是一个彻底开源的面向企业应用开发的大数据库集群,支持事务、ACID,是可以替代MySQL的加强版数据库

MySQL 数据库中间件 MyCAT 基础解析

删除回忆录丶 提交于 2019-12-01 14:45:18
前言 网络应用持续扩张的过程中,为了处理海量数据往往首先遇到的挑战就是数据存储的扩展 数据存储的扩展一般以切分来实现,切分的技术实现又可分为垂直切分和水平切分: 以表(或Schema)为切分粒度的是垂直切分 以表内行为切分粒度的是水平切分 初期扩展使用垂直切分就可以基本解决问题,垂直切分也相对简单,但随着数据行成量级的持续增长,针对这张表的各层面操作性能都会显著降低,此时就不得不进行水平切分了,水平切分就要复杂很多 为了应对此类挑战,就产生了一类新的数据库 NoSQL (Not Only SQL) ,此类的代表有 MongoDB、Redis、Memcached、Elasticsearch ,这类数据库可以轻松应对数据库的扩展(不论是水平还是垂直切分都非常高效),在海量数据的情况下,也能有着极佳的读写性能,NoSQL的根本优势就在于大数据时代易于进行大规模分布式扩展 但是由于NoSQL固有的分布式架构,目前对事务的支持非常弱,存储也是弱结构的,join等复杂操作能力很差,应用场景比较局限 数据库弱了,就意味着,如果要实现一样的特性,应用层面的设计得更复杂才能弥补,这也无形地引入了架构风险 为了使用到关系模型的一些特性(交易或支付的场景,前几年非常火热的去IOE),还是绕不过关系型数据库,但是关系型数据库先天就对分布式支持很弱 简单点可以这么理解: 事务性就是序列化,高并发就是分布式

基于mycat实现读写分离

一个人想着一个人 提交于 2019-12-01 13:33:44
Mycat 概述 在MySQL中间件出现之前,对于MySQL主从集群,如果要实现其读写分离,一般是在程序端实现,这样就带来一个问题,即数据库和程序的耦合度太高,如果我数据库的地址发生改变了,那么我程序端也要进行相应的修改,如果数据库不小心挂掉了,则同时也意味着程序的不可用,而这对很多应用来说,并不能接受。 引入MySQL中间件能很好的对程序端和数据库进行解耦,这样,程序端只需关注数据库中间件的地址,而无需知晓底层数据库是如何提供服务。 作为当前炙手可热的MySQL中间件,MyCAT实现MySQL主从集群的读写分离自是应有之义,其配置也相当简单。 在这里,我用三个实例组成MySQL主从集群,来验证MyCAT的读写分离功能,其实,一主一从就可以满足,之所以用三个,是为了验证MyCAT的分片功能。 集群组成如下: 角色 主机名 主机IP master server1 192.168.200.112 slave server2 192.168.200.113 slave server3 192.168.200.114 在 server1 上安装 jdk 和 mycat 安装Java环境(mycat基于java) yum install java-1.8.0-openjdk.x86_64 下载mycat wget http://dl.mycat.io/1.6.5/Mycat-server-1

MySQL基于Mycat实现读写分离

末鹿安然 提交于 2019-12-01 12:35:33
基于 Mycat实现读写分离 环境: mariadb主:192.168.200.129 Mariadb从 : 192.168.200.114 Mycat : 192.168.200.112 (1) 安装 jdk,先查看本机是否有jdk,由于Mycat是基于Java语言来编写的,所以需要安装JDK,版本为1.8即可。没有的话安装一下然后配置环境变量 [root@ns2 ~]# ls jdk-8u191-linux-x64.tar.gz [root@ns2 ~]# tar xf jdk-8u191-linux-x64.tar.gz //解压 [root@ns2 ~]# mv jdk1.8.0_191 /usr/local/java // 我把它移动到了 /usr/local 下起名叫 java [root@ns2 ~]# vim /etc/profile //配置环境变量 [root@ns2 ~]# source /etc/profile //声明一下 [root@ns2 ~]# java -version java version "1.8.0_191" Java(TM) SE Runtime Environment (build 1.8.0_191-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed

Mariadb 基于Mycat实现读写分离

别说谁变了你拦得住时间么 提交于 2019-12-01 12:30:03
环境:Mariadb主:192.168.200.129 Mariadb从:192.168.200.114 Mycat :192.168.200.112 (1) 安装jdk,先查看本机是否有jdk,由于Mycat是基于Java语言来编写的,所以需要安装JDK,版本为1.8即可。没有的话安装一下然后配置环境变量 [root@ns2 ~]# ls jdk-8u191-linux-x64.tar.gz [root@ns2 ~]# tar xf jdk-8u191-linux-x64.tar.gz //解压 [root@ns2 ~]# mv jdk1.8.0_191 /usr/local/java //我把它移动到了/usr/local下起名叫java [root@ns2 ~]# vim /etc/profile //配置环境变量 [root@ns2 ~]# source /etc/profile //声明一下 [root@ns2 ~]# java -version java version "1.8.0_191" Java(TM) SE Runtime Environment (build 1.8.0_191-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) (2)安装部署mycat

mycat 多库分表 单库分表(根据uuid)

扶醉桌前 提交于 2019-12-01 11:57:47
多 库 分 表 rule.xml: <mycat:rule xmlns:mycat="http://io.mycat/"> <tableRule name="test"> <rule> <columns>projectid</columns> <algorithm>test</algorithm> </rule> </tableRule> <tableRule name="rule1"> <rule> <columns>projectid</columns> <algorithm>func1</algorithm> </rule> </tableRule> <tableRule name="jump-consistent-hash"> <rule> <columns>projectid</columns> <algorithm>jump-consistent-hash</algorithm> </rule> </tableRule> <function name="jump-consistent-hash" class="io.mycat.route.function.PartitionByJumpConsistentHash"> <property name="totalBuckets">3</property> </function> <function name="func1

MyCAT详解【转】

纵然是瞬间 提交于 2019-12-01 08:59:10
原文链接: MyCAT详解 作者: Rangle 一、MyCAT概述 MyCAT是一款由阿里Cobar演变而来的用于支持数据库读写分离、分片的分布式中间件。MyCAT可不但支持Oracle、MSSQL、MYSQL、PG、DB2关系型数据库,同时也支持MongoDB等非关系型数据库。基础架构如下: 1、MyCAT原理 MyCAT主要是通过对SQL的拦截,然后经过一定规则的分片解析、路由分析、读写分离分析、缓存分析等,然后将SQL发给后端真实的数据块,并将返回的结果做适当处理返回给客户端。 2、MyCAT功能 (1)数据库分片(Sharding) 通过某种条件,将同一数据库中的数据分散的存储到多个数据库中,已达到分散单台数据库设备负载的效果,这就是数据库分片。 a.水平拆分 同一张表的不同记录,根据表的某个字段的某种规则拆分到多个数据库(主机)上,这既是水平拆分。 单库业务表可能会过于庞大,存在单库读写与存储瓶颈,这种情况可以通过水平拆分解决,水平拆分基本架构如下: 常用水平拆分规则: *ID *日期 *特定字段取模 优点: *拆分规则抽象好,join操作基本可以数据库内完成 *不存在单库大数据,高并发的性能瓶颈 *应用端改造少 *提高了系统稳定性和负载能力 缺点: *拆分规则难以抽象 *分片事务一致性难以解决 *数据多次扩展难度跟维护量极大 *跨库join性能较差 b.垂直拆分

重磅预告 | 今晚直播:MyCat的坑如何在分布式中间件DBLE上改善

橙三吉。 提交于 2019-11-30 20:44:26
上周,DBLE团队历时3个月准备的 开源MySQL分布式中间件DBLE系列公开课发布了 ,为使社区同学能够更好的评估课程内容、质量以及对DBLE有更清晰深入的认知,我们联合IT168将在第二节课程发布前开放一期直播,跟大家聊聊DBLE与MyCat错综复杂的故事。 直播时间: 3月14日(今晚)20:00PM 分享嘉宾: DBLE项目负责人 蓝寅 分享主题: 《MyCat的坑如何在分布式中间件DBLE上改善》 课程亮点 跟你分享MyCat不为人知的一面 线上的复杂查询其实结果不对? 被MyCat默默吃掉的那些SQL! MyCat不太支持的那些语法! 不严谨代码导致的那些bug! 内容简介 分享将从DBA与研发两个角度进行说明 ,对于DBA同学最关心的SQL语言实现以及运维管理应当如何评估;开发者同学十分关注的bug修复质量,代码质量及代码科学管理如何判断 ,通过拆解两方对中间件的需求来吐槽MyCat到底有多少坑以及DBLE是如何避免的,为大家在MySQL的“读写分离”、“分库分表”等架构选型方面提供指引。 课程提纲 一.DBA角度 1. SQL语言实现 数据查询: 简单查询 / 聚合函数查询 / 函数嵌套查询 / union 查询 / 子查询 / Join查询 / 跨表Join查询 数据操作:Insert / 全局序列 上下文设置:上下文变量 2. 运维管理 用户权限:管理端用户权限

[缺陷分析]半同步下多从库复制异常

孤街浪徒 提交于 2019-11-30 15:04:47
引 言 本文是由爱可生研发团队出品的「 图解MySQL 」系列文章,不定期更新,但篇篇精品。 爱可生开源社区 持续运营维护的小目标: 每周至少推送一篇高质量技术文章 每月研发团队发布开源组件新版 每年1024开源一款企业级组件 2019年至少25场社区活动 欢迎大家持续关注~ 本文分析的缺陷是MySQL bug#89370,其主要的现象是:配置半同步(复制)到多个从库,部分从库在一段时间内无法复制数据,但所有复制状态均正常。 缺陷的复现 MySQL 版本:5.7.16,5.7.17,5.7.21 配置半同步一个master两个slave,设置master的 rpl_semi_sync_master_wait_for_slave_count=2,保持一定数据压力 检查master的 rpl_semi_sync_master_status状态为ON,确保半同步没有退化为异步 设置master的 rpl_semi_sync_master_wait_for_slave_count=1 重启一个slave “stop slave; start slave” 可以观察到步骤4中重启的那个slave长达数分钟不会有master的复制数据流入,但查看复制状态均正常。 缺陷的原理图解 图一:描述了半同步复制的大致流程 上图中按序解析了MySQL半同步插件在binlog group