回滚

背景 本文为大家介绍Capital One如何利用自动化流水线实现Artifactory HA集群进行自动化运维。Capital One银行是美国最大的数字化银行之一，在Capital One的devops体系中应用了JFrog Artifactory HA集群进行软件制品管理。由于Capital One规模庞大并且为满足业务连续性要求，其部署的Artifactory HA拥有primary和DR（灾备）两套集群的架构。在运维Artifactory HA集群维护中通过建设和运行自动化的流水线，在不影响用户使用和业务连续性的前提下，自动地完成了版本升级、配置更新、功能更新，安全检测等工作，并且在检测到问题时，实现自动化的回滚。 流水线总体介绍： 通过Jenkins与Github集成驱动流水线。每个PULL请求触发一个小规模测试并提供快速反馈。每个Merge会触发研发环境HA集群范围的部署，并进行相关测试。标签（Tag）被用来标记代码更新的验证阶段和对应的环境。 使用Terraform创建基础设施，实现蓝/绿的发布。并通过Chef Cookbook完成整个集群内所有角色服务器配置 流水线构成 静态分析流水线 通过对代码静态分析对代码结构进行快速反馈，确保其符合行业标准。同时使用一系列的Linters进行不同类型的代码分析。 安全扫描流水线 Capital

开发老大要求通过binlog查询一条被修改的数据，数据被查出后问我，有没有可能binlog中不会记录，回答不会，因为数据被修改，若失败直接回滚，不会在binlog中记录，此刻一个朋友用了洪荒之力告诉我，失败的话也会记录，坐地无语，因为他sqlserver dba，用sqlserver的思维考虑mysql，哈哈哈哈哈，用实验让他闭嘴！ 简单测试步骤如下： root(yoon)> flush logs; Query OK, 0 rows affected (0.01 sec) root((none))> show binlog events in 'mysql-bin.000041'; +------------------+-----+-------------+-----------+-------------+---------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------------+-----+-------------+-----------+-------------+---------------------------------------+ | mysql-bin.000041 | 4 |

mysql是一种关系型数据库，关系型数据库一个重要的特性就是支持事务，这是区别于no-sql产品的一个核心特性。当然了，no-sql产品支持键值查询，不能支持sql语句，这也是一个区别。今天主要讨论下事务的提交流程，由于mysql插件式存储架构，导致开启binlog后，事务提交实质是二阶段提交，通过两阶段提交，来保证存储引擎和二进制日志的一致。本文仅讨论binlog未打卡状态下的提交流程，后续会讨论打开binlog选项后的提交逻辑。源码调试环境如下： 测试环境： OS：windows DB：mysql 5.6.12 engine：innodb 测试前置条件： set autocommit=0; create table tt(col1 int, col2 varchar(100)); 测试语句： insert into tt values(1, 'abcdef'); commit; 无论对于dml语句【insert，update，delete等】还是dcl语句【commit，rollback】，mysql提供了公共接口mysql_execute_command，我们先分析mysql_execute_command接口的基本流程： mysql_execute_command { switch (command) { case SQLCOM_INSERT: mysql_insert()

我们知道Git与SVN有着很多区别。Git相比SVN更加高效，其中主要的原因就是它把文件内容按 元数据 形式存储，可以理解为存到了一种类似 K/V型的数据库 里。 那么我们来分析下，它到底是如何存储文件以及如何管理提交与回滚的。 1.基础环境准备 在当前目录初始化一个用于测试的Git仓库 git_test_01 $ git init git_test_01 ; cd git_test_01 ; 创建一个文件并写入内容 $ echo 'first line' > test-file-01.txt ; 添加到暂存区并且提交该文件 $ git add -A ; git commit -am "first commit" ; 使用 git log --pretty=oneline 查看提交 如此，我们便成功的提交了一个文件。那么让我们进入**.git目录下的objects**文件夹看看发生了什么。 我们发现这里有个 d8 开头的目录，与我们 上次提交后产生的hash码 的开头 前两位 是一样的。 我们使用命令 ls -l d8 看看它究竟有什么 这里是一个名称为 85f1211e0cd1930bfdeecda5ac85998639f7d5 的文件，我们发现将 d8 和这个文件名组合一下居然和上面的提交id是一样的。这两者有什么关联呢？ 2.使用Git命令查看提交内容 2.1 内容写入及读取

深入了解分布式 分布式事务 分布式事务概念 分布式事务产生的原因 事务的ACID特性 分布式理论 CAP理论 BASE理论 分布式事务的应用场景 常见的分布式事务解决方案 两阶段提交 TCC编程模式 TCC开源框架-tcc-transaction TCC使用关键技术分析 分布式项目使用tcc-transaction框架 发布服务 调用服务 LCN解决方案 参考链接 分布式事务 分布式事务概念 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 分布式事务是为了保证不同数据库的数据一致性 分布式事务产生的原因 数据库分库分表 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表 应用SOA化 所谓的SOA化，就是业务的服务化。现在对整个网站进行拆解，分离除了订单中心、用户中心、库存中心。 事务的ACID特性 原子性(Atomicity) 所谓的原子性就是说，在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的操作都会被回滚，整个事务就像从没被执行过一样。 一致性(Consistency) 事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B50元，那么不管并发多少，不管发生什么，只要事务执行成功了

1. Mysql内核 MyISAM和InnoDB内核选型 1. InnoDB 支持事务，MyISAM 不支持事务。这是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一； 2. InnoDB 支持外键，而 MyISAM 不支持。对一个包含外键的 InnoDB 表转为 MYISAM 会失败； 3. InnoDB 是聚集索引，MyISAM 是非聚集索引。聚簇索引的文件存放在主键索引的叶子节点上，因此 InnoDB 必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此，主键不应该过大，因为主键太大，其他索引也都会很大。而 MyISAM 是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。 4. InnoDB 不保存表的具体行数，执行 select count(*) from table 时需要全表扫描。而MyISAM 用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快； 5. InnoDB 最小的锁粒度是行锁，MyISAM 最小的锁粒度是表锁。一个更新语句会锁住整张表，导致其他查询和更新都会被阻塞，因此并发访问受限。这也是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一； 如何选择： 1. 是否要支持事务

接上篇 文章目录 10 transaction-view-index事物-视图-索引: transaction定义,ACID,导致事物结束的两种情况:commit,rollback/回滚rollback:导致回滚的情况,解决方法/sql4个隔离层级isolated level,选择/事物序列化的定义,操作/view的定义,种类,声明,结合触发器的视图,基表更改引起实例化视图更改问题以及解决方法/index索引定义,声明,使用索引优化数据库查询tuning的优点,缺点 transaction定义,ACID,commit roll back:导致回滚的情况,解决方法 sql4个隔离层级isolated level,选择 视图的定义,两种类别,声明,结合触发器的视图,视图实例化,基表更改引起实例化视图更改问题的解决方法 index索引定义,声明,使用索引优化数据库查询tuning的优点,缺点 11 psm持久型存储模块(存储过程),pl与sql: psm定义,参量的三种类型,声明,invoke调用,语法:判断,循环,指针,return/动态SQL声明,调用 psm定义,参量,声明,invoke,3个基本种类及作用,语法:判断,循环,指针 动态SQL的声明,调用 12 grant授权: 语法:授权(操作权限,授权权限),撤销授权revoke,撤销授权的两种选项/授权图的点,边,AP,P*

最开始我用的是 vmware workstation（简称 vm），它满足了我的所有工作需求。随后在新的工作环境里面我改用 virtualbox （简称 vb）。 vb 我很欣赏的一点是它的辅助工具可以使用命令行安装，而 vm 则需要自己手动从光盘里进行操作（当然，这并不难）。 随后在工作中我遇到了俩个致命问题： 第一个是 vb 的快照机制和 vm 不太一样，vm 中的快照是相互独立的，我可以随时保存不同阶段的工作状态，从而在出错以后可以回滚到上一阶段，而 vb 的快照机制却不可以回滚（所以我并不知道这个快照有什么用）。 第二个是硬盘扩容，vb 的扩容需要在命令行进行复杂繁琐的指令操作，而且它会对系统进行格式化（我因此重装了俩次环境）。当然这一点是可以忍受的，直到有一天我打开 vb 的时候系统回滚到了扩容之前的系统（？？）。 当然我是很支持开源项目的，但是为了工作环境的稳定，我还是选择了花钱使用 vm。 来源： https://www.cnblogs.com/guangluwutu/p/10975716.html

出处： https://github.com/clsaa/Distributed-Transaction-Notes 。 作者总结得很全面，做个笔记搬运。 一、 两阶段提交(2PC) 一个基于两阶段提交协议的分布式事务框架(LCN) 二阶段提交(Two-phaseCommit)是指，在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。通常，二阶段提交也被称为是一种协议(Protocol))。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。 所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。 1. 准备阶段 事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志

什么是JTA？ JTA全称Java Transaction API ，即Java事务API，英文解释： Java Transaction API (JTA) specifies standard Java interfaces between a transaction manager and the parties involved in a distributed transaction system: the resource manager, the application server, and the transactional applications. JTA是一种高层的，与实现无关的，与协议无关的API，应用程序和应用服务器可以使用JTA来访问事务。 JTA允许应用程序执行分布式事务处理--在两个或多个网络计算机资源上访问并且更新数据，这些数据可以分布在多个数据库上。JDBC驱动程序的JTA支持极大地增强了数据访问能力。 JTA的主要接口： 位于javax.transaction包中 a、UserTransaction接口：让应用程序得以控制事务的开始、挂起、提交、回滚等。由Java客户端程序或EJB调用。 b、TransactionManager 接口：用于应用服务器管理事务状态 c、Transaction接口：用于执行相关事务操作 d、XAResource接口