小城我家

Mycat事务Mycat 数据库事务Mycat 目前没有出来跨分片的事务强一致性支持，单库内部可以保证事务的完整性，如果跨库事务，在执行的时候任何分片出错，可以保证所有分片回滚，但是一旦应用发起 commit 指令，无法保证所有分片都成功，考虑到某个分片挂的可能性不大所以称为弱 XAXA 事务使用Mycat 从 1.6.5 版本开始支持标准 XA 分布式事务，考虑到 MySQL 5.7 之前版本XA有bug，所以推荐最佳搭配 XA 功能使用 MySQL 5.7 版本。Mycat 实现 XA 标准

schema.xml 作为 Mycat 中重要的配置文件之一，管理着 Mycat 的逻辑库、表、分片节点、主机等信息<?xml version="1.0"?><!DOCTYPE mycat:schema SYSTEM "schema.dtd"><mycat:schema xmlns:mycat="http://io.mycat/"> <schema name="TESTDB" checkSQLschema="true" sqlMaxLimit="100

server.xml几乎保存了所有 mycat 需要的系统配置信息user标签这个标签主要用于定义登录 mycat 的用户和权限。例如下面的例子中，我们定义了一个用户，用户名为 user、密码也为 user，可访问的 schema为lg_edu_order。 <user name="user"> <property name="password">user</property> <property name="schemas">TESTDB&

分布式事务理论CAP（强一致性）CAP 定理，又被叫作布鲁尔定理。对于共享数据系统，最多只能同时拥有CAP其中的两个，任意两个都有其适应的场景BASE（最终一致性）BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ EventualConsistency）。它的核心思想是即使无法做到强一致性（CAP 就是强一致性），但应用可以采适合的方式达到最终一致性BA指的是基本业务可用性，支持分区失败；S表示柔性状态，也就是允许短时间内不同步

安装一台虚拟机并安装mysql用户名密码 root/root克隆3台出来192.168.181.135 -master192.168.181.134 -slave1192.168.181.133-slave2192.168.181.132-mha 停止mysql systemctl stop mysqldip用途192.168.181.132MHA管理节点192.168.181.133slave2192.168.181.134slave1192.16

分库分表概述互联网系统需要处理大量用户的请求。比如微信日活用户破10亿，海量的用户每天产生海量的数量；美团外卖，每天都是几千万的订单，那这些系统的用户表、订单表、交易流水表等是如何处理呢？数据量只增不减，历史数据又必须要留存，非常容易成为性能的瓶颈，而要解决这样的数据库瓶颈问题，“读写分离”和缓存往往都不合适，目前比较普遍的方案就是使用NoSQL/NewSQL或者采用分库分表。使用分库分表时，主要有垂直拆分和水平拆分两种拆分模式，都属于物理空间的拆分。分库分表方案：只分库、只分表、分库又分表。垂直

搭建一个主从添加链接描述添加一台新的服务修改原来的master中的my.cnf# endable binloglog_bin=mysql-binserver-id=1sync-binlog=1# 哪些库同步不步不设置就全步binlog-ignore-db=information_schemabinlog-ignore-db=mysqlbinlog-ignore-db=performance_schemabinlog-ignore-db=sys# 同步的库# binlog-db-

mysql-双主模式

下载https://downloads.mysql.com/archives/proxy/上传服务器修改角本sudo vim /usr/local/mysql-proxy/mysql-proxy-0.8.5-linux-el6-x86-64bit/share/doc/mysql-proxy/rw-splitting.lua将min_idle_connections = 4, 改为1创建配置文件 任何地方都可以sudo vim /etc/mysql-proxy.cnf内容[my

准备2个机器分别都安装好mysqlhttps://blog.youkuaiyun.com/ko0491/article/details/108513400防火墙基本操作命令https://blog.youkuaiyun.com/ko0491/article/details/107374919关闭防火墙-同时禁止开机启动[root@localhost ~]# systemctl stop iptables;Failed to stop iptables.service: Unit iptables.service no

sudo wget https://repo.mysql.com//mysql-community-release-el7-7.noarch.rpmrpm -ivh mysql-community-release-el7-7.noarch.rpm查看仓库yum repolist enabled | grep mysql安装yum install mysql-community-server

mysql-主从模式mysql-集群概述可用性设计站点高可用，冗余站点服务高可用，冗余服务数据高可用，冗余数据保证高可用的方法是冗余。但是数据冗余带来的问题是数据一致性问题实现高可用的方案有以下几种架构模式：主从模式简单灵活，能满足多种需求。比较主流的用法，但是写操作高可用需要自行处理。双主模式互为主从，有双主双写、双主单写两种方式，建议使用双主单写扩展性设计扩展性主要围绕着读操作扩展和写操作扩展展开。如何扩展以提高读性能加从库简单易操作，方案成熟。从库过多会

Mysql 锁机制在 MySQL中锁有很多不同的分类。从操作的粒度可分为表级锁、行级锁和页级锁*表级锁：每次操作锁住整张表。锁定粒度大，发生锁冲突的概率最高，并发度最低。应用在MyISAM、InnoDB、BDB 等存储引擎中。行级锁：每次操作锁住一行数据。锁定粒度最小，发生锁冲突的概率最低，并发度最高。应用在InnoDB 存储引擎中。页级锁：每次锁定相邻的一组记录，锁定粒度界于表锁和行锁之间，开销和加锁时间界于表锁和行锁之间，并发度一般。应用在BDB 存储引擎中从操作的类型可分为读锁和写锁

事务隔离级别隔离级别类型前面提到的“更新丢失”、”脏读”、“不可重复读”和“幻读”等并发事务问题，其实都是数据库一致性问题，为了解决这些问题，MySQL数据库是通过事务隔离级别来解决的，数据库系统提供了以下 4 种事务隔离级别供用户选择。读未提交Read Uncommitted 读未提交：解决了回滚覆盖类型的更新丢失，但可能发生脏读现象，也就是可能读取到其他会话中未提交事务修改的数据。读已提交读Read Committed 读已提交：只能读取到其他会话中已经提交的数据，解决了脏读。但可能发

MVCC多版本控制MVCC，也就是Copy on Write的思想。MVCC除了支持读和读并行，还支持读和写、写和读的并行，但为了保证一致性，写和写是无法并行的。在事务1开始写操作的时候会copy一个记录的副本，其他事务读操作会读取这个记录副本，因此不会影响其他事务对此记录的读取，实现写和读并行。一、MVCC概念MVCC（Multi Version Concurrency Control）被称为多版本控制，是指在数据库中为了实现高并发的数据访问，对数据进行多版本处理，并通过事务的可见性来保证事务

MySQL事务和锁ACID 特性在关系型数据库管理系统中，一个逻辑工作单元要成为事务，必须满足这 4 个特性，即所谓的 ACID：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性(Durability）。原子性原子性：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。修改—》Buffer Pool修改—》刷盘。可能会有下面两种情况：事务提交了，如果此时Buffer Pool的脏页没有刷盘，如何保证修改的数据生效？ Red

索引类型索引可以提升查询速度，会影响where查询，以及order by排序。MySQL索引类型如下：从索引存储结构划分：B Tree索引、Hash索引、FULLTEXT全文索引、R Tree索引从应用层次划分：普通索引、唯一索引、主键索引、复合索引从索引键值类型划分：主键索引、辅助索引（二级索引）从数据存储和索引键值逻辑关系划分：聚集索引（聚簇索引）非聚集索引（非聚簇索引）普通索引这是最基本的索引类型，基于普通字段建立的索引，没有任何限制。创建普通索引的方法如下：CREATE IND

Undo Log介绍Undo：意为撤销或取消，以撤销操作为目的，返回指定某个状态的操作Undo Log：数据库事务开始之前，会将要修改的记录存放到 Undo 日志里，当事务回滚时或者数据库崩溃时，可以利用 Undo 日志，撤销未提交事务对数据库产生的影响Undo Log产生和销毁：Undo Log在事务开始前产生；事务在提交时，并不会立刻删除undolog，innodb会将该事务对应的undo log放入到删除列表中，后面会通过后台线程purge thread进行回收处理。Undo Log

InnoDB线程模型IO Thread在InnoDB中使用了大量的AIO（Async IO）来做读写处理，这样可以极大提高数据库的性能。在InnoDB1.0版本之前共有4个IO Thread，分别是write，read，insert buffer和log thread，后来版本将read thread和write thread分别增大到了4个，一共有10个了。read thread ： 负责读取操作，将数据从磁盘加载到缓存page页。4个write thread：负责写操作，将缓存脏页刷新到

从MySQL 5.5版本开始默认使用InnoDB作为引擎，它擅长处理事务，具有自动崩溃恢复的特性，在日常开发中使用非常广泛。下面是官方的InnoDB引擎架构图，主要分为内存结构和磁盘结构两大部分InnoDB内存结构内存结构主要包括Buffer Pool、Change Buffer、Adaptive Hash Index和Log Buffer四大组件。Buffer Pool：缓冲池，简称BP。BP以Page页为单位，默认大小16K，BP的底层采用链表数据结构管理Page。在InnoDB访问表记录

5.78.0MySQL 5.7 版本将 Undo日志表空间从共享表空间 ibdata 文件中分离出来，可以在安装 MySQL 时由用户自行指定文件大小和数量。增加了 temporary 临时表空间，里面存储着临时表或临时查询结果集的数据。Buffer Pool 大小可以动态修改，无需重启数据库实例。MySQL 8.0 版本将InnoDB表的数据字典和Undo都从共享表空间ibdata中彻底分离出来了，以前需要ibdata中数据字典与独立表空间ibd文件中数据字典一致才行，8..

查看支持的引擎存储引擎在MySQL的体系架构中位于第三层，负责MySQL中的数据的存储和提取，是与文件打交道的子系统，它是根据MySQL提供的文件访问层抽象接口定制的一种文件访问机制，这种机制就叫作存储引擎。使用show engines命令，就可以查看当前数据库支持的引擎信息 show engines;InnoDB：支持事务，具有提交，回滚和崩溃恢复能力，事务安全MyISAM：不支持事务和外键，访问速度快Memory：利用内存创建表，访问速度非常快，因为数据在内存，而且默认使用Hash

MySQL运行机制建立连接（Connectors&Connection Pool）通过客户端/服务器通信协议与MySQL建立连接。MySQL 客户端与服务端的通信方式是 “ 半双工 ”。对于每一个 MySQL 的连接，时刻都有一个线程状态来标识这个连接正在做什么。通讯机制：全双工：能同时发送和接收数据，例如平时打电话。半双工：指的某一时刻，要么发送数据，要么接收数据，不能同时。例如早期对讲机单工：只能发送数据或只能接收数据。例如单行道线程状态：show processlis

MySQL体系架构-概述MySQL Server架构自顶向下大致可以分网络连接层、服务层、存储引擎层和系统文件层。一、网络连接层客户端连接器（Client Connectors）：提供与MySQL服务器建立的支持。目前几乎支持所有主流的服务端编程技术，例如常见的 Java、C、Python、.NET等，它们通过各自API技术与MySQL建立连接二、服务层（MySQL Server）服务层是MySQL Server的核心，主要包含系统管理和控制工具、连接池、SQL接口、解析器、查询优化器和缓存

架构V1.0 - 单机单库一个简单的小型网站或者应用背后的架构可以非常简单, 数据存储只需要一个MySQL Instance就能满足数据读取和写入需求（这里忽略掉了数据备份的实例），处于这个的阶段系统，一般会把所有的信息存到一个MySQL Instance里面V1.0 瓶颈数据量太大，超出一台服务器承受读写操作量太大，超出一台服务器承受一台服务器挂了，应用也会挂掉（可用性差）架构V2.0 - 主从架构V2.0架构主要解决架构V1.0下的高可用和读扩展问题，通过给Instance挂载从库解

双M结构主备延迟主备切换可能是一个主动运维动作，比如软件升级、主库所在机器按计划下线等，也可能是被动操作，比如主库所在机器掉电在介绍主动切换流程的详细步骤之前，我要先跟你说明一个概念，即“同步延迟”。与数据同步有关的时间点主要包括以下三个主库 A 执行完成一个事务，写入 binlog，我们把这个时刻记为 T1;之后传给备库 B，我们把备库 B 接收完这个 binlog 的时刻记为 T2;备库 B 执行完成这个事务，我们把这个时刻记为 T3。所谓主备延迟，就是同一个事务，在备库执行完成的时.

MySQL 主备的基本原理在状态 1 中，客户端的读写都直接访问节点 A，而节点 B 是 A 的备库，只是将 A 的更新都同步过来，到本地执行。这样可以保持节点 B 和 A 的数据是相同的。当需要切换的时候，就切成状态 2。这时候客户端读写访问的都是节点 B，而节点 A 是 B 的备库在状态 1 中，虽然节点 B 没有被直接访问，但是我依然建议你把节点 B（也就是备库）设置成只读（readonly）模式。这样做，有以下几个考虑：有时候一些运营类的查询语句会被放到备库上去查，设置为只读可以防止误操

binlog 的写入机制binlog 的写入逻辑比较简单：事务执行过程中，先把日志写到 binlog cache，事务提交的时候，再把 binlog cache 写到 binlog 文件中.一个事务的 binlog 是不能被拆开的，因此不论这个事务多大，也要确保一次性写入。这就涉及到了 binlog cache 的保存问题系统给 binlog cache 分配了一片内存，每个线程一个，参数 binlog_cache_size 用于控制单个线程内 binlog cache 所占内存的大小。如果超过了这个

事务隔离级别SQL 标准的事务隔离级别包括：读未提交（read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（serializable ）读未提交是指，一个事务还没提交时，它做的变更就能被别的事务看到。读提交是指，一个事务提交之后，它做的变更才会被其他事务看到。可重复读是指，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。串行化，顾名思义是对