首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    MySQL8.0 redo日志系统优化

    现在主流的数据库系统的故障恢复逻辑都是基于经典的ARIES协议,也就是基于undo日志+redo日志的来进行故障恢复。redo日志是物理日志,一般采用WAL(Write-Ahead-Logging)机制,所以也称redo日志为wal日志,redo日志记录了所有数据的变更,undo日志是逻辑日志,记录了所有操作的前镜像,方便异常时进行回滚。用户在提交事务时,只要确保写redo日志成功即可,并不需要对应的数据页也实时落盘,这套机制的基本思想是利用空间换时间,用户事务的更新实际上在数据页和redo日志中记录了两份,传统的数据库存储引擎都是基于B+Tree来组织数据页,因此刷数据页是离散小块IO,而写redo是顺序IO,对磁盘介质更友好,而且OLTP场景下,业务对RT(ResponseTime)也比较敏感,所以这套机制非常流行。

    02

    MySQL异常访问的熔断机制

    网上搜了下,问题原因就是同一个IP在短时间内产生太多(超过MySQL数据库max_connection_errors的最大值)中断的数据库连接而导致的阻塞,按照他所说的,max_connect_errors是一个MySQL中与安全有关的计数器值,他负责阻止过多尝试失败的客户端以防止暴力破解密码的情况,max_connect_errors的值与性能并无太大关系。这个设计倒是和Oracle中的密码延迟验证功能有些相似,在Oracle中,随着密码输入错误次数,延迟验证时间会逐步增加(可参考《登录缓慢的诡异问题》),同样都是为了防止账号密码被暴力破解。但是Oracle的这个机制可能回导致其他用户受到影响,或者出现严重的library cache lock等问题,而MySQL的机制很彻底,就是让这个IP不能登录,对其他人没影响,不会导致其他的性能问题。

    01

    MySQL异常访问的熔断机制

    网上搜了下,问题原因就是同一个IP在短时间内产生太多(超过MySQL数据库max_connection_errors的最大值)中断的数据库连接而导致的阻塞,按照他所说的,max_connect_errors是一个MySQL中与安全有关的计数器值,他负责阻止过多尝试失败的客户端以防止暴力破解密码的情况,max_connect_errors的值与性能并无太大关系。这个设计倒是和Oracle中的密码延迟验证功能有些相似,在Oracle中,随着密码输入错误次数,延迟验证时间会逐步增加(可参考《登录缓慢的诡异问题》),同样都是为了防止账号密码被暴力破解。但是Oracle的这个机制可能回导致其他用户受到影响,或者出现严重的library cache lock等问题,而MySQL的机制很彻底,就是让这个IP不能登录,对其他人没影响,不会导致其他的性能问题。

    02

    2021年大数据HBase(十四):HBase的原理及其相关的工作机制

    flush溢写流程:   hbase 2.0版本后的流程       随着客户端不断写入数据到达memStore中, memStore内存就会被写满(128M), 当memStore内存达到一定的阈值后, 此时就会触发flush刷新线程, 将数据最终写入HDFS上, 形成一个StoreFile文件 1) 当memStore的内存写满后, 首先将这个内存空间关闭, 然后开启一个新的memStore, 将这个写满内存空间的数据存储到一个pipeline的管道(队列)中 (只能读, 不能改) 2) 在Hbase的2.0版本后, 这个管道中数据, 会尽可能晚刷新到磁盘中, 一直存储在内存中,  随着memStore不断的溢写, 管道中数据也会不断的变多 3) 当管道中数据, 达到一定的阈值后, hbase就会启动一个flush的刷新线程, 对pipeline管道中数据一次性全部刷新到磁盘上,而且在刷新的过程中, 对管道中数据进行排序合并压缩操作, 在HDFS上形成一个合并后的storeFile文件

    02

    Kafka环境搭建

    在异步交互模式中,我们经常会谈到消费者与生产者的模式,在这中间会使用到主流的MQ的中间件,主要为Kafka和RabbitMQ的中间件。当然也可以说是消息队列,由于在同步交互的模式中存在延迟的缺陷,那么也就说是在高并发的应用场景下,使用同步交互的模式显然是不合理的,就需要使用异步的消息队列来解决这个过程中消息的堵塞和积压。比如大量的请求对底层的DB进行请求,请求过多导致DB层面的连接数占用资源得不到释放,从而导致Too Many Connections等其他的异常信息。当然基于这样的场景很多的,因此就需要一个缓冲机制来解决这类的问题,而消息队列可以很好的解决这类堵塞以及积压的问题,准确的说消息队列通过异步处理请求来缓解系统的压力。消息队列拥有先进先出的特性,主要应用于不同进程或线程之间的通信机制,来处理输入的请求。在异步通信的机制中,客户端与服务端不需要知道对方的存在,更多关注的是MQ的消息,如下所示:

    03
    领券