本文主要讨论用户记录存储相关的数据页面(索引页和外部存储页)的物理结构以及组织方式。InnoDB用B+树的方式管理用户记录数据,每个索引对应一个B+树。B+树是通过索引页构建的,用户记录的数据存储在聚簇索引的叶子结点中。如果有变长字段(如text、blob、varchar)的长度过长,则可能会将该字段的全部数据或部分数据存储到外部存储页(blob页面)。
最近我们发现在Read Committed隔离级别下出现了S类型的Gap锁参与的死锁告警。 本身RC隔离级别上出现Gap锁就很诡异了,更诡异的是两条看起来完全不相干的SQL发生了死锁。让我们一起来分析一下吧。
在之前的公众号文章《GTID实践和分析》中介绍了GTID的基本原理,MySQL主要通过Server引擎的binlog文件和Innodb的mysql.gtid_executed表来持久化GTID集合信息。在提交时会将分配给事务的GTID刷到binlog文件中,在事务成功提交后会将GTID加入内存的executed_gtids集合中,并周期性持久化到mysql.gtid_executed表中。在实例恢复时可以从mysql.gtid_executed表+最后一个binlog文件中的GTID信息来恢复executed_gtids集合,从而保证GTID的完整性。
K8s社区主要通过Extender Resource和Device Plugin方式给为用户提供GPU物理资源支持。 每个GPU厂商都会实现自己的Device Plugin Agent,Agent在底层节点层会将物理卡扫描上报到集群。用户用拓展资源方式在Pod创建时指定需要物理卡的数量,Device Plugin在每个Kubelet节点上做启动,并且调用各个GPU厂商的设备工具,将设备卡资源扫描上报。
本文主要介绍如何在腾讯云平台下自建高可用DNS环境,来满足企业在云上的内外网域名解析的需求。这里主要介绍两种方案的实现方式,方案一: 基于Centos 系统自带的Bind软件构建智能解析方案;方案二:基于CoreDNS与ETCD来构建CoreDNS高可用方案,在阐述两个方案实现的前,咱们一起回顾下DNS的基础概念及原理。
本文将从一个普通开发者的角度去探索Kubernetes,从应用部署方式的演变方式说起,再到搭建一个简易的K8s集群,去了解它的资源管理方式,然后再去实战。当对K8s有了一定了解后,再将其中的核心组件的原理进行剖析,从而深入理解Kubernetes的原理与架构。相信可以在读完本文后对Kubernetes有一个初步认识。