￥29.96篇/更新中
￥9.92篇/更新中
￥29.97篇/已完结
-
编辑 删除
MySQL中server_id一致带来的问题
我们都知道在MySQL搭建复制环境的时候，需要设置每个server的server_id不一致，如果主库与从库的server_id一致，那么复制会失败。但是最近在解决一个客户的问题的时候，遇到一个有意思的现象，客户环境有三台数据库服务器，一主两从，客户的两台从库设置了相同server_id，在排查问题的过程中，查看MySQL错误日志，发现有很多奇怪的信息。 我们模拟了客户的环境，并进行测试、分析，最终在代码中找到了我们想要的答案。下面就是我们测试、分析、总结的步骤以及内容。
-
编辑 删除
【oracle 12c asm专题】flex diskgroup相关概念
当Flex Diskgroup挂载之后，下一步就是创建一些新的实体（这里的实体指文件组和配额组等）了。首先，需要创建配额组（quota group），顾名思义，配额组可以给组内的实体设定配额（存储空间上限）。你可以选择自己根据自己的需求创建一个配额组，当然也可以不创建，因为Oracle会默认为你创建一个没有存储上限的默认配额组。稍后你将看到，默认配额组将被分配给这个Flex Diskgroup中所有新建的数据库。
-
编辑 删除
oracle 12c flex cluster专题 之 节点角色转换
笔者上一篇译文中在介绍Leaf Node时提到，**虽然leaf node不要求直接访问共享存储，但最好还是连上共享存储，因为说不准未来哪天就要把这个leaf node转为hub node使用。**其实这样的说法并不够准确，在12cR1时，leaf node上是无法运行只读数据库实例的，这时不连接共享存储完全不影响其使用。而12cR2的leaf node是可以运行只读数据库实例的，一旦leaf node上有了数据库，这时leaf node（确切的说这时leaf node应该叫做reader node）就必须连接共享存储了。这次就介绍下如何将节点的角色在hub node和leaf node之间互相转换。由于笔者实验环境中已经存在了一个leaf node，所以先从leaf node转为hub node做起。
-
编辑 删除
【Oracle 12c Flex Cluster专题 】— Leaf Node的故障迁移
Oracle 在12c中使用hub-and-spoken技术实现了Flex Cluster的功能(即RAC集群中的每个节点不再需要既运行ASM实例又运行DB实例，各节点可以扮演不同的角色)。相比12c以前的版本，该功能使集群规模的扩大和缩减变得更加靠谱。
-
编辑 删除
MySQL 5.7复制配置不规范修改导致的坑（二）
从上文中冗长的分析过程，我们可以得知，导致出问题的起因是主库持续写入的情况下，从库执行stop slave;时，IO线程读取并只向relay log中写入了一个事务的部分event（event组不完整，只写了GTID EVENT），后续change master to master_auto_position=0语句既没有指定请求主库的binlog位置，也没有指定从库的relay log，导致mysql server执行了清理relay log（清理了IO线程最后写入的GTID EVENT）以及 relay log和SQL线程相关的表和内存中的位置信息，并把SQL线程的位置指向了IO线程的停止位置（IO线程读取的主库binlog file and pos），后续start slave;时从库就从IO线程停止的位置开始复制，由于IO线程停止时的位置处在一个事务的中间，SQL线程从这个位置开始应用时，立即发现了这个事务缺少GTID event，被误认为是一个 匿名事务（gtid_mode系统参数设置为ON时，IO线程和SQL线程都不允许碰到匿名事务），所以SQL协调器线程和worker线程
-
编辑 删除
MySQL 5.7复制配置不规范修改导致的坑（一）
今天咱们同事说碰到一个古怪的问题，说MySQL 5.7.18上，主从复制结构中，从库在使用change master语句切换master_auto_position=1为0时，SQL线程报错了([ERROR] Slave SQL for channel '': Error '@@SESSION.GTID_NEXT cannot be set to ANONYMOUS when @@GLOBAL.GTID_MODE = ON.' on query. Default database: 'sbtest'. Query: 'BEGIN', Error_code: 1782)，然后，出于尝试修复，又改成了1，重新启动复制就恢复正常了，然后再改成0重新启动复制，这个时候发生数据丢失了，再反复切换几次之后，MySQL crash了。。，当时我听到这个问题的第一反应就是：一脸懵逼（因为1782错误通常是发生复制架构启用GTID复制之后，从库IO线程读取到主库的ANONYMOUS 事务时报错）。。然后，发了一阵呆之后，想到了一些可能导致这个问题的原因，下文我们通过"复现与简单分析"、"重新复现、详细分
-
编辑 删除
MySQL中的统计信息相关参数介绍
上周同事在客户现场遇到了由于统计信息的原因，导致应用数据迁移时间过慢，整个迁移差点失败。关键时刻同事发现测试环境与生产环境SQL语句执行计划不一致，立刻收集统计信息才保证迁移得以正常完成。 统计信息对于SQL的执行时间有重要的影响，统计信息的不准确会导致SQL的执行计划不准确，从而致使SQL执行时间变慢，Oracle DBA非常了解统计信息的收集规则，同样在MySQL中也有相关的参数去控制统计信息。
-
编辑 删除
mysqldump与innobackupex备份过程你知多少（完结篇）
作为专职的DBA：我们一定一定要保持一种高度谨慎的态度，在数据库备份方案选型时，一定要根据自己的业务场景充分测试，校验，尽可能地把可能出现的深坑挖出来。除了寻找适合自己的，可行的备份方案之外，更应该做好备份校验（备份是否成功完成、备份文件是否损坏）、备份恢复演练（备份文件是否可以正常恢复数据），以备不时之需。对生产库的DDL操作、大事务、或者长时间锁表的操作，一定要避开备份时间，否则，你懂的……
-
编辑 删除
mysqldump与innobackupex备份过程你知多少（三）
想必大家都知道，mysqldump备份时可以使用--single-transaction + --master-data两个选项执行备份（老实讲，为图方便，本人之前很长一段时间，生产库也是使用mysqldudmp远程备份的），这样备份过程中既可以尽量不锁表，也可以获取到binlog pos位置，备份文件可以用于数据恢复，也可以用于搭建备库。看起来那么美好，然而，其实一不小心你就发现自己已经在坑里了。
-
编辑 删除
mysqldump与innobackupex备份过程你知多少（二）
沃趣科技 罗小波1.2.3. 使用WITH CONSISTENT SNAPSHOT子句的作用START TRANSACTION语句使用WITH CONSISTENT SNAPSHOT子句时，会为事务启动一致性读(该子句仅适用于InnoDB)。其行为与执行START TRANSACTION语句之后+一个SELECT语句效果相同（会获取一个事务号，在read view中占个坑，但是...
-
编辑 删除
mysqldump与innobackupex备份过程你知多少（一）
要查看备份过程中这俩备份工具都对数据库做了什么操作，想必大家都知道：可以打开general_log来查。那么问题来了，general_log输出的信息都代表什么？如果不这样做会怎样？这两个备份工具会不会有什么平时被忽略的坑？请看下文分析，也许……你会发现原来之前对这俩备份工具好像也不是那么了解!
-
编辑 删除
沃趣科技与Mellanox联合打造证券行业高性能及同城双活数据库云平台
近几年来，股市的跌宕起伏和井喷行情，给各大券商的业务系统带来巨大压力，其IT 系统面临前所未有的挑战。为应对日益增长的行情和业务需求，并通过信息技术的升级带动业务创新，打造差异化竞争力，证券公司均不断加强对 IT 系统的新建和改造的投入。目前，证券公司诸多关键业务和应用系统均运行在IOE（IBM 为代表的小型机、Oracle数据库、EMC为代表的集中式存储）架构的系统平台上，在应对突发实时交易流量暴增、保障系统高可用、提升移动互联网化的用户体验、满足行业监管要求等方面，原有的IOE基础架构平台面临着诸多不足。
-
编辑 删除
Performance Schema使用简介(一)
此次简单介绍了Performance Schema的使用，后面会逐步介绍使用Performance Schema的一些实战功能。
-
编辑 删除
关于热点数据导出与加载的影响，多的是你不知道的事
想必数据库的同行们都知道，热点数据导出导入的动作，使得数据库重启之后，不需要再耗费大量的时间来预热，使得因为热点数据的原因导致数据库性能波动的时间大大减少，那么执行热点数据的导出与导入操作时究竟对数据库的性能有没有影响呢？如果你的服务器拥有超大内存，而且设置了一个对应内存一定比例的超大buffer pool，是否在纠结需不需要设置热点数据在重启时自动导出导入呢？下面一起看演示过程，答案就在其中。
-
编辑 删除
“mysqlbinlog”工具做binlog server靠谱吗？
玩过binlog server的同学都知道，它使用mysqlbinlog命令以daemon进程的方式模拟一个slave的IO线程与主库连接，可以很方便地即时同步主库的binlog，以便弥补定时备份策略中最近一次备份到下一次备份完成之前这段时间内的数据容易丢失的问题。
-
编辑 删除
看各路神仙如何大战MySQL insecure warning报警有感
如果你要写一个脚本调用mysql命令来获得server_id的值，这个Warning的信息绝对是你的噩梦。 提示这个安全原因本来无可厚非，但是坑爹的是，没有任何一个参数或者开关能关闭这个Warning。
-
编辑 删除
由optimizer_switch所引起的诡异问题
mrr_cost_based代表是否使用基于代价的方式去计算使用MRR特性，新的系统中将他设置为off代表不使用基于代价方式而是使用基于规则的，这样设置的原因是考虑到MySQL基于代价的方式比较保守，不能使用到MRR这个特性。本身设置这个参数是没有任何问题，只不过正好遇到mrr_cost_based设置为off时碰到了这么诡异BUG，希望可以帮助到遇到同样问题的朋友们。
-
编辑 删除
load data语句如何保证主备复制数据一致性(一)
通过示例演示并查看过程中binlog中如何记录load data语句等方式来验证 load data语句如何保证主备复制数据一致性 * 将分别在四种隔离级别下（会话级别修改tx_isolation）针对binlog_format（会话级别修改binlog_format）的三种格式分别进行演示执行load data语句，观察MySQL server层如何处理，主库binlog中如何记录load data语句，备库的binlog中如何如何记录load data语句 * 本文假定你已经搭建好了主备复制环境，如果未搭建请先自行搭建主备复制环境
-
编辑 删除
【MySQL】load data语句详解（三）
关于使用local子句与不使用local子句的时候的差异如果load data语句使用了local子句，则客户端使用TCP远程连接mysql server时，没有file权限仍然能够导入文本文件，这个时候是非常危险的，因为local子句的内部原理是从客户端的主机读取文本文件并传送到server端的/tmp目录并保存为一个临时文件，再执行load data语句的。另外，要使用local子句，还需要看server端启动是否关闭了local_infile选项（如果不指定该选项，则服务端默认为ON），mysql client连接时是否关闭了local_infile选项（如果不指定该选项，则客户端默认为ON），local_infile在server或client端任意一端关闭都不能使用local子句，会报错误：ERROR 1148 (42000): The used command is not allowed with this MySQL version如果load data语句不使用local子句，则这个时候用户必须要有file权限才能够执行导入文本文件（并且只能够导入se
-
编辑 删除
【MySQL】load data语句详解（二）
当mysql server从文本文件读取数据时，FIELDS和LINES默认值会导致LOAD DATA INFILE的行为如下：寻找换行边界字符\n来进行换行不跳过行前缀，把行前缀也当作数据（发生在如果导出数据时使用了行前缀，导入时没有指定正确的行前缀或者根本没有指定行前缀选项时）使用制表符\t来分割一行数据中的各列要注意：在FIELDS和LINES的默认值下，在解析文本文件时不会把字符串之间的引号当作真正的引号，而是当作数据
