go mysql客户端https://github.com/baixiaoyu/gocligo 解析系统表空间https://github.com/baixiaoyu/gibdgo id生成器https://github.com/baixiaoyu/idgeneratorpython 一些脚本h
最近用go把数据库的自动化运维重构了一遍，之前都是些一些分散的脚本，没有成体系，现在把所有的功能都集成到了agent中，agent中封装的有些命令，会执行一些条件检查，避免手工执行的一些问题，比如建库，库名重复，等等，agent不曝漏，可
MySQL中遇到问题，我们首先会去看show processlist,如果你的链接数量比较多，阻塞比较多的情况下，一般不太好查源头，我们还要手工执行一些sql ,才能定位问题，针对一些由于配置导致的MYSQL响应慢问题，也是需要进行一些排查。myanalyzer.py 这个工具能自动分析线程阻塞的原因，并给出建议，能非常方便的快速定位问题，针对对mysql不熟悉的人，也能使用这个工具进
MySQL的after_sync半同步与raft 保证一致性的方式有些类似。after_sync是master在sync binlog后等待从库把事务写到relay log后的ack，拿到ack后，在commit，然后在返回给客户端提交成功的信息。raft中的日志有commit和applied 两个列表，commited 代表日志写入了文件
看了几篇不错的flashcache文章，连接如下： http://www.orczhou.com/index.php/2010/09/flachcache-first-view/?spm=a2c4e.11153940.blogcont11195.3.3f2953baz5EOn7 http://www.orczhou.com/index.php/2010/10/how-to-setup-flash
开发有一个sql，在a实例上执行正常执行，b实例上执行报错。报错信息ERROR 1093 (HY000): You can’t specify target table ‘ver’ for update in FROM clause对比下2个实例的配置Variable b a========================= ...
(1)、 Manager工具:masterha_check_ssh : 检查MHA的SSH配置。masterha_check_repl : 检查MySQL复制。masterha_manager : 启动MHA。masterha_check_status : 检测当前MHA运行状态。masterha_master_monitor : 监测master是否宕机。masterha_master
参数innodb_file_format定义了文件格式 Antelope是原本的文件格式，支持compact和redundant行格式。 Barracuda是最新的文件格式，支持所有的行格式，包括compressed和dynamic行格式， 5.6默认的是Antelope，5.7是Barracuda 待补充
绑定 https://www.aliyun.com/jiaocheng/174430.html 查看使用的cpu核 https://blog.csdn.net/vevenlcf/article/details/47041389
sync_relay_log 肯定是与relay log相关，所以从rpl_slave.cc处理relay log的代码开始入手extern "C" void *handle_slave_io(void *arg)/* XXX: 'synced' should be
echo “$(sed ‘s/10.92xxx/10.92xxx/g’ /etc/hosts)” > /etc/hostshttps://xuxinkun.github.io/2017/07/03/docker-sed-cannot-rename/
平衡二叉树https://blog.csdn.net/isunbin/article/details/81707606红黑树http://www.360doc.com/content/18/0904/19/25944647_783893127.shtml红黑树比平衡
在使用salt调用shell的时候，如果shell中包含放置在后台运行的命令，那么salt会卡住，无法得到返回值，比如mysql使用mysqld_safe命令去启动实例的脚本，就会导致salt无法得到返回值一直处于卡住状态。 解决方案： 参考了 http://zhengbin.blog.51cto.com/2989505/1241608 使用python 的pexpect.spawn方法去间
因为想看下之前测试的varchar类型的http://blog.csdn.net/aoerqileng/article/details/53407786问题的原因，所以在ubuntu上搭建下mysql源码的调试环境，跟踪
数据库管理平台一期已经开发完成，主要实现了下面的功能： 1数据库信息标记 2自动安装部署，之前的自动化安装部署是在后台调用写好的shell脚本，这种
假设4台机器，master 在host1, slave在host2,host3,mha manager在host4 1部署主从结构 2安装mha node mha node有些脚本和独立的perl模块，主要是做下面的事情：save_binary_logs，保存和拷贝死去的master的二进制日志apply_diff_relay_logs:标识relay log事件的增量，应用所有必要的lo
在使用masterha_master_switch –master_state=alive进行再线切换的时候，看输出日志经历了下面几个阶段 1配置检查 会读取配置文件，检查复制状态，另外会提示在原主库上执行FLUSH NO_WRITE_TO_BINLOG TABLES，还会检查新主库是否ok的 2拒绝update阶段 这个阶段会调用你的脚本禁止主库上的写操作，执行完后，会把原主库上的所有表锁
今天在导数据到新搭建的测试环境中遇到了下面的错误提示： ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes 应该是键的长度超过了阈值，首先是想到了字符集设置的问题，在将测试环境与线上环境的字符集设置成一致后，依然是这个错误，查看表的定义CREATE TABLE `__Auth` ( `user
在mysql5.7版本中，有json类型字段，使用myloader0.6版本在还原的时候报错：myloader Cannot create a JSON value from a string with CHARACTER SET 'bin…需要注意下
千算万算，算不过代码的坑在mysql中，配置双主切换是一般常用的手段，理论上是不用停服的，但是遇到了奇葩的代码，这套逻辑就行不通了。所以在不清楚你的rd开发的代码之前，高级架构什么都是浮云，老老实实的用最简单架构吧。如果在双主切换的时候，应用切换一般连接新主，一半连接旧主，新主上写了一个数据，然后又删除了，然后紧接这应用在旧主上更新了这个记录，那就悲剧了，开始恢复修整数据吧。上天保佑你眼不...
1 Executing secondary network check script2 Executing SSH check script: save_binary_logs --command=test -3Monitoring server xxx is reachable, Master is not reachable from xxx. OK4探测3次 Master is no...
之前搞oracle，最近在搞mysql，之前没有接触过mysql，所以经过了一段时间的接触后，有一些自己的感悟。抛出深入到源码层面，总体的个人感觉是搞3年oracle的可以在3个月内搞定mysql，搞3年mysql的人不太可能在3个月内搞定oracle，mysql与oracle的管理上主要在下面几点有所区别。 备份恢复监控 备份方面差别不是很大，都是有逻辑备份和物理备份，有点区别的地方就是mys
开发说在测试的时候出现了重复主键的错误的，但是数据库中的记录中没有这个主键，上去看了下发现确实是没有这个记录，但是在另外的测试库中有这个记录，代码中的意思是先查询A库，然后再根据查询的结果去插入数据到B库，但是现实的结果是插入了A库当中，A与B没有设置复制，是独立的库，经过检查确认是代码的问题，在使用多源数据库的时候，没有正常
order by中带limit与不带limit返回的顺序不一定是相同的。下面这种语句也是会使用索引的SELECT * FROM t1WHERE key_part1 = constantORDER BY key_part2; KEY `idx_c` (`TABLE_NAME`,`TABLE_ROWS`)explain select table_name,TABLE_ROWS from d...
mysql> select * from bai_utf8;+-----+--------+| id | myname |+-----+--------+| 1 | aa || 100 | ab || 200 | cc || 300 | dd || 400 | ee || 500 | ff |+-----+------...
在主库上执行大量的吸入操作，模拟延时,因为之前的基准测试，导致从库出现长时间的复制延时，在执行stop slave的时候没有响应。 Master_SSL_Key: Seconds_Behind_Master: 85719 mysql> set global slave_parallel_type=logical_clock;ERROR 3017 (HY000
5.6版本之前mysql的udno是放在ibdata中，在5.6后可以设置undo的参数来指定undo的存储mysql> show variables like '%undo%';+-------------------------+-------+| Variable_name | Value |+-------------------------+---...
组复制 原以为mysql的开发会按照oracle的方式去走，最终就是小版本的oracle，没想到在mysql57中出了组复制的功能，组复制提供了了容错能力，只要组中的大多数的成员存活，那么系统就是可用的，组复制有2中形式，多master，所有server都能接受更新和单master自动选主，只有master接受更新,有更新冲突的时候，会采用先提交获胜的策略，回滚掉后提交的，组复
在使用sysbench进行基准测试的时候遇到下面的错误提示 (last message repeated 3 times) FATAL: MySQL error: 1461 “Can’t create more than max_prepared_stmt_count statements (current value: 16382)” FATAL: `thread_init’ functi
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
