当然，本篇也是关于性能优化的，那性能优化就应该一把梭子吗？还是要符合一些规范和原则呢？
MySQL的buffer一页的大小是16K，文件系统一页的大小是4K，也就是说，MySQL将buffer中一页数据刷入磁盘，要写4个文件系统里的页。
MySQL采用buffer机制，避免每次读写进行磁盘IO，提升效率： 《缓冲池(buffer pool)》 《写缓冲(change buffer)》 《日志缓冲(log buffer)》 MySQL的buffer一页的大小是16K，文件系统一页的大小是4K，也就是说，MySQL将buffer中一页数据刷入磁盘，要写4个文件系统里的页。 如上图所示，MySQL里page=1的页，物理上对应磁盘上的1+2+3+4四个格。 那么，问题来了，这个操作并非原子，如果执行到一半断电，会不会出现问题呢？ 会，这就是所谓
在事务的ACID特性中，原子性（A）、一致性（C）、持久性（D）由undo log和redo log实现，隔离性（I）由锁+MVCC实现
method profile、gc统计、io统计、流量统计、硬件使用统计、耗电量分析。
MySQL软件官方下载地址(https://dev.mysql.com/downloads/mysql/)，个人感觉下载压缩包版比下载安装包办的要好，因为安装包版的默认安装路径为系统盘，整个数据库有1.8G左右，太占系统盘存储。
正常情况下，只要主库执行更新生成的所有binlog，都可以传到备库并被正确执行，备库就能达到跟主库一致的状态，这就是最终一致性。
mysql的"双1验证"指的是innodb_flush_log_at_trx_commit和sync_binlog两个参数设置，这两个是是控制MySQL 磁盘写入策略以及数据安全性的关键参数。下面从参数含义，性能，安全角度阐述两个参数为不同的值时对db 性能,数据的影响。
WAL(Write Ahead Log)预写日志，是数据库系统中常见的一种手段，用于保证数据操作的原子性和持久性。
云豆贴心提醒，本文阅读时间7分钟 现在MySQL运行的大部分环境都是在Linux上的，如何在Linux操作系统上根据MySQL进行优化，我们这里给出一些通用简单的策略。这些方法都有助于改进MySQL的性能。 闲话少说，进入正题。 一、CPU 首先从CPU说起。 你仔细检查的话，有些服务器上会有的一个有趣的现象： 你cat /proc/cpuinfo时，会发现CPU的频率竟然跟它标称的频率不一样： 这个是Intel E5-2620的CPU，他是2.00G * 24的CPU，但是，我们发现第5颗C
在memcached的解决方式中。分布的不同memcached结点彼此是不能通信的，要实现memcached结点的之间的Master/Slave结构。有一个日本同学开发了一个第三方的工具Recached，能够实现Memcached的主备结构。从结点能够实时的同步主结点的数据，当主节点挂掉，从结点能够热备的提供服务。
ssize_t write(int fd, const void *buf, size_t count);
数据库要将数据进行管理的前提就是将数据进行存储。但是存储数据使用文件就可以了，为什么还要弄个数据库呢？
办公室掉电，PXC集群环境无法启动，也就是说整个集群的状态处于丢失的情形。因此需要采取强制的方式来进行，见下面的描述。
EasyNVR视频边缘计算网关可以放置在项目现场，7x24 小时不间断使用，通电联网即可成功运行，部署操作十分简单。我们在此前的文章中也介绍过不少关于EasyNVR硬件的相关技术配置与操作教程，大家可以在博客中自行搜索进行了解。
在进行数据存储的时候，最担心的莫过于数据丢失了，而数据丢失可以从很多层面来进行保障，但是最终数据都是存储在磁盘当中。
明显不会，磁盘IO太慢了，如果每个请求过来 MySQL 都要写磁盘，磁盘肯定扛不住。
apache-tomcat/bin目录下的startup.bat在windows上启动。
没有电池的嵌入式设备，很容易发生随机掉电。因此要让产品可靠稳定，就必须保证各种场景下的掉电安全。
在上一篇文章中，介绍了 binlog 的基本内容，在一个主备关系中，每个备库接收主库的 binlog 并执行。
酷 壳 – CoolShell http://coolshell.cn/articles/17680.html
FLASH存储器又称闪存，它结合了ROM和RAM的长处，不仅具有电可擦除可编程（EEPROM）的功能，还不会断电丢失数据，同时可以快速读取数据（NVRAM的优势），U盘使用这种存储器。
断电后恢复，启动线下数据库，启动备库start slave报错io_thread没有启动成功
最近1-2周, 业务侧基于性能和一致性的需求，测试和验证基于sofa-jraft的框架。由于上线后事关生产环境的稳定性，于是加入调研jraft/raft相关领域调研，确保生产环境即使在极端情况下，也在我们考量的范围之内。
昨天，Gitlab.com发生了一个大事，某同学误删了数据库，这个事看似是个低级错误，不过，因为Gitlab把整个过程的细节都全部暴露出来了，所以，可以看到很多东西，而对于类似这样的事情，我自己以前也干过，而在最近的两公司中我也见过（Amazon中见过一次，阿里中见过至少四次），正好通过这个事来说说一下自己的一些感想和观点吧。我先放个观点：你觉得有备份系统就不会丢数据了吗？ 事件回顾 整个事件的回顾Gitlab.com在第一时间就放到了Google Doc上，事后，又发了一篇Blog来说明这个事，在这里，
第二届云原生编程挑战赛正在火热进行中，Kirito 也在做《针对冷热读写场景的RocketMQ存储系统设计》这个题目，不过参与的是内部赛道，没法跟外部的小伙伴们一起排名了。
这周又一段时间没怎么写文章了，这周上班接触的东西有点多，每天都在接受挑战。维护公司移动app界面，设计到的技术是css、html、javascript。然后把写好的app程序通过threadx和Linux两个系统的支持（Linux内核版本是在3.10版本的，在安霸和海思平台）；第一次搭建编译环境（这里跟平时学的环境有比较大的出路，作者被骂了好几次，终于是成功了，呜呜。。。），然后实时在PC或者手机端采集实时视频监控。后期会不断学习和分享自己在工作当中的一些经验给大家，希望对大家有帮助。今天开始写Uboot的文章和Linux驱动的文章。之前Linux应用的文章全部在公众号后台有。以上学习过程中，作者是学习朱有鹏老师的嵌入式课程。
不管是开发同学还是DBA,想必大家都遇到慢查询(select,update,insert,delete 语句慢)，影响业务稳定性。这里说的慢，有两个含义一是比正常的慢，有可能正常执行时间是10ms，异常的是100ms 。二是sql执行时间超过设置的慢查询标准比如500ms。
今天在工作中遇到了一个问题，就是某个服务器的从库由于磁盘问题，产生了延迟，而监控和报警没有发觉，没有报警提示，当我清理磁盘之后，发现一个问题，从库已经无法落后主库24个小时了，好的一点是主库的binlog文件都还在，但是从库应用relay-log的速度小于relay-log的生成速度，所以导致这个从库的SBM(second behind master)一直缓慢上升，想了半天没有好的办法，最终通过设置innodb_flush_log_at_trx_commit=0的方法暂时得到缓解。关于mysql中的这个参数，之前简单做过一些了解，今天看了下官方的手册，大概翻译如下：
在MySQL的日常维护中，我们总会遇到这样或那样的问题，对于那些经常发生且有处理经验的事故，不论是新手还是老司机都能在故障规定的容错时间内解决。而对于那些不常见、比较棘手的问题，新手上路可能就显得举足无措了，这个时候新手和老司机的差距就体现出来了。从知识储备还是工作经验，可能老司机比新手强一点，但如果一个新司机没有日志排错的意识，不具备日志排错的经验，那怎么能学会弯道超车、漂移的快感。我们知道数据库中有很多重要的日志，如错误日志error log、慢日志slow log、二进制日志binary log、查询日志general log等等其他日志，错误日志error log是我们分析问题参考的依据，它记录数据库的启动/运行/停止的过程，包含了info、warning、error三个级别，分析error log也有助于我们了解数据库的运行机制。
谁也不能保证计算机系统能够永远无故障的执行下去。网络波动、磁盘损坏等现网高频故障，机房掉电、服务器硬件失效等低频却又致命的故障，时刻考验着我们的系统。
MySQL 的慢查询日志是 MySQL 提供的一种日志记录，它用来记录在 MySQL 中响应时间超过阀值的语句，具体指运行时间超过long_query_time值的 SQL，则会被记录到慢查询日志中。long_query_time的默认值为10，意思是运行10s以上的语句。
日志系统主要有redo log(重做日志)和binlog(归档日志)。redo log是InnoDB存储引擎层的日志，binlog是MySQL Server层记录的日志， 两者都是记录了某些操作的日志(不是所有)自然有些重复（但两者记录的格式不同）。
2023年12月27日，由中国信息通信研究院、中国通信标准化协会主办的2023系统稳定性与精益软件工程大会在北京举行。腾讯专有云《基于AZ内故障演练的专有云服务风险隐患排查》荣获第二届云系统稳定安全运行优秀案例-混沌工程实践优秀案例，《专有云机房断电恢复应急处置实践案例》荣获云系统运行故障应急处理实践优秀案例。
mysql启动的时候会自动生成一个套接字的文件，可以通过本地访问这个文件登录mysql
show slave status的报错信息如下： Last_SQL_Error: Error '@@SESSION.GTID_NEXT cannot be set to ANONYMOUS when @@GLOBAL.GTID_MODE = ON.' on query. Default database: ''. Query: 'CREATE TABLE IF NOT EXISTS infra.chk_masterha (`key` tinyint NOT NULL primary key,`val` int(10) unsigned NOT NULL DEFAULT '0') engine=MyISAM'
许多IC都包含上电复位（POR）电路，其作用是保证在施加电源后，模拟和数字模块初始化至已知状态。基本上电复位（POR）功能会产生一个内部复位脉冲以避免"竞争"现象，并使器件保持静态，直至电源电压达到一个能保证正常工作的阈值。
上一篇简单介绍了下MySQL的存储引擎，为什么需要存储引擎以及如何使用存储引擎。MySQL的配置文件是控制和配置 MySQL服务器行为的重要文件。对于新手开发者来说，理解掌握并运用 MySQL 配置文件是非常重要的。本篇想着重讲下MySQL的配置文件，帮助读者朋友们快速了解并上手使用，以便解决你在学习和工作中遇到的问题。
本文是由爱可生研发团队出品的「图解MySQL」系列文章，不定期更新，但篇篇精品。欢迎大家持续关注～
Redo log的刷盘操作将会是最终影响MySQL TPS的瓶颈所在。为了缓解这一问题，MySQL使用了组提交，将多个刷盘操作合并成一个，如果说10个事务依次排队刷盘的时间成本是10，那么将这10个事务一次性一起刷盘的时间成本则近似于1。
是否启用mysql查询缓存，可以通过2个参数：query_cache_type和query_cache_size，
对于全栈而言，数据库技能不可或缺，关系型数据库或者nosql，内存型数据库或者偏磁盘存储的数据库，对象存储的数据库或者图数据库……林林总总,但是第一必备技能还应该是MySQL。从LAMP的兴起，到Mariadb的出现，甚至PG的到来，熟练的MySQL技能都是大有用武之地的。
大家好，又见面了，我是你们的朋友全栈君。 大数据的处理方式有两种：基于内存的流式处理和基于硬盘的存储处理。 流式处理就好象是在经过的数据面前建一道水闸。数据流过这里，经过闸门的时候，就进行筛选过滤，分析出有价值的内容，然后丢弃，以后也不再使用。 存储处理则是建一个储水池。数据先放进入储水池存起来，需要的时候，再进到储水池里，在里面筛选分析，找到那些有价值的内容。这个过程中，因为水还在储水池里，没放掉，所以可以供下次继续使用。 存储模式的数据处理是可以重复的，用完再用，反复使用。但是因为硬盘本身的机械特性问题，导致它处理速度慢，速率不高。不过现在也还是有一些针对硬盘的优化措施。 流式处理因为数据的处理过程在内存里进行，内存的处理性能是硬盘的数个量级，所以它的处理速率比存储模式高很多。但是也因为数据驻留在内存里，内存的特性是掉电即失的，只能一次性使用。所以流式处理通常是用完即弃，象卫生巾。 大数据产品里，Spark是流式处理，Laxcus、Hadoop是存储处理。
Linux 将物理内存分为内存段，叫做页面。交换是指内存页面被复制到预先设定好的硬盘空间（叫做交换空间）的过程，目的是释放这份内存页面。物理内存和交换空间的总大小是可用的虚拟内存的总量。
在电源关断模块有可能要求register对关断前的数据进行锁存或者在电源打开后要求对锁存的数据进行恢复，这就需要特殊的单元Retention Register。
今天来和大家分享MySQL的三个日志文件，可以说 MySQL 的多数特性都是围绕日志文件实现，而其中最重要的有以下三种：
前面几篇文章，从两个开源程序chaos-mesh、chaosblade入手，分析混沌工程的原理；然后讲混沌工程实施的完整过程及混沌原则梳理，本文主要是记录之前的知识，用一个例子说明混沌工程是怎么设计的。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
