MySQL ERROR 2027(HY000):Malformed packet due to GoldenGate Replication Slave

最近有个客户查看MySQL主从同步时,提示ERROR 2027(HY000):Malformed packet错误,存在slave连接失败的现象,后分析是因为该MySQL配置了oracle goldengate,以replication slave的方式抽取,仅记录提醒再次遇到该问题。

, ,

TiDB SQL运行失败tidb_mem_quota_query limit

今天一客户的TiDB数据库环境业务查询报错,单条SQL的执行内存上限,提示如下:
Your query has been cancelled due to exceeding the allowed memory limit for a single SQL query. Please try narrowing your query scope or increase the tidb_mem_quota_query limit and try again

,

Migrate oracle to openGauss/oceanbase/达梦/kingbase: md5 function

在十年前简单测试过oracle 9i 的加密解密用法之dbms_obfuscation_toolkit(二),其中有md5单向加密, 最近在oracle迁移到opengauss项目中用到了md5, 这里简单记录替换方案,在pg或og中直接就有md5 function. 在mysql及Mysql系的产品和ocenabse, 达梦一样存在该函数md5。

MySQL Estimate of the duration of a rollback operation(估算rollback事务回滚剩余时间)

很久以前记录过一篇 Oracle Estimate of the duration of a rollback operation (估算rollback事务回滚剩余时间) ,oracle的大事务cancel或kill后的回滚操作,rollback所花费的时间通常比原来的操作还要长,而且在回滚完成前有可能会堵塞其它事务,在PostgreSQL中因为没有使用undo而是多版本,所以忽略rollback的时间,这是PG的强项,但是在MySQL中和oracle一样同样存在回滚问题,这里简单记录如何估算MySQL中的事务回滚时间。

,

GoldenDB TEMP Tablespace(#innodb_temp)导致文件系统使用率高

最近,我注意到一位朋友在处理一个以G字开头的MySQL系国产数据库时遇到了一些问题。具体来说,该数据库占用了超过1TB的临时文件,导致文件系统告警,之前kill session并且未能释放。这是由于在杀掉dbproxy上的session后,db node上的session仍然存在。这样的情况可能是非原生分布式数据库的一个风险点,因为每个data node都是一个独立的MySQL实例。最终,我们通过登录到data node并手动kill session解决了问题。我在另一款国产MySQL系分布式数据库GoldenDB上进行了类似的模拟测试,仅记录处理方法。

, ,

Troubleshooting MySQL ERROR 1709 (HY000): Index column size too large.

在MySQL 5.6或从5.6 升级到8.0后有可能会遇到ERROR 1071 (42000):Specified key was too long; max key length is 767 bytes 报错,提示是遇到了索引KEY的最大上限767 字节。在本文中,我将解释此错误发生的原因以及如何解决它。

Alert: 不要升级到 MySQL 8.0.38( 8.4.1, 9.0.0) 任何版本?

上周,Percona 发布了一篇警告博客,提醒用户<不要升级到 MySQL 8.0.37 之后的任何版本>。然而,现在访问 MySQL 官方下载页面,依然可以在主推的下拉列表中看到这些版本。
Percona 在文章中提到,Jean-François Gagné 在 bug.mysql.com 上报告了一个编号为 #115517 的 bug。不幸的是,这个 bug 目前处于私密状态。简而言之,如果您创建大量表(例如 10000 个),MySQL 守护进程在重新启动时会崩溃。当然,也有人认为这是危言耸听,因为单个数据库实例中有超过1万张表的用户可能不足0.0000001%。

, ,

MySQL的DDL注意事项,在Goldendb中有改进吗?

Oracle 数据库在在线维护操作方面引入了大量特性,旨在实现日常维护和升级时无需停机。相比之下,MySQL 在这方面的表现稍逊一筹。作为 Oracle 的 DBA 是一件很幸福的事情,因为日常的分区维护、发现性能问题时的紧急创建索引等操作都可以在线完成。而 MySQL 虽然也宣称支持 DDL,但这是真的吗?

我们有一个 GoldenDB 的客户要求以后所有的 DDL 操作只能在停所有业务的情况下执行。对于拥有大量数据库实例且需要频繁进行 DDL 维护的情况,请问你能提供多少停机时间?

, ,

MySQL Backup/Restore tools 总结

数据库存放着组织拥有的最重要的资产之一——数据。保持数据安全和不受破坏是关键任务。对于大多数应用程序来说,停机比数据丢失或损坏更痛苦。DBA的核心职责包括数据库的备份恢复,到了关键时刻非常考验方案的有效性。在MySQL开源数据库也存在一些备份工具,但存在一些差异,备份应根据恢复需求进行规划, 这里简单整理。

Oracle MySQL PostgreSQL数据库比较系列(二十二): BLOB & CLOB maximum size Limit

The maximum size of large objects (LOBs) in Oracle, PostgreSQL, and MySQL varies depending on the type of LOB and the database system. Here are the details for each database:

MySQL 行锁lock 放大现象Oracle DBA无法理解

MySQL事务隔离级别默认的Repeatable Reade 下有Gap Lock问题,在更低的隔离级别下,如读已提交(Read Committed)或读未提交(Read Uncommitted),Gap Lock不会被使用,在READ-COMMITTED下同样存在类似“Gap Lock”的问题,如果Oracle 数据库向基于MySQL innodb的数据库迁移后,不知是否会出现原有应用经常行锁等待的现象,等待innodb_lock_wait_timeout参数配置的时间后报错, 而oracle lock是在行头(row header)上,MySQL这种导致锁定记录增加的现象,让从事oracle DBA转型的无法理解

,

Oracle, MySQL, PostgreSQL 数据库比较系列(二十一): 纪元秒数与日期转换

前几日一客户问我在oracle执行unix_timestamp函数报错,心想这不是MySQL的函数吗?难道oracle引入了?找了一圈到oracle 23ai也没有自带该函数,可以自定义函数实现, 在去年的一个oracle迁移到PostgreSQL系数据库里,有套业务库大量使用epochs做为datetime,这里简单记录在oracle, mysql ,postgresql中如何做unix epoch到datetime的转换.

分析应用日志Caucho连接池MySQL随机com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

最近一客户的应用日志随机会出现一些数据库源访问错误,中间件使用Caucho的连接池,数据库为MySQL 5.7主从,前端有HAproxy, 应用server多个,报错也不是持续性,再次重试可能会就正常,错误日志DataAccessException: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago.

,

Goldengate alter extract process after MySQL master Switchover to slave

Oracle数据库有dataguard主从,MySQL有主从或MGR,Goldengate同步支持从前两种数据库做数据抽取,但是在主从切换以后需要在Goldengate做相应的修改。这里记录一下MySQL因master 需要停机维护时,OGG主动切换到slave的方法。

Oracle、MySQL、PostgreSQL、openGauss、达梦、OB、Tidb数据库比较系列(二十): 事务隔离级别

事务隔离级别是数据库事务处理的基础,ACID 中的 “I”,即 Isolation,指的就是事务的隔离性。ANSI/ISO SQL 标准定义了4 种事务隔离级别,对于相同的事务,采用不同的隔离级别分别有不同的结果。这些隔离级别是根据3 个“现象”定义的,

Oracle、MySQL、PostgreSQL、openGauss、达梦数据库比较系列(十九): 增加列default value会表重写吗?

之前曾经在《oracle add column xx default value 增强(二)》记录过,在日常运维中增加column是常见的操作,对于大表增加列时是否会导致回写表还是只修改数据字典影响DDL的执行时间和停机窗口长短。之前也在《“alter table ” modify column in Oracle、MySQL、PostGreSQL(数据库比较系列十三)》记录修改column时不同库的表现, 这里简单记录测试一下当前主流的几个库对于add column的现象。

,

Oracle、Kingbase、OceanBase、TIDB、达梦数据库比较系列(十八): for update nowait 报错信息可读性

前几天看到有OB用户留言,提到OceanBase很可能是出于对他们需求的考虑,而应用中以前对ORACLE报错的依赖。这表明现在数据库厂家在满足各种甲方要求时也颇为无奈,在应用的兼容性上做了种种让步。就对于会话1事务中,会话2 select for update nowait相同的报错场景,我简单测试一下在其它国产库上是否还不如Oceanbase. 为了方便横向对比,这里我再简单的附上ORACLE 与OB的报错。

,

Oracle、MySQL、PostgreSQL、OceanBase、万里开源数据库比较系列(十七): IN ( MAX Subquery )

在关系数据库中两表关联在oracle中使用IN( subquery)的语法很常见, 但kevin发现在MySQL中subquery使用MAX聚合参数时,会导致主查询Full scan而无法使用索引范围扫描, 当遇到大表时可能性能下降明显 ,测试发现有的库使用子查询做为驱动表,有的是使用filter从主查询过滤。下面简单测试。

Oracle、MySQL、PostgreSQL/openGauss、达梦、OceanBase数据库比较系列(十六): Index scan MIN/MAX

在关系数据库中常见的一种需求统计表的记录的最大值或最小值,SQL中使用max min,为了最佳效率通常希望可以在列上创建索引,减少表段的IO量,如果可以可以使用更佳的执行计划如直接访问索引的头和尾(btree index的有序结构),减少index 块的访问,我们对比一下几款数据库在该方面的能力。

注意: GreatDB中sysdate并不是oracle的sysdate

国产库在承接Oracle替换方面做了大量的兼容性,如果仅实现了语法兼容,没有相同的语义,这恐怕比不兼容还糟糕,比如原来的oracle的应用迁移到国产库后执行不报错,但却有可能和oracle得到完全不一样的结果。今天我们以万里开源的GreatDB中的sysdate为例, 对最近同事遇到这个案例简单分享。

,