工具人的博客

经过多次尝试和排查，发现问题的根源竟然在于my.ini文件的字符编码。如果my.ini文件不是使用ANSI编码保存的，那么MySQL在读取配置文件时可能会遇到问题，从而导致服务无法启动。最坑的是mysql日志不会报错，windos的事件查看器也看不到任何错误。接着就检查了所有的常见问题（如端口占用、配置文件路径错误等）仍然无法找到原因。通过将my.ini文件的编码修改为ANSI，问题得以解决。进行重启，发现重启失败，而且提示服务没有任何错误。环境：win server 2012R2。

一、首先第一步，我们先来编写数据库配置文件，在test001keshanchu下创建目录和文件test_db\config.ini，内容如下[DATABASE]host = 10.182.27.158port = 3306user = rootpasswd = 123456wtdatabase = xttest_newdbchar = utf8table = interface_test二、第二步，我们写一个从config.ini配置文件中读取我们想要信息的readConfig.py文件

最近数据库一直有事务发生RUNNING不结束，使用了以下方法进行排查 mysql在数据库information_schema 中增加了三个关于锁的表 innodb_trx ：当前运行的所有事务 innodb_locks ： 当前出现的锁 innodb_lock_waits ：锁等待的对应关系locks和lock_waits没有信息 show engine innodb status #

数据库使用的是阿里云RDSmysql5.6 应用程序CALL生产库的存储过程，navicat报错ERR1449 但是在测试库使用时并没有问题。 以为是权限问题，检查后发现和测试库的权限是一样的。查看应用后台日志发现ERROR如下 看内容是关于GTID参数设置的问题，发现确实日志中提示的enforce_gtid_consistency参数在生产库中是ON，测试库

目前数据库为一主两从，版本5.6。昨天发现其中一台数据库数据有缺失类似gtid空洞，执行show slave status发现executed_gtid_set数据不正常，有几个事务卡住。正常情况应该是这样的解决过程如下：1、主库show master status;找到主库uuid的gtid，即变化的gtid，记录前段2、从库stop slave; show master stat...