有个水友提问： 沈老师，我们有一次MySQL崩溃，重启后发现有些已经提交的事务对数据的修改丢失了，不是说事务能保证ACID特性么，想问下什么情况下可能导致“事务已经提交，数据却丢失”呢？ 这个问题有点复杂，得先从redo log说起。 为什么要有redo log？ 事务提交后，必须将事务对数据页的修改刷(fsync)到磁盘上，才能保证事务的ACID特性。 这个刷盘，是一个随机写，随机写性能较低，如果每次事务提交都刷盘，会极大影响数据库的性能。 随机写性能差，有什么优化方法呢？ 架构设计中有两个常见的优化方法
MySQL 有很多存储引擎（也叫数据引擎），所谓的存储引擎是指用于存储、处理和保护数据的核心服务。也就是存储引擎是数据库的底层软件组织。在 MySQL 中可以使用“show engines”来查询数据库的所有存储引擎，如下图所示：
谁也不能保证计算机系统能够永远无故障的执行下去。网络波动、磁盘损坏等现网高频故障，机房掉电、服务器硬件失效等低频却又致命的故障，时刻考验着我们的系统。
如果熟悉MySQL你肯定知道MySQL能过对数据进行恢复（前提是开启bin log日志），当然这要归功于bin log日志。但是你可曾听过redo log呢？
日常开发中,获取数据的总数是很常见的业务场景,但是我们发现随着数据的增长count(*)越来越慢，这个是为什么呢，
innodb_flush_log_at_trx_commit 是 MySQL 的一个系统变量，运行环境是 InnoDB 引擎。该变量定义了 InnoDB 在每次事务提交时，如何处理未刷入（flush）的重做日志信息（redo log）。它是 InnoDB 确保 ACID 属性中的持久性（Durability）的关键因素。当数据库发生故障，如崩溃或者断电，这项设置可以保护您的数据不会丢失。
RDB：这是一种快照的方式，它将 Redis 某时间点的数据都进行快照存储。比如 Mysql Dump 也是这种方式。 AOF：写日志的方式，记录每次对服务器写的操作, 当服务器重启的时候会重新执行这些命令来恢复原始的数据。例如 Mysql binlog，Hbase HLog。
提交事务的时候，redo日志必须是刷入磁盘文件里的。这样可以严格的保证提交事务之后，数据是绝对不会丢失的，因为有redo日志在磁盘文件里可以恢复你做的所有修改。如果要是选择0的话，可能你提交事务之后，mysql宕机，那么此时redo日志没有刷盘，导致内存里的redo日志丢失，你提交的事务更新的数据就丢失了；如果要是选择2的话，如果机器宕机，虽然之前提交事务的时候，redo日志进入os cache了，但是还没进入磁盘文件，此时机器宕机还是会导致os cache里的redo日志丢失；所以对于数据库这样严格的系统而言，一般建议redo日志刷盘策略设置为1，保证事务提交之后，数据绝对不能丢失。
4.更新操作为什么不直接更新磁盘反而设计这样⼀个复杂的InnoDB存储引擎来完成？
目前，容器和 Docker 依旧是技术领域最热门的词语，无状态的服务容器化已经是大势所趋，同时也带来了一个热点问题被大家所争论不以：数据库 MySQL 是否需要容器化？
容器的定义：容器是为了解决“在切换运行环境时，如何保证软件能够正常运行”这一问题。 目前，容器和 Docker 依旧是技术领域最热门的词语，无状态的服务容器化已经是大势所趋，同时也带来了一个热点问题被大家所争论不以：数据库 MySQL 是否需要容器化？ 认真分析大家的各种观点，发现赞同者仅仅是从容器优势的角度来阐述 MySQL 需要容器化，几乎没有什么业务场景进行验证自己的观点；反过来再看反对者，他们从性能、数据安全等多个因素进行阐述 MySQL不需要容器化，也举证了一些不适合的业务场景。下面，我们就聊一
—1— 前言 容器的定义：容器是为了解决“在切换运行环境时，如何保证软件能够正常运行”这一问题。 目前，容器和 Docker 依旧是技术领域最热门的词语，无状态的服务容器化已经是大势所趋，同时也带来了一个热点问题被大家所争论不以：数据库 MySQL 是否需要容器化？ 认真分析大家的各种观点，发现赞同者仅仅是从容器优势的角度来阐述 MySQL 需要容器化，几乎没有什么业务场景进行验证自己的观点；反过来再看反对者，他们从性能、数据安全等多个因素进行阐述 MySQL不需要容器化，也举证了一些不适合的业务场景。下
GTID模式：GTID是事务的ID，唯一识别号，全局唯一。对于主从复制简单来说就是不需要管binlog日志和复制点，简化复制操作和降低复制集群维护的难度，但是只支持带事务的引擎和语句
这个问题是在某个群里面，看见有人问的，已经2020年了，到底Double write 能不能关，这是一个好问题。因为有些数据库压根没有 Double write 也就没有性能上的损耗了。那为什么MYSQL 要有DOUBLE WRITE ，并且可以关吗？
来源 | https://www.toutiao.com/i6675622107390411276
首先，InnoDB会判读缓冲池里是否存在 id = 1 这条数据，如果不存在则从磁盘中加载到缓冲池中，而且还会对这行数据加独占锁，防止多个sql同时修改这行数据。
作为一位优秀的程序员，当你发现你的同事删库跑路，一个八百米飞奔奔向美好的明天时，随手把身边的你拉入了无底深渊，请不要心慌，不要着急，平静下来，看完本章秘籍，在进行直播卖货APP开发时，我们可能会遇到数据库数据丢失的情况，那么，我们该怎么做呢？
MySQL是一个RDBMS（关系型数据库管理系统），由瑞典MySQL AB 公司开发，目前属于 Oracle 旗下产品。由于其体积小、速度快、拥有成本低，尤其是开放源码这一特点，广受各大企业欢迎，包括腾讯，阿里，百度，网易，Google，FaceBook等互联网巨头企业 随着互联网的高速发展，互联网服务可用性变得越发重要，数据容灾也随之成为各企业的关键任务。在数据容灾中，数据库集群如何处理数据一致性也成为了各企业需要解决的问题。特别在一些新兴的金融服务中，MySQL也逐渐成为其核心数据库，如何保证金钱的准
在《图解Kafka中的基本概念》中已经对副本进行了介绍。我们先回顾下，Kafka中一个分区可以拥有多个副本，副本可分布于多台机器上。而在多个副本中，只会有一个Leader副本与客户端交互，也就是读写数据。其他则作为Follower副本，负责同步Leader的数据，当Leader宕机时，从Follower选举出新的Leader，从而解决分区单点问题。本文将继续深入了解Kafka中副本机制的设计和原理。
《高性能MySQL》读书笔记（二）——MySQL存储引擎概述 （原创内容，转载请注明来源，谢谢） 一、基础信息 mysql将数据库保存在数据目录下的一个子目录，创建表时，会在此目录下，创
最近线上突然发现一张表每天会产生500w条的数据，一个月下来发现已经接近8000w条的数据，达到90G之大的数据，之前在系统没有升级之前一年才产生100w左右的记录，估计开发的程序或者逻辑出现问题了，不管怎么样，作为运维发生问题，第一时间先以解决问题为第一位，所以这里总结一下删除大表数据的经验。
业务系统通过一个数据库连接发给MySQL，经过SQL接口、解析器、优化器、执行器，解析SQL语句，生成执行计划，接着由执行器负责执行该计划，调用InnoDB的接口去实际执行。
上篇文章《InnoDB在SQL查询中的关键功能和优化策略》对InnoDB的查询操作和优化事项进行了说明。但是，MySQL作为一个存储数据的产品，怎么确保数据的持久性和不丢失才是最重要的，感兴趣的可以跟随本文一探究竟。
首先看下MySQL误删数据排名最前的几种是什么，然后说几点平时预防误操作导致文件/数据丢失不成熟的建议，最后再说万一发生误操作时，怎么以最快速度进行补救。
我们通常将 Redis 作为缓存使用，提高读取响应性能，一旦 Redis 宕机，内存中的数据全部丢失，假如现在直接访问数据库大量流量打到 MySQL 可能会带来更加严重的问题。
本文我们来看一个场景，两台MySQL实例使用主从复制，当master故障，触发高可用切换，新master上线后，通过备份重建旧master并建立复制后，数据发生丢失。
案例是一个泰国网站的生产环境（请脑补一句“萨瓦迪卡”，为了叙述方便，下文中均以"萨瓦迪卡"指代这个网站。）“萨瓦迪卡”是一个 采用 Wordpress + MySQL搭建的应用。这个遗留系统已经工作了五年。客户已经把在其它 VPS 上平移到 AWS 上。平移（lift and shift）是说原样复制，而迁移（migration）还要进行改造。而客户唯一发挥 AWS 优势的一点就是用了一个配置很高的 EC2 虚拟机 —— m4.4xlarge。这样一台配置的虚拟机有 16 个虚拟 CPU，64 GiB 的内存，以及 2000 Mbps 的网络带宽，最高 3000 IOPS 的 200GiB 的块存储设备（也就是硬盘）。
在进行业务系统开发时，缓存的引入可以显著提升系统性能,但是也会带来一致性问题。本文将介绍缓存不一致的原因,以及如何实现缓存与数据库的强一致性。
Mysql为了解决这个风险并提高复制的性能，将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Yahoo!的一位工程师“Jeremy Zawodny”。这样既解决了性能问题，又缩短了异步的延时时间，同时也减少了可能存在的数据丢失量。当然，即使是换成了现在这样两个线程处理以后，同样也还是存在slave数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事物中，这些问题都是会存在的。如果要完全避免这些问题，就只能用mysql的cluster来解决了。不过mysql的cluster是内存数据库的解决方案，需要将所有数据都load到内存中，这样就对内存的要求就非常大了，对于一般的应用来说可实施性不是太大。
可以发现的是，它们的持久化机制都差不得太多。今天想来总结一下，一方面想来回顾一下这些组件，一方面给还没入门过这些中间件的同学总结一下持久化的”套路“，后面再去学习的时候就会轻松很多。
MySQL软件官方下载地址(https://dev.mysql.com/downloads/mysql/)，个人感觉下载压缩包版比下载安装包办的要好，因为安装包版的默认安装路径为系统盘，整个数据库有1.8G左右，太占系统盘存储。
公司运维能力不是太好，数据库最近出了一次问题，导致丢失了一天的数据，并且某个服务宕机一晚上。为了避免再次出现类似问题，我决定添加一个Slave服务器，以避免数据丢失和服务宕机的问题。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
整合了商品名称、价格、图片、简介的商品详情页就是典型的场景，可以把通过复杂操作耗时查询出来的结果，确定短时间内不会频繁更新变化，但是对这个数据会有大量读请求，这个时候就可以直接把结果存放在缓存中，后面的请求就直接读取缓存即可。
Redis提供了将数据定期自动持久化至硬盘的能力，包括RDB和AOF两种方案，两种方案分别有其长处和短板，可以配合起来同时运行，确保数据的稳定性。
容器的定义：容器是为了解决“在切换运行环境时，如何保证软件能够正常运行”这一问题。
Memory引擎的表和InnoDB引擎的表我们在执行全表查询的时候，Mmeory引擎的表返回结果0在最后一行，而InnoDB引擎的表0在第一行。这种区别主要是因为数据组织方式的不同。
关于误操作删除数据和数据恢复，一定要有安全意识，MySQL数据的找回，一定要在配置bin-log，否则数据丢失将无法恢复：
我们有需要将物理盘上的mysql迁移到ssd上，先说一下生产环境一直有数据产生，且数据量达到500G。 方案一：使用mysqldump，不管是导入导出都太耗时，没有一天拿不下 方案二：直接物理磁盘上拷贝也是非常耗时，拷贝过程中需要停服务，这就导致停服务时间太长。 方案三：这个方案本来是很有优势的，但是实际情况导出导入也需要锁表或锁库，也是需要停服务，本来我们就不需要增量拷贝，innobackupex优势体现在增量拷贝。 方案四：拷贝速度快 综合停服务时间以及操作难易度，最终选择了方案四。 下面描述下操作步骤
Metabase 是一个开源的数据可视化工具，其引入的question概念使得非技术人员能够轻松地创建和共享自定义数据仪表板。Metabase 同时还支持用户通过简单的拖放界面连接到任何数据源，并使用直观的图表和图表来可视化数据。Metabase 还提供了丰富的分析功能，例如聚合、过滤和分组，使数据能够更加高效便捷的展示出来，便于用户更好的了解数据。
相对于其他的数据库厂商大会，MySQL的的确寒酸，连幕头都没有，上来就直接讲，不过也符合MySQL一贯的风格。这次翻译的是 2023年MySQL summit -- MySQL high availability and disaster recovery。开始本次的讲解人是 MySQL的产品经理，明显和我之前听的MongoDB的两期差距较大，一看是不善言辞的人。
前言 上一篇分享了关于MySQL事务的知识，在我们数据库中最重要的就是数据了，所以数据的备份就显的特别的重要！ 为什么要备份数据？ 在生产环境中我们数据库可能会遭遇各种各样的不测从而导致数据丢失, 大概分为以下几种： 硬件故障、软件故障、自然灾害、黑客攻击、误操作（占比例大） 所以, 为了在数据丢失之后能够恢复数据, 我们就需要定期的备份数据, 备份数据的策略要根据不同的应用场景进行定制, 大致有几个参考数值, 我们可以根据这些数值从而定制符合特定环境中的数据备份策略： 能够
Linux没有图形化界面，我们只能通过控制台去操作系统，我们就要使用类似DOS命令的Linux命令去操作系统
所以, 为了在数据丢失之后能够恢复数据, 我们就需要定期的备份数据, 备份数据的策略要根据不同的应用场景进行定制, 大致有几个参考数值, 我们可以根据这些数值从而定制符合特定环境中的数据备份策略
开发哥们最近遇到个问题，说是Django ORM日志上看数据已经提交了，但是服务器突然断电，重启后发现之前写入的数据丢失了。 让我帮看看什么原因导致的。
我们试着想一想, 在生产环境中什么最重要？如果我们服务器的硬件坏了可以维修或者换新, 软件问题可以修复或重新安装, 但是如果数据没了呢？这可能是最恐怖的事情了吧, 我感觉在生产环境中应该没有什么比数据跟更为重要. 那么我们该如何保证数据不丢失、或者丢失后可以快速恢复呢？只要看完这篇, 大家应该就能对MySQL中实现数据备份和恢复能有一定的了解。 为什么需要备份数据？ 其实在前言中也大概说明了为什么要备份数据, 但是我们还是应该具体了解一下为什么要备份数据 在生产环境中我们数据库可能会遭遇各种各样的不测从而
本文将重点探讨Docker容器中的数据管理策略，包括卷、挂载和数据持久化。通过深入分析这些数据管理策略在Docker社区和市场中的应用，以及在不同领域和技术领域中的具体应用案例，我们可以更好地理解如何有效地管理Docker容器中的数据，并确保数据的安全和持久性。
大家好，我是小菜。一个希望能够成为 吹着牛X谈架构 的男人！如果你也想成为我想成为的人，不然点个关注做个伴，让小菜不再孤单！
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
