Mysql8.0开始默认采用新的caching_sha2_password的身份验证方式,常规老接口会因此无法连接数据库。 为继续使用老的身份验证方式,需显式指定身份验证方式为 mysql_native_password,如下: ALTER USER 'ingp_auth'@'%' IDENTIFIED WITH mysql_native_password BY 'password^kAuAaj*Y'; flush privileges; 查询目前已有用户…
Mysql8.0开始默认采用新的caching_sha2_password的身份验证方式,常规老接口会因此无法连接数据库。 为继续使用老的身份验证方式,需显式指定身份验证方式为 mysql_native_password,如下: ALTER USER 'ingp_auth'@'%' IDENTIFIED WITH mysql_native_password BY 'password^kAuAaj*Y'; flush privileges; 查询目前已有用户…
实际工作中总会发生数据误删除的场景,在没有备份情况下,如何快速恢复误删数据就显得非常重要。 本文基于MySQL的binlog日志机制,当日志格式设置为“binlog_format=ROW”时,记录一步一步手动解析binlog、恢复误删数据的全过程,供大家参考使用。 大致的思路是:通过命令找到删除操作对应的 binlog 详细信息,可通过 postion 或者时间的方式来检索查询,查到相对应的 DELETE 语句,通过 sed 将 DELETE 命令转换成 INSERT 的命令,然后提取出来执行完成恢复。当然这个需要…
MySQL不同于oracle,没有闪回查询这类概念,但网上流传几个闪回的开源工具如 binglog2sql、MyFlash,可以使用binglog日志进行误操作数据的恢复。 笔者以前测试过 binglog2sql,发现安装配置比较复杂不太友好。 本次测试了下 MyFlash 这个开源工具,发现相对简单易用,特此做一个使用记录。 MyFlash是由美团点评公司技术工程部开发维护的一个回滚DML操作的工具。该工具通过解析v4版本的binlog,完成回滚操作。相对已有的回滚工具,其增加了更多的过滤选项,让回滚更加容易。 …
研发人员在测试大事务提交时遇见了错误: Got error 5 - 'Transaction size exceed set threshold' during COMMIT 测试了几次都是1200S的时候停止的,不过在注释掉特定步骤后,过程还是在1200S失去连接了,不知道这个1200S的执行参数是哪个,可能这个1200s的执行参数是关键,因为看 wsrep_max_ws_size 最大提交量是2G,理论上应该是够用的。 通过以下查询方式,也只能查出这个2G的限制: show variable…
在MySQL8.0的一个PXC集群中,默认的sql_mode设置如下: select @@sql_mode; +-----------------------------------------------------------------------------------------------------------------------+ | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIV…
一、PXC方案概述 Percona XtraDB Cluster (PXC) 是一个完全开源的 MySQL 数据库集群解决方案,它可确保高可用性,防止停机和数据丢失,并为不断增长的环境提供线性可扩展性。它将 Percona Server 和 Percona XtraBackup 与 Galera 库集成在一起,以实现同步多源复制。 集群由节点组成,其中每个节点包含在节点间同步的相同数据集。推荐的配置是至少有 3 个节点,也可以有 2 个节点,但不建议使用2个节点。每个节点都是一个常规的 MySQL Server 实…
一套2节点的MySQL PXC集群,第1节点作为主用节点长时间的dml操作,导致大量的事务阻塞,出现异常,此时查看第2节点显示是primary状态,但无事务阻塞情况。 此时第1节点无法正常提供服务,于是以为第2节点可以作为主节点提供sst数据源来新建第1节点,但清空第1节点开始启动时,却发现无法正常启动sst同步,因为:failed to reach primary view 此时的报错信息详情如下: 2022-03-16T11:28:00.546024Z 0 [ERROR] [MY-000000] [Galera…
接上文,本次在较高性能的X86物理机上,做真实生产环境的大数据量导入测试。 一、测试环境 ■ CPU是24核,每核2线程,即48CPU $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 48 On-line CPU(s) list: 0-47 Thread(s) per core: 2 Core(s) per socket: 12 座: 2 NUMA 节点: 2 厂商 ID: G…
接上文,继续测试3000万条记录快速导入数据库。 一、导入前1000万条数据 清库、建库、新建表结构、导入前1000万条数据,结果: ■ 1000万行,有2索引导入耗时:16分钟 Query OK, 9999966 rows affected, 5920 warnings (16 min 12.95 sec) Records: 9999966 Deleted: 0 Skipped: 0 Warnings: 5920 可见,导入千万条数据,性能下降明显。 二、导入前2000万条数据 清库、建库、新建表结构、导入前20…
对于传统的关系数据库如oracle,在大量数据导入方面的效率,我们一般有一个大概的认知,即1分钟以内可以导入千万条数据,而对于MySQL数据库,普遍观点以为性能相对较差,尤其时对于千万级别的数据量,几十分钟、几个小时,都是可能的。是否如此,本文会给出答案。 在普遍去IOE的今天,最难的去O也已经势在必行,所以探讨测试一下MySQL的大数据量导入非常有必要。事实上我们的各个新建项目由于采用了MySQL数据库,在备份恢复时,便会面临大量数据的逻辑导出与导入需求。 恰好笔者手头有一个3000多万行的数据记录,SQL文本格…