XJC's Journal Container

In this post, we’ll explore how Serializable Snapshot Isolation (SSI) addresses concurrency anomalies under Snapshot Isolation (SI). Although SI already provides good performance in many systems, it can still lead to anomalies such as Write Skew. We’ll walk through why SI can fail in certain cases and how SSI fixes these issues with a relatively small overhead and a clever conflict detection mechanism. Introduction This post focuses on Isolation in the context of single-node databases (i.

Continue reading 

Configure your blog to past SSL Server Test

Continue reading 

NTP 本篇博文来自我和gpt-o1的对话 网络时间协议（Network Time Protocol, NTP）是一种用于在计算机系统之间同步时间的协议，它能够提供高精度的时间校准，并在网络延迟和抖动（jitter）的影响下保持较高的时间一致性。 核心概念 时间同步： NTP 的目标是确保分布式系统中的设备与参考时钟（通常是全球的原子钟或 GPS 时钟）保持时间同步。 它不仅提供绝对时间（如 UTC），还能校正因网络延迟导致的时间偏差。 分层架构（Stratum Levels）： NTP 使用分层架构，每一层称为一个 “层级（Stratum）"： Stratum 0：参考时钟，例如原子钟、GPS 接收器等。 Stratum 1：直接连接到参考时钟的设备，称为主时间服务器。 Stratum 2+：通过 NTP 协议从上层同步的设备。层级越高，离参考时钟越远，精度越低。 客户端-服务器模式： NTP 通常采用客户端-服务器模式： 客户端向 NTP 服务器发送请求，服务器回复时间信息。 客户端根据收到的信息计算与服务器的时间偏差，并调整本地时钟。 对称模式： 在对等网络中，设备既可以充当客户端，也可以充当服务器，彼此交换时间信息。 时钟模型： NTP 使用一种加权平均的算法来结合多个时间来源的信息，从而提高时间同步的精确性和鲁棒性。 计算时间戳 要计算NTP协议中的四个时间戳（T1、T2、T3、T4），我们需要模拟客户端（c1）和服务器（c2）之间的时间同步过程，并考虑它们的时钟速率和网络延迟。 假设： c1的时钟速率（ρ₁）：0.95（比真实时间慢） c2的时钟速率（ρ₂）：1.01（比真实时间快） 网络延迟（从c1到c2）：d₁ = 0.1秒 网络延迟（从c2到c1）：d₂ = 0.2秒 服务器处理时间：p = 0.05秒 初始同步时间：t₀ = 0秒 步骤1：计算c1和c2在t₀ + 10秒时的时钟时间 真实时间经过：10秒 c1的时钟时间： ( T_{c1} = t₀ + \text{真实时间} \times \rho₁ = 0 + 10 \times 0.

Continue reading 

TL, DR 能原地扩容就原地扩容, 不能的时候就迁移. 迁移的本质是一个 bin packing problem. Aurora 采用了反应式MCDM迁移决策算法, 但具体的屁都没说. Intro 无服务器这个需求很容易理解. 没有Serverless, 用户需要自己预估工作负载购买合理容量的计算资源, 设计扩容缩容策略, 甚至还要自己负责安全, 软件更新, OS tuning等等工作. 并不是所有用户都有精力自己搞定这些, 相当一部分用户更愿意专注在业务逻辑的开发上, 这有助于他们早日实现生意的成功. Aurora Serverless中将资源抽象为了ACU, 一个ACU定义为2GB内存以及与之配套的CPU, 网络, IOPS等计算资源的集合. 用户只需要指定资源用量(预算)上下界, 然后就可以开使干活儿了. 当然, Serverless只是一个用户视角的称呼, 服务器并不是真的消失不见了. 真正的服务仍然运行在某一台机器中, 云服务提供商需要来负责orchestration. Aurora Serverless的论文里主要讨论了两个问题的解决方案: 1) 什么时候扩容/缩容. 2) 扩缩容时发生需要迁移的情况时, 把谁迁移到哪儿? 在Aurora中, 这两个问题由Fleet级的决策系统和Host级的决策系统的组合来解决. 开始讨论之前先澄清一些词汇. Fleet: 一组物理机器组成的集群, 每个AZ都有一个fleet. Host: 一台物理机. Instance: 一台VM. Fleet级 迁移 舰队资源管理器的一个重要的职责是定期轮询监控实例的情况, 并执行以下三步: 1. 决定哪些主机需要迁出 对于每个主机, 舰队管理器会通过定期查看该主机上的每个实例的预留ACU的和是否超过了阈值(多少没说)判断主机是否过热, 过热就迁出. 论文里说了判断过热后会继续判断是否有足够网络带宽自持迁出, 但也没说不支持的时候会怎么办. 2. 决定从主机上迁出哪些实例 考量有3: CPU,网络占用大的可能合适. memory map大小和脏页率影响迁移时间. 公平, 不要频繁迁移一个实例.

Continue reading 

Resource Management in Aurora Serverless 摘要 Amazon Aurora Serverless 是 Amazon Aurora 的一种按需自动扩展配置，完全兼容 MySQL 和 PostgreSQL。它根据客户数据库应用程序的需求自动提供容量扩展/缩减(即垂直扩展)。通过这种方式，它使客户无需显式管理其数据库容量；客户只需使用一个简单易懂的多资源容量抽象概念——Aurora 容量单位(ACU)来指定最小和最大边界。对于工作负载随时间变化的客户，由于其灵活和细粒度的扩展以及基于使用的计费模式，与预置的 Aurora 或其他替代方案相比，它可以节省成本。本文描述了 Aurora Serverless 资源管理的关键思想。为了帮助实现其目标，Aurora Serverless 采用并微调了与资源过度订阅相关的成熟思想；基于近期测量的反应式控制；分布式和分层决策；以及数据库引擎、操作系统和虚拟机管理程序在效率方面的创新。也许最具挑战性的目标是在以高度利用率运行主机的同时提供一致的资源弹性体验。Aurora Serverless 实现了几个新颖的想法，以在这些相互对立的需求之间取得平衡。其将工作负载映射到主机的技术确保在常见情况下，主机内有足够的备用容量来支持工作负载的快速扩展。在罕见的情况下，如果不是这样，它被设计为实时迁移工作负载以确保无缝扩展。其负载分配策略的特点是跨主机"不平衡"负载，以实现灵活的实时迁移。最后，它采用基于令牌桶的速率调节机制，以防止不断增长的工作负载在基于实时迁移的补救措施之前使其主机饱和。 1 引言和动机 Amazon Aurora [1] 是一种现代关系数据库服务，为完全开源的 MySQL 和 PostgreSQL 兼容版本提供大规模的性能和高可用性保证 [37]。2014 年推出的原始预置 Aurora 产品允许客户选择按需实例（虚拟机），按小时付费使用数据库，无需长期承诺或预付费用，或选择预留实例以获得额外优惠 [2]。最近，Amazon 开始提供 Aurora Serverless [3]，这是 Amazon Aurora 的一种按需自动扩展配置。Aurora 提供的自动扩展能力是向上/向下扩展（即单个数据库实例分配资源的"垂直"扩展），而不是某些其他系统提供的横向扩展（“水平"扩展）。Aurora Serverless 旨在快速扩展数据库工作负载，从每秒数百次事务到数十万次事务。第一个 Aurora Serverless 产品（ASv1）于 2018 年 8 月推出，而最新产品（ASv2）于 2022 年 4 月发布。 为什么选择 Aurora Serverless？Aurora Serverless 的主要卖点是它在很大程度上减轻了客户管理其数据库资源容量如何响应动态工作负载的需求。客户无需预先选择特定的实例大小或配置，只需以称为 Aurora 容量单位（ACU）[4] 的单位指定数据库容量。每个 ACU 是 2 GB 内存、相应的 CPU、网络和块设备 I/O 吞吐量的组合。Aurora Serverless 根据应用程序需求，在客户指定的（最小，最大）ACU 范围内持续自动扩展客户数据库集群中的每个写入器或读取器。与预置的 Aurora 或其他替代方案相比，Aurora Serverless 因以下原因带来的成本节省和便利性而吸引各种客户：

Continue reading 