我们之前了解了复制、扩展性，接下来就让我们来了解可用性。归根到底，高可用性就意味着 "更少的宕机时间"。
对于任何一个企业来说，数据安全的重要性是不言而喻的。我在开篇词中也曾经强调过，凡是涉及到数据的问题，都是损失惨重的大问题。
数据是当今Web，移动，社交，企业和云应用程序的流行货币。确保数据始终可用是任何组织的头等大事。几分钟的停机时间可能会导致收入和声誉严重损失。
上篇文章《InnoDB在SQL查询中的关键功能和优化策略》对InnoDB的查询操作和优化事项进行了说明。但是，MySQL作为一个存储数据的产品，怎么确保数据的持久性和不丢失才是最重要的，感兴趣的可以跟随本文一探究竟。
内容来源：2017年7月22日，UCloud高级研发工程师王松磊在“饿了么技术沙龙【第九弹】上海研发中心·运维专场”进行《数据库高可用架构》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。 阅读字数：3280 | 9分钟阅读 摘要 分享UCloud在数据库高可用上的最佳实践。首先介绍MYSQL常见的高可用方式，并分析其存在的问题，然后给出UCloud对此的思考和解决方法。 嘉宾演讲视频及PPT回顾：http://suo.im/2obXuQ MySQL
MySQL AB解决了数据备份的问题，但是当A由于某些原因宕机后，WEB服务器就没有办法在往数据库写或者读写了。线上业务中断了，完了，出事故了。这该怎么办呢？
当用户发出commit的时候, mysql服务器宕机了, 下次启动的时候是回滚还是恢复呢.
业务系统通过一个数据库连接发给MySQL，经过SQL接口、解析器、优化器、执行器，解析SQL语句，生成执行计划，接着由执行器负责执行该计划，调用InnoDB的接口去实际执行。
数据的一致性和完整性对于在线业务的重要性不言而喻，如何保证数据不丢呢？今天我们就探讨下关于数据的完整性和强一致性，MySQL做了哪些改进。
有一个小问题可能很多人都想起过，那就是MySQL中既然已经有了binlog,为什么还需要redo,这个问题看起来好像很简单，但是细细品来，还是有不少值得注意的地方。 对于数据恢复，尤其是异常宕机的情况下，再次启动的时候，如何恢复，恢复的数据依据，这个尤为重要，在MySQL中是有checkpoint的技术来做一个基本的检查点控制，也就是常说的LSN,对于事务性数据库，大都会采用write ahead log的策略，即当前事务提交的时候，先写redo,在修改相应的页，如果发生宕机导致数据丢失的时候
提交事务的时候，redo日志必须是刷入磁盘文件里的。这样可以严格的保证提交事务之后，数据是绝对不会丢失的，因为有redo日志在磁盘文件里可以恢复你做的所有修改。如果要是选择0的话，可能你提交事务之后，mysql宕机，那么此时redo日志没有刷盘，导致内存里的redo日志丢失，你提交的事务更新的数据就丢失了；如果要是选择2的话，如果机器宕机，虽然之前提交事务的时候，redo日志进入os cache了，但是还没进入磁盘文件，此时机器宕机还是会导致os cache里的redo日志丢失；所以对于数据库这样严格的系统而言，一般建议redo日志刷盘策略设置为1，保证事务提交之后，数据绝对不能丢失。
在之前的文章「简单了解InnoDB底层原理」聊了一下MySQL的Buffer Pool。这里再简单提一嘴，Buffer Pool是MySQL内存结构中十分核心的一个组成，你可以先把它想象成一个黑盒子。
前几篇对MySQL的知识介绍，让我们知道MySQL基本单位是数据页，默认情况下每个数据页的大小是16kb。数据页被读取到内存（Buffer Pool）中后被称为缓存页,，当对Buffer Pool中的数据页做了更新后，此时的数据页叫做：脏页，脏页最终是要刷入磁盘的，那么问题来了。
一条数据在更新过程当中，如果中途 mysql crash 了，mysql 是如何保证数据的一致性和持久性的？在这个过程中 mysql 的日志系统起到了至关重要的作用。本文将会介绍 mysql 中的 undo log、redo log 和 bin log 在这其中的作用。
这里我们所讨论的连接池是MyCat的后端连接池， 也就是MyCat后端与各个数据库节点之间的连接架构。
2PC全称是Two-PhaseCommit，翻译过来是二阶段提交，是分布式事务XA规范（XA规范是X/Open DTP定义的交易中间件与数据库之间的接口规范）的实现思路，满足CAP理论的CP，是强一致性事务。
在所有分布式系统实现中，很多技术点是基于日志实现的，可以认为日志是分布式系统中除了网络通信之外另一个实现基础。我做的第一个类似于hadoops的分布式任务调度处理系统就是基于raft+日志实现的，所以我们这次聊聊日志之于分布式系统的意义。
大家有没有想过为什么MySQL数据库可以实现主从复制，实现持久化，实现回滚的呢？其实关键在于MySQL里的三种log，分别是：
记住！ 记住！ 记住！ 上边这张图，她是MySQL更新数据的基础流程，其中包括redo log、bin log、undo log三种日志间的大致关系，好了闲话少说直奔主题。
首先，InnoDB会判读缓冲池里是否存在 id = 1 这条数据，如果不存在则从磁盘中加载到缓冲池中，而且还会对这行数据加独占锁，防止多个sql同时修改这行数据。
该参数是默认打开的，在数据库启动后立即启动自动relay log恢复。在恢复过程中，创建一个新的relay log,并将IO线程初始化到SQL线程的位置。
数据库对企业来说最重要的莫过于其中的数据，所以做好数据库的备份是一个不可或缺的工作。数据库及时备份可以帮助我们在数据库出现异常宕机时及时的使用备份数据进行恢复工作，将因为数据库宕机产生的影响降低到最小。所以，本篇文章主要数据库数据备份与恢复进行介绍。由于MyISAM存储引擎中备份数据是将表保存到单独的文件所以比较简单，所以这里我主要针对InnoDB存储引擎介绍备份与恢复机制。
TA想问：在这样的场景下，还有办法让B库尽快跑完这7200秒延迟数据吗，或者正确的办法是什么呢？
只要开启了binlog功能的mysql服务器就支持同步数据,支持数据同步就支持做为主节点.
Crash-safe，顾名思义，就是系统在突发的宕机或者崩溃情况发生时，对数据的安全性进行保护。在数据库中，我们把这个概念进一步细化，特指某种数据库特性或者机制，可以在系统宕机或者异常终止的情况下，保证数据的一致性和完整性。
当检测到物理线路1发生故障，系统自动将流量切换至物理线路2，保证业务正常运行。故障修复后，流量自动切回。
爱奇艺每天都为数以亿计的用户提供7x24小时不间断的视频服务。通过爱奇艺的平台，用户可以方便的获取海量、优质、高清的视频资源。但如果服务平台出现故障，会有大量的用户将无法正常播放视频，因此我们的应用服务以及数据库服务都必须具备高可用架构。
通过上文《MySQL是如何保证数据不丢失的？》可以了解DML的操作流程以及数据的持久化机制。对于一个数据库而言，除了数据的持久性、不丢失之外，一致性也是非常重要的，不然这个数据是没有任何意义的。在使用MySQL时，数据不一致的情况也可能出现，所以，本文就来看看MySQL是如何保证数据一致的。
参考博客1（建议先通读该博客）介绍了MySQL通过Undo+Redo Log的机制实现了事务的原子性、一致性和持久性（关于事务的隔离性是通过锁机制来保障的，请参考我的另一篇博文MySQL常见的七种锁详细介绍）。文章中提到：
对于 MySQL 5.7 的数据恢复,我们可以借助 dbsake 和 ibd2sql 这两个强大的工具来完成。这个方法不仅可以恢复表结构,还能恢复数据,是一个相当完整的解决方案。下面是详细步骤:
1、什么是悲观锁？什么是乐观锁？ 1）悲观锁 它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在 整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供 的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改 数据）。
今天下午，线上阿里云RDS的本地只读从库宕机了，还好，这个个服务器上的数据库实例只是提供了一部分的读需求，很快就复原了，但是上面所有的数据库实例都down掉了，启动实例并保证主从复制关系迫在眉睫。这个过程中发现有一个主从复制的问题值得研究一下，虽然最后我解决了，但是具体的原因没有找到，还请大家帮忙看看，也算是集思广益了，如果某一天找到原因了，再回来更新一下。
2023 年某一天周末，新手程序员小明因为领导安排的一个活来到公司加班，小明三下五除二，按照领导要求写了一个跑批的数据落库任务在测试环境执行 ，突然间公司停电了，小明大惊，“糟了，MySQL 还在跑任务，会不会因为突然断电，导致数据库崩了”。
MySQL Group Replication（简称MGR）是MySQL官方于2016年12月份推出的一个全新的高可用与高扩展的解决方案。MGR提供了高可用、高扩展、高可靠的MySQL集群服务，是MySQL数据库未来发展的一个重要方向。 场景描述 操作系统MySQL版本CentOS Linux release 7.3.1611MySQL5.7.20 二进制 ip地址规划 IP地址hostsport192.168.74.134mgr-node1.up.com3306\23306192.168.74.13
现如今 Redis 变得越来越流行，几乎在很多项目中都要被用到，不知道你在使用 Redis 时，有没有思考过，Redis 到底是如何稳定、高性能地提供服务的？
在上一篇《面试官：你说说一条查询SQL的执行过程？》中描述了Mysql的架构分层，通过解析器、优化器和执行引擎完成一条SQL查询的过程，那这一篇续上继续说明一条更新SQL的执行过程。
RocketMQ天然支持分布式集群模型，其中主节点可读可写，从节点只可读，不可写，类似MySQL的主从模式。RocketMQ主要支持以下几种集群模型：
导语｜近年来，Redis 变得越来越流行。Redis 持久化、主从复制、哨兵、分片集群是开发者常遇到的、看似容易理解的概念。它们存在什么联系？Redis 为什么会演化出几种架构模式？腾讯云后台开发工程师谭帅将带你一步步构建出稳定、高性能的 Redis 集群。了解 Redis 做了哪些方案来实现稳定与高性能之后，你在日常使用 Redis 时，能够更加游刃有余。
InnoDB 存储引擎是以页为单位来管理存储空间的, 我们的增删改查操作本质上都是在访问页面, 如读取一条数据, 会把这个数据所在的页加载到内存中, 而不仅仅是这条数据本身, 这个页的默认大小是 16KB.
ber的Schemaless数据库是从2014年10月开始启用的，这是一个基于MySQL的数据库，本文就来探究一下它的架构。本文是系列文章的第二部分；第一部分是关于Schemaless的设计。 在《Mezzanine项目——Uber的超级大迁移》一文中，我们描述了如何将Uber的核心trip数据从一个单独的Postgres实例迁移到Schemaless这个可扩展与高可用的数据库中。然后对Schemaless进行了简单介绍，包括其发展决策过程、整体数据模型，并介绍了Schemaless的trigger与索引等
Redis 现在已经十分流行，互联网几乎所有项目都会用到，在使用 Redis 时，你知道是如何保证稳定和高效的提供服务呢，它的架构演化路程是什么呢？
redo log 事务的支持是数据库区分文件系统的重要特征之一，事务的四大特性： 原子性：所有的操作要么都做，要么都不做，不可分割。 一致性：数据库从一种状态变成另一种状态的的结果最终是一致的，比如A给B转账500，A最终少了500，B最终多了500，但是A+B的值始终没变。 隔离性：事务和事务之前相互隔离，互不干扰。 持久性：事务一旦提交，它对数据的变更是永久性的。 本篇文章主要说说持久性相关的知识。 当我们在事务中更新一条记录的时候，比如： update user set age=11 where u
我们的系统在和 MySQL 数据库进行通信前，需要先和数据库建立连接，而这个功能就是由MySQL驱动底层帮我们完成的，建立完连接之后，我们只需要发送 SQL 语句就可以执行 CRUD 了。如下图所示：
在MySQL 中我们经常会接触到三个核心日志，它们分别是：binlog 、redo log、undo log。
最近在极客时间看丁奇大佬的《MySQL45讲》，真心觉得讲的不错，把其中获得的一些MySQL方向的经验整理整理分享给大家，有兴趣同学可以购买相关课程进行学习。
我们通常将 Redis 作为缓存使用，提高读取响应性能，一旦 Redis 宕机，内存中的数据全部丢失，假如现在直接访问数据库大量流量打到 MySQL 可能会带来更加严重的问题。
我们在使用和维护MySQL时，一定经常听到binlog这个概念。binlog在主从复制，数据恢复等场景都有着重要作用。本篇文章主要介绍binlog的概念，功能及常用操作，旨在帮助大家对binlog有更深的了解。
有了ibd2sql,就多了一张保命符。下次遇到类似情况,别忘了这个强大的工具。它可能会帮您化险为夷,保住饭碗!
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
