fsync

1、前言 相信工作了一段时间的同学肯定都用过事务，也都听说过事务的4大特性ACID。ACID表示原子性、一致性、隔离性和持久性。一个很好的事务处理系统，必须具备这些标准特性： 原子性（Atomicity）： 一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚。 一致性（consistency）： 数据库总是从一个一致性的状态转换到另一个一致性的状态。（其实原子性和隔离性间接的保证了一致性） 隔离性（isolation）： 通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的。 持久性（durability）： 一旦事务提交，则其所做的修改就会永久保存到数据库中。 而我们最常说的隔离性其实有对应的隔离级别，MySQL规定的隔离级别有4种，分别是： READ UNCOMMITTED（读未提交）： 在此级别里，事务的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，也就是会产生 脏读 ，在实际应用中一般很少使用。 READ COMMITTED（读已提交）： 大多数数据库系统的默认隔离级别都是它，但是MySQL不是。它能够避免脏读问题，但是在一个事务里对同一条数据的多次查询可能会得到不同的结果，也就是会产生 不可重复读 问题。 REPEATABLE READ（可重复读）： 该隔离级别是MySQL默认的隔离级别

前言 刚接触 Java IO 的时候， 一直有一个 困惑：为什么 BufferedInputStream 比 FileInputStream 快? 随着对 Linux 了解，这个问题也得到解决。最近也在看 Linux 内核 方面的书，想了解程序在 Linux 上运行的过程，感觉收获还是很多的。 基于安全考虑，只有 Linux内核 才能权限去访问计算机的硬件， Linux内核 会提供一些接口（系统调用）让我们可以和硬件交互。不过数据一般都是从 硬件 到 内核态 ,再从 Linux内核 复制到 用户态 进程的内存空间中，这样进程才能对读取的数据进行处理。 本文内容： Linux 中的虚拟文件系统介绍 Page Cache 和 Dirty Page Java api 写入的数据，什么时候会被刷新到磁盘中 Linux 中 虚拟文件系统（VFS） 虚拟文件系统（Virtual File System，简称VFS）是Linux内核的子系统之一，它为操作文件（普通文件，socket 等）提供了统一的接口，屏蔽不同的硬件差异和操作细节。我们只需调用 open 、 read 、 write 、 close 、 fsync 这些系统调用，达到操作文件的目的。 我们实际看到的 linux的目录，实际就是 VFS 中的路径，我们可以通过将硬盘中的分区挂载到 linux 中的路径下

主键索引、唯一键索引、普通索引、全文索引、组合索引。 主键设置为自增，数据库会使用自增锁来维护主键的有序性；索引设置为自增，可以方便管理索引，否则会涉及到页分裂与列合并，影响性能 覆盖索引：一张表有两个列Id，Name，select id from table where Name = '';只需要查找Name的B+Tree不需要在去查找Id的，这种情况加做覆盖索引； 回表操作指的是InnoDb，InnoDb非主键索引存储的不是行数据，所以有回表；MyISam索引表中存储的是数据的地址，所以不存在回表； 组合索引：设计到最左匹配原则，建立索引的时候，需要注意索引列的顺序；维护一个name，age组合索引，当where条件为age=10，组合索引会失效，因为最左原则，name都没有，就没有必要查下去了，如果where name=‘aaa’，该组合索引是有效的，相当于先查name，再查age； 索引下推：简历组合索引，name，age，入下图数据，相当于对mysql索引查询的优化，索引下推之前，根据name条件查询出符合的数据，然后根据ID，在去Id索引表查询数据并比较age值；索引下推，根据name条件查询出符合的数据，在匹配age条件，符合条件的Id返回去； 持久性 通过redo log实现 数据插入数据库：数据插入会保存在用户态的某块内存中，数据积累到一定数量回进行系统调用

十四、PostgreSQL 12.2企业级应用系列公开课：调优系列公开课(一) 1、如何获得慢查询的SQL语句 2、常见参数设置因子与应用案例 2.1、shared_buffers 2.2、wal_buffers 2.3、work_mem 2.4、maintenance_work_mem 2.5、fsync 2.6、synchronous_commit 2.7、checkpoint_timeout，checkpoint_completion_target 2.8、default_statistics_target 3、pg_stat_statements部署与使用 3.1、查看TOP 5 最耗时sql语句 3.2、查看执行次数最多的sql语句 3.3、.... 本课程做为PG调优线上技术沙龙的第一篇，抛砖引玉的解释数据库调优的基础框架。后续的公开课将Oracle的调优思路与PG的相互借鉴，起到触类旁通的作用。 时间：2020-06-13 20:00-21:00 注：PostgresSQL 12.2 企业级课程系列公开课，是由北京CUUG的陈老师制作讲解，内容涉及到企业中常用到的一些技术，比如备份恢复、PITR、流复制、双机热备、单表查询成本估算、可见性验证、Autovacuum调优、事务隔离级别、并行查询调优、等一系列内容，免费公开课，欢迎大家参与学习。 关于PGCA和PGCE认证

对于在不同 Unix 系统之间移植程序，最重要的事情就是确定新系统的一些编译时、运行时固定或不固定的限制值了。例如文件路径最大长度 PATH_MAX、进程最大可打开文件句柄数 OPEN_MAX、用户可加入的附加用户组最大数量 NGROUPS_MAX、进程命令行参数最大字节数 ARG_MAX、内存页大小 PAGESIZE、线程栈大小默认值 STACKSIZE、临时文件最大数量 TMP_MAX 等等。甚至有些系统特征也可以通过查询来提前确定，例如是否支持读写锁、是否支持异步 IO、是否支持实时信号等等，这样程序就可以根据系统提供的能力来选择不同的接口去实现同样的功能。 回头来看 apue 第二章有关系统限制与选项这一块的内容，由于掺杂了 UNIX 标准化的内容，显得很没有条理，例如将各种限制按标准划分为： ISO C 编译时限制 （头文件常量） POSIX 不变的最小值 （声明遵循 POSIX 的系统必需支持到至少这么多，不能再小了） 不变值 （SSIZE_MAX） 运行时可增加的值 运行时不变的值 路径名可变值 XSI 不变的最小值 （同上） 数值限制 运行时不变值 看得人一头雾水，其实如果抛开标准，单按限制的性质来分，就比较简单啦： 编译时限制 （通过头文件常量） 运行时限制 不与文件系统相关部分（通过 sysconf） 与文件系统相关部分（通过 pathconf） 也就是说

一封报警邮件，大量服务节点 redis 响应超时。 又来，好烦。 redis 响应变慢，查看日志，发现大量 TimeoutException。 大量TimeoutException，说明当前redis服务节点上已经堆积了大量的连接查询，超出redis服务能力，再次尝试连接的客户端，redis 服务节点直接拒绝，抛出错误。 那到底是什么导致了这种情况的发生呢？ 总结起来，我们可以从以下几方面进行关注： 一、redis 服务节点受到外部关联影响 redis服务所在服务器，物理机的资源竞争及网络状况等。同一台服务器上的服务必然面对着服务资源的竞争，CPU，内存，固存等。 1、CPU资源竞争 redis属于CPU密集型服务，对CPU资源依赖尤为紧密，当所在服务器存在其它CPU密集型应用时，必然会影响redis的服务能力，尤其是在其它服务对CPU资源消耗不稳定的情况下。 因此，在实际规划redis这种基础性数据服务时应该注意一下几点： 1）一般不要和其它类型的服务进行混部。 2）同类型的redis服务，也应该针对所服务的不同上层应用进行资源隔离。 说到CPU关联性，可能有人会问是否应该对redis服务进行CPU绑定，以降低由CPU上下文切换带来的性能消耗及关联影响？ 简单来说，是可以的，这种优化可以针对任何CPU亲和性要求比较高的服务，但是在此处，有一点我们也应该特别注意：我们在

十四、PostgreSQL 12.2企业级应用系列公开课：调优系列公开课(一) 1、如何获得慢查询的SQL语句 2、常见参数设置因子与应用案例 2.1、shared_buffers 2.2、wal_buffers 2.3、work_mem 2.4、maintenance_work_mem 2.5、fsync 2.6、synchronous_commit 2.7、checkpoint_timeout，checkpoint_completion_target 2.8、default_statistics_target 3、pg_stat_statements部署与使用 3.1、查看TOP 5 最耗时sql语句 3.2、查看执行次数最多的sql语句 3.3、.... 本课程做为PG调优线上技术沙龙的第一篇，抛砖引玉的解释数据库调优的基础框架。后续的公开课将Oracle的调优思路与PG的相互借鉴，起到触类旁通的作用。 来源： oschina 链接： https://my.oschina.net/u/4312354/blog/4307792

redo log(重写日志) redo log的特点 redo log是用来实现原子性和持久性。 redo log由重做日志缓冲区(内存中)和重做日志文件文件（磁盘中）两部分组成。 redo log是物理日志，记录的是页的物理修改操作。 流程 在InnoDB存储引擎中，通过Force Log at Commit机制实现事务的持久化； 当事务提交时，必须先将该事务的redo log写入到重做日志文件中进行持久化，待事务的commit操作完成才算完成。 Innodb_flush_log_at_trx_commit参数用来控制日志刷新到磁盘的策略： 参数： 0：事务提交时不进行写入重做日志操作，而是由主线程完成，主线程每秒执行一次重做日志的fsync操作； 1：事务提交时必须调用一次fsync操作，默认值； 2：事务提交时将重做日志写入重做日志文件，但仅写入到文件系统的缓存，不进行fsync操作。由文件系统触发fsync操作。 undo log undo log的特点 undo log 用来实现一致性，用于回滚和MVCC undo log 记录的是逻辑日志 undo log 记录的是反操作，比如对于每一个INSERT会有一个对应的DELETE，UPDATE会有个反的UPDATE操作 来源： oschina 链接： https://my.oschina.net/u/4295823/blog

提起MySQL，其实网上已经有一大把教程了，为什么我还要写这篇文章呢，大概是因为网上很多网站都是比较零散，而且描述不够直观，不能系统对MySQL相关知识有一个系统的学习，导致不能形成知识体系。为此我撰写了这篇文章，试图让这些底层架构相关知识更加直观易懂： 尽量以 图文 的方式描述技术原理； 涉及到关键的技术，附加 官网 或者 技术书籍 来源，方便大家进一步扩展学习； 涉及到的 背景知识 尽可能做一个交代，比如讨论到log buffer的刷盘方式，延伸一下IO写磁盘相关知识点。 好了，MySQL从不会到精通系列马上就要开始了（看完之后还是不会的话..请忽略这句话）。 可能会有同学问：为啥不直接学更加先进的TiDB，或者是强大的OceanBase。 其实，MySQL作为老牌的应用场景广泛的关系型开源数据库，其底层架构是很值得我们学习的，吸收其设计精华，那么我们在平时的方案设计工作中也可以借鉴，如果项目中用的是MySQL，那么就能够把数据库用的更好了，了解了MySQL底层的执行原理，对于调优工作也是有莫大帮助的。本文我重点讲述MySQL底层架构，涉及到： 内存结构 ： buffer pool 、 log buffer 、 change buffer ，buffer pool的页淘汰机制是怎样的； 磁盘结构 ： 系统表空间 、 独立表空间 、 通用表空间 、 undo表空间 、 redo

一安装 >=PHP7.0 >=Centos7.0 yum install beanstalkd --enablerepo=epel 启动： /usr/bin/beanstalkd -l 0.0.0.0 -p11300 -b /var/lib/beanstalkd/binlog -F & 参数： /usr/bin/beanstalkd -h Use:/usr/bin/beanstalkd [OPTIONS] Options: -b 开启binlog，断电后重启会自动恢复任务。 -f MS fsync最多每MS毫秒-F从不fsync（默认） -l ADDR侦听地址（默认为0.0.0.0） -p端口侦听端口（默认为11300） -u USER成为用户和组 -z BYTES设置最大作业大小（以字节为单位）（默认值为65535） -s BYTES设置每个wal文件的大小（默认为10485760） （将被舍入到512字节的倍数） -c压缩binlog（默认） - n 不要压缩binlog -v显示版本信息 -V增加冗长度 -h显示这个帮助 配置文件： /etc/sysconfig/beanstalkd 二PHP操作 来源： oschina 链接： https://my.oschina.net/songms/blog/4347999