如何解决数据库主从中断报错：Got fatal error 1236 from master when reading data from binary log?
数据库主从中断报错：Got fatal error 1236 from master when reading data from binary log: ‘Client requested master to start replication from impossible position’
出现这个问题是不正常先重启数据库或者断电。
查看一下从日志数据库错误：tail /mysql/mysql-error.log
查一下位置：/mysql/bin/mysqlbinlog –start-position=1039561141 /mysql/binlog/mysql-bin.00071
根据错误记录看中断同步位置，一般情况解决方法如下：
大量big5数据latin1转utf8的简要过程
如果直接导出SQL 再导入UTF8库里 会出现大量中文乱码。
1、先导出数据库结构
2、用SED只能批量修改或者文本批量修改 latin1 为 utf8
3、可以导出小量数据转换特殊字符，测试数据是否正常转换。
如何解决The table ‘表名’ is full 错误?
打开系统前台报错 插入数据已经满
一开始检查 以为空间满了 看了一下正常。
接着查看了mysql日志 mysql-error.log 大量报错误信息
错误：The table ‘表名’ is full
看样子是MYSQL 内存表有问题
如何通过SQL日志分析并修复注入漏洞？
最近mysql日志空间爆满，一天有几十G的数据量，明显有异常。
一、经过分析mysql日志发现，系统里有一个表被注入SQL日志
二、通过mysql慢查询通过其中一台WEB2如下：
如何解决Last_Error: Error ‘The table ‘表’ is full’ on query？
最近在从数据表同步某一个数据表报错，
出现“Last_Error: Error ‘The table ‘表’ is full’ on query“。
一开始以为数据表占满了，
查了一下此表，
如何解决Discuz!数据pre_common_stat报错？
最近一段时间数据库过12点后容易报错，错误如下：
（1062)Duplicate entry ‘20151203’ for key ‘PRIMARY’
INSERT INTO common_stat SET ‘daytime’=’20151203’,’login’=1
DISCUZ脚本处理这个触发时，有人点击网页才能进行处理，
这里说明同时并发的情况下，重复触发新建入库了。
不正确重启服务器对正在运行应用可能会造成破坏
最近几天发现网管打完补丁后，就重启机器，正在运行数据库表被破坏，前台web页面就报错！
服务器日志报错如下：
mysqld: Incorrect key file for table ‘.\数据库名\表.MYI’; try to repair it
修复：停止web服务，进入数据库，用repair指令修复一下就行了，幸好服务器的数据量不大。。。
总结：如果数据量有点大的话，修复上就会麻烦。
正确的做法是：先关闭web服务(nginx,httpd等)，再关闭数据库服务，最后在关机。
往往人都省麻烦（含个人电脑)，不关闭应用层的东东就直接关机！
如何解决 Writing to net ?
centos6.2 下主从防火墙相应的端口已经开放了
最近查数据库老出问题，
发现新增的从数据， 在主从同步出现 Writing to net
如 下图
+——–+———–+———————+——-+————-+——-+—————————————————————-+——————+
| Id | User | Host | db | Command | Time | State | Info |
+——–+———–+———————+——-+————-+——-+—————————————————————-+——————+
| 1054 | ddd | ip1:38323 | NULL | Binlog Dump | 11874 | Has sent all binlog to slave; waiting for binlog to be updated | NULL |
| 1056 | ddd2| ip2:37068 | NULL | Binlog Dump | 11874 | Has sent all binlog to slave; waiting for binlog to be updated | NULL |
| 466120 | ddd3| ip3:52302 | NULL | Binlog Dump | 751 | Writing to net | NULL |
测试发现关闭防火墙问题就会消失！
后来再测了一下，用另外一台centos5.5 从数据库防火墙配置覆盖新增加的，结果还是一样的会出现 writing to net
两台丛数据区别 centos版本不同 iptables 版本不同
