高清PDF：阿里云主备切换和跨可用区迁移示意图高清VISIO：阿里云主备切换和跨可用区迁移示意图先说结论：阿里云说的发生切换时（不管是主备切换还是跨可用区切换），影响时间是30秒内，这个是基本成立的。测试是每种场景测试4~5次，观察其平均效果。主备库切换迁移可用区MySQL只读：1秒只读：10~20秒PostgreSQL断联：1秒只读：8~9秒正常读写：5~30秒断联：1秒只读：8~9秒 汇总：影响20秒左右只读：8~9秒断联：1秒正常读写：5秒断联：1秒只读：15秒~30秒 汇总：影响约30秒MongoDB（非分片）只读：25秒断联：12秒汇总：影响37秒有条件的只读（需要执行rs.slaveOk()才能只读）：16~26秒断联：2秒有条件的只读（需要执行rs.slaveOk()才能只读）：4~11秒汇总：影响40秒内 （一）MySQL：1. 运行压测语句：while true do RUN_FLAG=`ps -ef |grep sysbench |grep run |grep -v grep |wc -l` if [ ${RUN_FLAG} -lt 1 ]; then sysbench oltp_read_write --mysql-host=xxxxxxxxxx.rds.aliyuncs.com --mysql-port=3306 --mysql-user=myus ...继续阅读 (6)

几百个微服务的用户，都用了同一个用户user1来连接数据库。如果要修改user1的用户，会导致几百个微服务都要在同一时间内重启，业务不太接受这种方式，业务希望用灰度的方式逐步切换。因此可以采用代理用户的方式来修改密码。大致步骤：（1）假如平时用的用户叫user1，创建代理用户 create user proxy_user1 identified by PASSWORD;（2）alter user uese1 grant connect throgh proxy_user1（3）应用【逐个切换】切换到代理代理用户proxy_user1，需要注意的地方，是连接方式修改了。 本来是 conn user1/passwd_of_user1，现在是要 conn proxy_user1[user1]/passwd_of_proxy_user1. 需要应用逐个修改连接方式。用代理用户的密码来登录。（4）全部应用的连接，切到代理用户之后，修改原来的user1的密码。（5）修改user1为新密码（6）应用逐个切回user1检查当前的连接，是否有使用代理用户（在v$session是看不到代理用户，只能看到被代理的用户，需要配合v$session_connect_info 看）。select s.sid, s.serial#, s.username, s.osuser, sci.authenticatio ...继续阅读 (5)

PDF文件（高清）：Amazon Aurora DSQLFreeMind文件（源文件）：Amazon Aurora DSQL.mm（思维导图太大了，blog放不下，各位可以选取PDF来看，比较清晰。）参考：【AWS re:Invent 2024】​​AWS re:Invent 2024 – Dr. Werner Vogels KeynoteAWS re:Invent 2024 – Deep dive into Amazon Aurora and its innovations (DAT405)AWS re:Invent 2024 – Get started with Amazon Aurora DSQL (DAT424)AWS re:Invent 2024 – Deep dive into Amazon Aurora and its innovations (DAT405)AWS re:Invent 2024 – Deep dive into Amazon Aurora DSQL and its architecture (DAT427-NEW)【Marc Brooker的博客, AWS VP and Distinguished Engineer】DSQL Vignette: Aurora DSQL, and A Pers ...继续阅读 (33)

在任何数据库管理系统（DBMS）中，并发控制在确保多个事务能够同时进行而不会导致数据不一致或损坏方面起着至关重要的作用。它指的是管理事务如何交互的机制，特别是在它们访问共享资源时。分布式数据库管理系统（D-DBMS）由于数据分布在多个节点上而引入了复杂性，导致了数据复制、网络延迟和保持一致性等挑战，这使得并发控制的重要性更加突出。在设计高效扩展的分布式系统时，避免持续协调变得至关重要。通过这样做，组件必须对其他组件的状态做出假设，因为它们不能持续检查。这些假设可以分为乐观和悲观。乐观假设是乐观并发控制（OCC）的核心，假设冲突很少发生，允许事务在没有锁的情况下进行，并在发生冲突时解决。这种方法在分布式环境中特别有用，可以增强可扩展性，但需要强大的冲突检测和解决机制来保持ACID属性——在系统中保持原子性、一致性、隔离性和持久性。悲观假设是悲观并发控制（PCC）的基础，假设冲突是常见的，并在事务期间对资源实施锁定以防止干扰。尽管这提供了一致性，但它可能会限制可扩展性和性能。选择OCC还是PCC取决于您的系统是更受益于避免早期协调并在后期解决冲突，还是通过提前控制来防止任何事务冲突。在这篇文章中，我们深入探讨了并发控制，提供了有关设计高效事务模式的宝贵见解，并展示了有效解决常见并发挑战的示例。我们还包括一个示例代码，展示如何在Amazon Aurora DSQL（DSQL）中实现重试模 ...继续阅读 (17)

关系数据库是各种应用程序和服务的强大且灵活的构建模块——从微服务和网站，到移动后端和SaaS应用程序。十年前，我们推出了Amazon Aurora，提供了无与伦比的高性能和高可用性，并完全兼容MySQL和PostgreSQL，成本仅为商业数据库的十分之一。我们听到客户希望有一种关系数据库，更易于管理，能够根据工作负载进行扩展，并且更容易构建高可用的多区域和多可用区架构。今天，我们介绍Amazon Aurora DSQL，这是用于始终可用应用程序的最快的无服务器分布式SQL数据库。它提供几乎无限的扩展性、最高的可用性和零基础设施管理。它可以在不进行数据库分片或实例升级的情况下扩展以满足任何工作负载需求。凭借其创新的主动-主动分布式架构，Aurora DSQL在单区域配置中设计为99.99%的可用性，在多区域配置中设计为99.999%的可用性，使其成为构建高可用性应用程序的理想选择。其无服务器设计消除了补丁、升级、维护停机等操作负担。Aurora DSQL还提供了简单的体验，从几步快速创建数据库开始。Aurora DSQL兼容PostgreSQL，使开发人员能够使用熟悉的关系数据库概念以及他们已经熟悉的驱动程序、工具和框架快速构建和部署应用程序。在这篇文章中，我们讨论了Aurora DSQL的优势以及如何开始使用。Aurora DSQL架构和优势Aurora DSQL设计有两种配置：一 ...继续阅读 (17)

在测试阿里云的sqlserver到mysql的dts同步，且是带过滤条件的同步，发现更新有个“能增不能减”的问题。在做带过滤的update，把过滤字段更新成其他值，目标端只能增不能减。—— 即过滤字段update成过滤条件，在目标端会增加改行记录； 过滤字段从符合过滤条件update成不符合过滤条件，在目标端不会自动删除该行记录。看下面的例子：dts实例id ： dtshrj10404232y2vg源端：sqlserver： 实例id：rm-wz97281ap59lcz4md目标端：mysql： 实例id：rm-wz94c40229w5qdze1过滤条件，table1的myid字段， myid=5Case a：（一） 更新前：源端（sqlserver）：目标端（mysql）：（二） 执行更新sqlserver：（三） 更新后源端（sqlserver）：目标端（mysql）：Case b：（一） 更新前： 源端（sqlserver）：目标端（mysql）：（二） 执行更新：（三） 更新后：源端（sqlserver）：目标端（mysql）：原因分析：我们在测试sqlserver到mysql的，带过滤条件的dts同步，update过滤字段，同步能增加不能减少，如，我的过滤条件为myid=5a）比如 update table set myid=5 where myid=4 ，即将不符合过滤 ...继续阅读 (42)

开发希望多个系统联调，能自己在一个大集中环境部署一个数据库，然后创建多个实例。那么是可以在一个数据库中配置一个类似的高权限用户（该用户和高权限用户一样权限，但是在界面中看到是普通用户），然后再建库和建用户的。-- 创建应用管理用户app_admin： create user app_admin identified by; -- 对应用管理用户授权： grant ALTER,ALTER ROUTINE,CREATE, CREATE VIEW,CREATE ROUTINE,CREATE USER, CREATE TEMPORARY TABLES,DELETE,DROP,EVENT, EXECUTE,INDEX,INSERT,LOCK TABLES,PROCESS,RELOAD, REFERENCES,REPLICATION SLAVE,REPLICATION CLIENT ,SELECT,SHOW VIEW,TRIGGER,UPDATE on *.* to app_admin WITH GRANT OPTION; -- 用应用管理用户app_admin连接，进行创建各个数据库，并进行授权： -- 创建数据库和每个库testdb对应的用户app_rwcreate database testdb2 character set utf8mb4; create user app_ ...继续阅读 (21)

一个500GB的mysql数据库，需要做跨vpc的迁移，可以有下面的方法：1. mysqldump做导出导入，需要一个能连通vpc A和vpc B的机器，做跳板机，且要准备比较大的空间放导出文件。准备时间：准备申请一个跳板机，开通跳板机连通2个vpc的操作时间。需要负责计算资源的同学和负责数据库的同学配合。迁移时间：导出+导入，迁移期间需要停业务，预估在8小时左右的时间。2. 同账号同区域快照复制准备时间：不需要额外准备，只需要业务方沟通停机时间。操作上没有其他依赖资源，只需负责数据库的同学操作。迁移时间：停应用后打DB快照+快照还原+恢复multiaz架构。迁移期间需要停业务，预估3小时左右。3. dms做同步，需要开通两个vpc的vpc peering。准备的时间：开通vpc peering+配置好路由表，测试dms是否正常能通过vpc peering进行数据同步，需要手动迁移元数据防止dms不能同步mysql secondary index。需要负责网络的同学和负责数据库的同学配合。迁移时间：分钟级切换。4. mysql binlog replication，复制从库副本到主力vpc，然后利用mysql的原生主从进行同步（需要vpc peering）。准备时间：开通vpc peering，测试副本复制+原生同步，需要负责网络的同学和负责数据库的同学配合。迁移时间：分钟级切换另 ...继续阅读 (19)

有朋友提到最近最近比较热门的pg数据库和AI结合，提到了PGAI和postgres.new，看了相关资料。PDF文件：pgai和postgres.newFreeMind文件：pgai和postgres.new.mm ...继续阅读 (17)

数据传输工具，在全量同步中，往往是并发执行的，dts有个重写逻辑，是：1）DTS碰到死锁的时候，会当前session中重试，继续写入数据。比如：DTS一批写入1024条数据，写到第1000条失败了，会在当前session中继续从头写入这1024条数据。这个过程可能会出现数据重复写入，会发生主键冲突。2）DTS写入检测到主键冲突报错，就会将insert转换成delete + insert执行，先对当前1024条做delete操作，删除完成后，做insert操作。因此，在某些场景下，会导致不断删除重写数据，导致产生大量的事务日志。比如oracle的bitmap索引，会enq-TX mode=4的锁堵塞，进而产生死锁，进而引发问题：并且在后续，不仅出现insert对insert的死锁，由于dts还要删除数据，会delete数据，因此然后又加上了delete和insert的死锁，后续还有delete和delete的死锁。死锁的频率越来越高，重写次数越来越高，因此事务日志的量，可能会变成平时的10多倍，打爆磁盘空间，从而引发事故。 ...继续阅读 (27)

在一个8c16g的阿里云mysql上进行sysbench，在run 压测的时候，报错max_prepared_stmt_count不够了：sysbench oltp_read_write --mysql-host=rm-wedtteessttm.mysql.rds.aliyuncs.com --mysql-port=3306 --mysql-user=**** --mysql-password=********* --mysql-db=testdb --tables=30 --table-size=500000 --threads=64 --time=600 --report-interval=10 runmax_prepared_stmt_count的值，可以参考下面的表格进行设置：测试模型prepare语句数量计算公式oltp_read_only线程数 * 表数量 * 5 + 线程数oltp_write_only线程数 * 表数量 * 4 + 线程数oltp_read_write线程数 * 表数量 * 9 + 线程数oltp_insert0. (oltp_insert场景没有prepare语句)在MySQL中，可以使用prepare来进行sql的预编译处理，pg也有，oracle也有，sqlserver也有。注意这里的prepare是指prepare-statement，而不是 ...继续阅读 (29)

用一个8c16g共享型的mysql，同步到4c8g的共享型mysql，利用sysbench 加载数据sysbench oltp_read_write --mysql-host=rm-xyetdtwsoistegdhed.mysql.rds.aliyuncs.com --mysql-port=3306 --mysql-user=**** --mysql-password=***** --mysql-db=testdb --tables=30 --table-size=500000 --threads=30 prepare进行dts同步，dts选择的类型是small，从深圳到香港。在配置任务对象时，对于table中的某个需要增加过滤条件的表，点击“编辑”，然后写上过滤条件：测试结果：1. 初始化时，id=5的数据能同步过去，其他数据不同步过去。2. 新增id=5的数据，能同步过去。即目标端新增数据。3. 删除id=5的数据，能同步过去，即目标端会减少数据。原来id=5的数据会被删除。4. 更新id=5的数据成id=6（按照过滤条件更新），能同步过去，即目标端会减少数据，原来id=5的数据更新成id=6后，目标端这些数据会被删除。注:在50万左右数据量，更新时，在small的dts实例下会导致延时，超过10分钟，可以通过扩容解决。参考：《过滤待迁移数据》 ...继续阅读 (34)

阿里云redis 主从版，HA切换（节点A为原主实例，切换到节点B），步骤和耗时分解：序号耗时（单位：毫秒）步骤名称备注16ms开始Switchover到实例B的流程244ms重新获取链路上的主节点A35ms获取A原主的角色40msKill原B节点上的连接55ms尝试连接master A630msKill master A上的连接75ms设置Master A为只读88ms设置Master A为只读成功910msKill master A上的连接101ms检查Slave，等待同步完成如果系统繁忙，在这一步等待同步完成的时间，会稍久11734ms切换VIP链路A为B120ms完成切换VIP链路A为B139msKill master A上的连接143ms设置节点的角色-升原B为新主1540ms设置节点的角色-降原主A为新备1644ms维护元数据信息 ...继续阅读 (36)

调整SET_TABLE_PREFS，按照表来单独设置，减低stale的百分比，比如变化1%就收集统计信息调整 ESTIMATE_PERCENT的比例，不用AUTO_SAMPLE_SIZE，而用更低的采样比例High-frequency Optimizer Statistics Collection自定义搜集统计信息的job，设置自定义的time intervalReal-time Statistics19c有实时统计信息，在display_cursor中可以看到 – dynamic statistics used: statistics for conventional DML配置参数：optimizer_real_time_statistics ，21c的参数backport到19c RU 10分区表：用Incremental Statistics，注意时长场景，时间窗口移动。“Out of Range” 场景：在range 分区表中比较常见，应对方法：DBMS_STATS.COPY_TABLE_STATS（注意，临时解决方案，还是需要搜集详细统计信息）另外，还可以通过分析数据增长或者变化的趋势，手动设置统计信息：DBMS_STATS.SET_COLUMN_STATSGATHERING STATISTICS MORE QUICKLYUsing ...继续阅读 (59)

2024年3月20号，Redis Lab宣布，从redis 7.4开始，redis的开源协议，将从宽松的BSD协议，使用者可以任意使用和商用，转成SSPL v1（Server Side Public License）和RSAL v2（Redis Source Available License）协议，使用者可以内部使用，但是不能商业化和提供给他人使用。这意味着，在没有得到redis官方的许可下，云厂商不能再继续免费试用redis的代码。注：SSPL：SSPL 是 MongoDB 创建的一个源码可用的许可证，以体现开源的原则，同时提供保护，防止公有云供应商将开源作品作为服务提供而不回馈此开源作品。SSPL 允许自由和不受限制的使用和修改开源作品，但如果你把此开源作品作为服务提供给别人，你也必须在 SSPL 下公开发布任何修改以及管理层的源代码。RSAL：RSAL是 Redis 授予的宽松、非排他性、免版税许可证。用于使用、分发和修改专为与 Redis 一起工作的某些软件组件，但须遵守协议中概述的特定限制和条件。看来，继Elasticsearch、MongoDB之后，redis也走上了对抗云厂商“白嫖”的道路。 —— 但是，云厂商是否真正“白嫖”，还是有大量反馈，这个公道自在人心，网上也有不少的文章，比如《Redis 社区的发展与国内开发者的贡献》那么，在redis改变开源协议之后，各 ...继续阅读 (58)

最近公司里，向量数据库的需求越来越多。前几天请aws的诸位专家一起来开会讨论了一下，学到了不少知识。以下是我的心得和收获，仅代表我个人观点：1. 知识库，图片识别，图片或视频近似度搜索，电商推荐等是很多公司的应用场景。2. 向量计算，这其实每个数据库都可以拥有这个功能，向量近似度计算的方法：余弦夹角，欧几里得距离，内积等等……知道了向量近似度算法，那么凡是数据库都可以根据算法写自己的实现过程，操作函数。3. 向量适合“语义模糊”的近似度检索，虽然左右两个百分号是模糊检索，但他其实还是精准检索，比如like ‘%深圳%’看上去是模糊检索，但是它还是需要精确匹配“深圳”关键字，它没办法搜索出来“当年在香港旁边画了一个圈的小渔村”。语义的近似查找，是向量数据库的主战场。4. 向量数据库，离开了模型是没有意义的。离开了模型，向量数据库中存在的只是一堆无意义的多维数组（但是最近有安全方面的论文说可以实现逆向工程）。模型+向量数据库，才是向量数据的生命周期。另外，更新了模型，原来存放的向量数据可能也没有意义了。5. 模型对原始数据的spliting，embedding，非常重要。常见模型有aws泰坦模型，Claude模型，stable diffusion模型，等等。6. RAG中的LLM如果数据不完善，可以通过外部多模数据的embedding，存入到向量数据库中进行修正 ...继续阅读 (50)

2023年11月27日，aws 宣布了他们的新的产品，aws无限数据库（limitless database）。我比较关注这个新产品，简单谈谈对他的看法。大部分的信息，是来自于《AWS re:Invent 2023 – Monday Night Live Keynote with Peter DeSantis》 这场演讲。这场演讲还是非常有逻辑性的，整个故事，还是得从serverless谈起……1. aws一直在追求serverless。数据库也在向这个方向努力。2. aws发布了aurora rds，兼容pg和mysql，aurora最大的创新，是优化的分布式存储系统，内部代号叫grover。通过grover，实现了算存分离，实现了The log is database。grover能显著减少IO消耗，实现用多少算多少，能简单快速的复制节点，为serverless打下了基础。3. 但是grover实现的，并不是真正的serverless，比如它只是能增加只读副本，不能增加读写节点。如果要扩展读写节点，你还是需要扩容升级，需要做failover迁移。4. 所以aws推出了aurora serverless服务。做到了无需调整数据库大小，进行failover迁移。在serverless中，数据库可以根据自己使用的情况，来申请内存。但是传统的方式中，数据库的内存是基于宿主机 ...继续阅读 (53)

证书更换的逻辑：1. 只读节点是高可用版本的情况下（不适合只读节点是basic的版本）， 先对只读节点的slave进行更新证书。1.1 更新证书的过程，先把证书路径下的证书文件进行删除或者重命名。因为如果生成新证书时，在同一路径下存在同名文件，则创建失败。（证书路径是数据库中 show variables like ‘%ssl%’中的参数显示的路径）1.2. 用mysql_ssl_rsa_setup创建证书，证书期限是一年，证书产生在原来老证书路径，由于老证书之前进行了删除或者重命名，不存在同一路径下同时有2张证书的情况。2. 证书更新后的生效，需要重启mysql实例，通过HA切换来实现。2.1 只读节点的主从互换，其实并不是的主从互换，而是一个读写主实例，基于mysql原生主从，做了2个只读实例。一主拖两从部署。2.2 HA切换，是重启了只读节点的slave节点上实例，并且将只读节点的终端链接指向，（可能是通过修改dns指向），指向这个实例。2.3 在只读节点的原master节点（现在为slave节点）上，生成新证书，重启只读节点原master节点。在2023-11-01之前，存在一个bug，是在证书更换的第1阶段， 没有正确生成新证书。这可能是老证书没有重命名或删除，导致同名新证书无法生成；可能是创建新证书时mysql_ssl_rsa_setup执行失败 ...继续阅读 (55)

在当前情况下，想要使用先进的GPT-4技术，只有两种途径。这款人工智能语言模型在各个领域都有着广泛的应用，然而目前要获得它的使用权并不容易。以下是可以让您体验到GPT-4功能的两种方法。首先，您可以选择使用Poe App。这款应用提供了一个简单易用的平台，让用户能够体验到GPT-4带来的惊人能力。要使用Poe App中的GPT-4功能，您需要购买其内置的订阅服务。订阅费用为每月16.67美元，订阅后，您将获得每月300个message的使用额度。这意味着您可以在该应用中使用GPT-4生成300条消息。虽然这个额度可能不足以满足一些专业用户的需求，但对于大部分人来说，这已经是一个相当不错的选择了。另一种获得GPT-4使用权的方法是通过开通和订阅官方的GPT Plus服务。这个服务的费用为每月20美元，略高于Poe App的订阅价格。然而，GPT Plus的使用限制相对较低，您可以在每3小时内获得25个message的使用额度。这种方式更适合那些需要在短时间内使用大量message的用户。需要注意的是，这两种方法均无法让您直接获取GPT-4的API。目前，GPT-4的API尚未开放，这意味着开发者和企业暂时无法将其直接集成到自己的应用和服务中。然而，随着GPT-4技术的不断发展和普及，我们有理由相信，未来API的开放将会成为现实。总之，虽然GPT-4的API尚未开放，但用户仍然可以通过 ...继续阅读 (61)

之前有泛泛的跟ChatGPT聊过数据库未来发展方向，数据库的优化工作是否可以有AI替代人类完成。 —— 这次我想问的再深入和专业一些。同时，我也用英文提问了。我希望英文给它的训练能给我更好的答案。我先抛出了一个问题，SQL Server是否可以将普通表转换成分区表。回答的算是中规中矩，说无法直接转成分区表，需要新建+select into导入。我想试试ChatGPT是否会知道SQL Server创建分区表的语法（因为各个数据库创建分区表语法都不一样，oracle可以直接创建，而SQL Server需要创建分区函数（function）和分区架构（schema）），没想到ChatGPT轻松的把语句级的例子写出来了，这应该是它的强项。既然能写SQL Server，再试试它对Oracle的了解程度。它也是能很轻松的举例出来。但是这最简单的分区改造方式，不符合我的要求。我给了它一个场景假设，如果数据是在不断变动的，那么要怎么做分区表。它给了几种方式，还可以，它的第一种方案就提到了在线重定义。我对它说的用外部表的方式（第2种方法），不是很理解。让它详细解释一下，没想到是把内部表转成外部表，然后再创建分区表，然后把外部表的数据insert到分区表。这种方式，估计是错误的。因为第一内部表是个不断变化的表，数据非静止；第二外部表转内部表，这应该是Hive的思路，不是oracle的方法。如果不是对各种 ...继续阅读 (50)

阿里云在上周日（2022-12-18）发生了发生了香港region的可用区C的大规模故障，阿里云自己在也微信公共账号贴出了处理过程，服务影响，问题分析和改进措施。（《关于阿里云香港Region可用区C服务中断事件的说明》）我使用阿里云不算多也不算少，2000个不到的实例，rds的mysql、pg、sqlserver，dts的同步、迁移也都在用。我觉得阿里云最大的问题，不是在假的status页面，也不是降温处理慢导致消防喷淋，而是阿里云的可用区建设，根本就是一坨屎。rds的高可用区选择，乱成一团麻。可以选择（1）单可用区的高可用部署；（2）多可用区指定主可用区+指定备可用区部署；（3）多可用区指定主可用区+自动选择备可用区部署；而且这些标准，是因地而异，比如杭州的多可用区是“多可用区部署+备用节点可用区自动选择”，而法兰克福的多可用区是“多可用1（可用区A+可用区B）。同样的rds购买菜单下，不同类型的rds，能选择的可用区数量不一样。比如买mysql高可用版时，可以选择的可用区是可用区F、可用区D、可用区E（我他妈也不知道为什么是这个排序），买pg高可用版的时候，可以选择的可用区是可用区F、可用区E。同样rds购买菜单下，沟通同一种类的rds，比如mysql，不同的版本，选择的可用区也是不一样。比如我选择买mysql 8.0高可用版，可以选择的可用区是:可用区F、可用区D、可用区E ...继续阅读 (44)

1. 阿里云的pg一键上云，其实是调用了pg_basebackup，这个功能不仅仅可以用在一键上云上，还能用在rds pg到rds pg的小版本升级上。2. 阿里云的pg大版本升级过程：（一）准备阶段：2.1 界面发起大版本升级；2.2 原实例snapshot（注，需要打开秒级备份功能，不然的话，非基于存储快照的pg_basebackup备份时间会比较长）用于产生目标实例master，业务无影响，这个步骤大约耗时1秒；2.3 利用快照生产生产实例，业务无影响，这个步骤大约耗时6~9分钟；2.4 以老版本形态,拉起目标实例Master，检查源端实例master到目标端实例master的同步状态；（二）割接阶段：2.5 源端实例设置成Read only,业务影响开始，这个步骤大约耗时2秒；2.6 目标端实例matser promote成主库，业务影响继续，这个步骤大约5秒；2.7 目标实例master pg_upgrade以link方式升级，业务影响继续，这个步骤大约6秒；2.8 DNS切换，业务影响继续，这个步骤大约60秒，切换DNS后业务影响结束；（三）后续阶段：2.9 kill session，在源端，每分钟kill一次，一共kill 3次；2.10 目标库收集统计信息；2.11 界面显示升级完毕；（源端实例会以ReadOnly形态一直存在，除非手动发起删除）3 ...继续阅读 (48)

原来一直以为这个文件中，每一行的顺序是没有区别的，但是最近的一个需求，研究时发现，原来这个文件对登录的会话，是从上往下依次判断的：具体的规则是：1. 登录的会话，会顺着pg_hba.conf的策略一条一条往下走。 2. 如果遇到匹配到的规则，那么做成判断，是信任，还是拒绝，还是验证密码。后续就不往下走继续判断规则了。 3. 如果某一条规则不符合，没匹配成功，就继续往下走，继续做判断，直到所有的规则都判断完毕。因此，如果我有一个用于备份的用户，叫anybackup（爱数备份软件），由于权限设置的比较大，需要保证只能在数据库本机登录（利用爱数在数据库本机的agent，登录数据库），且要禁止该用户，从别的主机登录。我们可以这样写我们的pg_hba.conf文件：# TYPE DATABASE USER ADDRESS METHOD local all all trust host all anybackup 10.0.0.0/8 reject host all anybackup 127.0.0.1/32 trust host replication repuser ...继续阅读 (47)

最近微软又爆了一个千年虫的bug，微软FIP-FS反恶意软件扫描引擎由于Year 2022漏洞导致Exchange服务器无法发送邮件。另外，本田、讴歌汽车也爆了Y2K22千年虫漏洞。这是因为，在程序中，或者数据库中，字段类型定义成int32字段类型。而int32，一共32位，第一位表示符号，因此可以表示数值大最大位是31位，即2147483647：1111111111111111111111111111111（二进制，31个1） —> 2147483647（十进制）2021年12月31日23点59分 —>windows，短年表示，精确到分，21年12月31日23点59分—>2112312359—–> 1111101111001110101010000100111下一分钟2022年1月1日0点1分 ——->windows，短年表示，精确到分，22年01月01日00点01分—>2201010001—–> 10000011001100001011111101010001 —> 超过 1111111111111111111111111111111（二进制），overflow，所以报错了。 另外还有一个类似的问题，北京时间2038年1月19号11:14:07( ...继续阅读 (49)

通常情况下，我们总是系统备份的速度是越快越好。 但是，有时候这会导致IO压力，我们需要削峰处理。我之前写过一个减少rman备份对OLTP系统的影响，其实mysql的备份（使用 MySQL Enterprise Backup）也可以采用类似的方法：我们在mysqlbackup命令中，添加sleep参数即可。修改前：修改后（削峰，其实备份的IO总量并没有减少，但是IO的波峰被削平了，同时备份时间也被延长了）：类似的，我们如果pg数据库，由于大表autovacuum导致IOPS波峰，也可以用这个思路来解决。调整autovacuum的参数如下（具体根据实际情况定）：autovacuum_vacuum_scale_factor=0.001 autovacuum_vacuum_cost_delay=100 autovacuum_vacuum_cost_limit=1500参考：16.10 Performance / Scalability / Capacity Options ...继续阅读 (48)

Oracle的进程，如果在os层面kill -9了，那么在v$transaction中是看不到的，需要在v$fast_start_transactions中去看。可以用下面2种方法预估回滚时间：方法一：（利用v$fast_start_transaction）set pages 1000 set line 1000 set feedback off set serveroutput on declare l_start number; l_end number; mydate varchar2(200); est_time varchar2(200); v_pause_secs number; begin --Set the pause time for get 2 times change,default is 300 seconds v_pause_secs:=600; select sum(undoblockstotal-undoblocksdone) into l_start from v$fast_start_transactions where state='RECOVERING'; dbms_lock.sleep(v_pause_secs); select sum(undoblocksto ...继续阅读 (47)

Postgresql数据库层限流脚本：with tmp3 as (select count(*) as cnt from pg_stat_activity WHERE pidpg_backend_pid() and datname='mypg1' and usename='postgres' and state='idle' and query like '%select now%') select case when cnt <= 400 then (with tmp1 as ( select pg_terminate_backend(pid) from (select pid from pg_stat_activity WHERE 1=2 ) as foo1) select count(*) from tmp1 ) when cnt > 400 then (with tmp2 as ( select pg_terminate_backend(pid) from (select pid from pg_stat_activity WHERE pidpg_backend_pid() and datname='mypg1' and usename='postgres' and state='active' and query li ...继续阅读 (50)

pg在11之前，有原生的range分区和list分区，但是没有原生的hash分区。 hash分区是需要通过pg_pathman插件来实现。如果你从原来pg 10版本+pg_pathman实现hash分区，且分区数比较多，比如1024个分区，那么到你升级到pg 11之后，如果采用了原生分区，你会发现sql语句的planning time会变得比较长。我们进行了测试，来验证pg 11的原生分区的性能：分区数pg 11.5 with native partition first time planning(ms)pg 11.5 with native partition second time planning(ms)pg 11.5 with pg_pathman partition first time planning(ms)pg 11.5 with pg_pathman partition second time planning(ms)pg 12.2 with native partition first time planning(ms)pg 12.2 with native partition second time planning(ms)41.891.241.381.221.410.62165.793.082.472.871.610.616456.5915.492.932 ...继续阅读 (56)

这个脚本是用来在mysql数据库中创建一个myawr数据库，记录数据库中记录active session。cat /root/user/myawr.sql--先创建myawr数据库 create database myawr DEFAULT CHARACTER SET utf8mb4;use myawr; CREATE TABLE myawr.`processliststatus` ( `ID` bigint(21) unsigned NOT NULL DEFAULT '0', `USER` varchar(32) NOT NULL DEFAULT '', `HOST` varchar(64) NOT NULL DEFAULT '', `DB` varchar(64) DEFAULT NULL, `COMMAND` varchar(16) NOT NULL DEFAULT '', `TIME` int(7) NOT NULL DEFAULT '0', `STATE` varchar(64) DEFAULT NULL, `INFO` longtext, `clock` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, `snapid` bigint(20) DEFAULT NULL, KEY ` ...继续阅读 (49)

Data file 结构：第一个extent:page 0 : File Header，注m_type = 15，Metadata: ObjectId = 99 page 1 : PFS( page free space)，注m_type = 11，Metadata: ObjectId = 99 page 2 : GAM ( global allocation map)，注m_type = 8，Metadata: ObjectId = 99，每个GAM管理4GB的页面，所以每隔4GB大小的页面，会有一个GAM。 page 3 : SGAM ( shared global allocation map)，注m_type = 9，Metadata: ObjectId = 99 page 4 : 空的，注m_type = 0，Metadata: ObjectId = 0 page 5 : 空的，注m_type = 0，Metadata: ObjectId = 0 page 6 : DCM（differential change map），注m_type = 16，Metadata: ObjectId = 99 page 7 ：BCM（bulk change map），注m_type = 17，Metadata: ObjectId = 99注意，如果大temp文件（一个超过4 ...继续阅读 (56)