Tags
Meta
Blogroll
Mine
Tag Archives: MySQL
bind + mydns 大容量智能 DNS 的方案简述
大体上就是 bind 上启用 view 功能，然后把请求转发给后端的多个 mydns。不过遇到的问题是，如果用 zone {type “forward”;} 的话，会导致 bind 给出的解析结果里缺少 AA 标志位，而且还会带上 ADDITIONAL SECTION，而这个 ADDITIONAL SECTION 指向的恰恰是 bind 自己，于是有时会造成循环。 怎么让 bind 认同自己事实上的权威地位，成了方案的关键。想了几个小时，终于明白了只有 master 和 slave 才能给出带 AA 标志位的应答。master试过了肯定是不行的，因为必须有 file 参数。后来试了试 slave，竟然只需要 masters 参数即可。 最终方案是两横两纵的： 1 一个域有两个 NS 服务器 … Continue reading
很不幸，又遇到bug了——MySQL replication故障
我就说 RedHat 的软件质量不好，还总有人不信。这次又找到证据了。 RHEL5.4/5.5 里带的 mysql-server 包 # rpm -qi mysql-server Name : mysql-server Relocations: (not relocatable) Version : 5.0.77 Vendor: Red Hat, Inc. Release : 4.el5_4.2 Build Date: Sat 30 Jan 2010 03:11:47 AM CST 存在 replication 时，slave 跟不上 … Continue reading
怒了，mysql真是太过分了，竟然改开发接口
今天编译 Courier-authlib 0.62.2 版本，编译出来都是残废，不支持 MySQL 查询。后来看了 config.log，发现其需要的 mysql_connect 函数在 libmysqlclient 库中找不到。nm 了一下那个库，还真的是没有。 后来到 http://dev.mysql.com 翻文档，说这个函数改成 mysql_real_connect 了。MySQL 真是太过分了，就不知道留个接口给老的代码吗？ 这件事也教育我们：没事不要自己编译，浪费时间和精力。
请随手删除无用的文件和设置
今天我们部门把一个数据库迁移到另外一台服务器了，但我仍发现原数据库有很多写入操作，干扰mysql master-slave工作，找了很多遍，还是没找到问题所在。后来直接把旧的库删除了，问题马上就暴露出来了。 回想到前年在aka公司，公司的服务器上有十几个ipip隧道，也不知道指向哪里的；服务器上还有几十个服务的配置文件，也不知道还有用没有。单单为了搞清楚那台服务器是干什么的，就花了我两三天的时间。看来这行业手脚不干净的人还是挺多的。 最后喊一句口号：请随手删除无用的文件和设置，践行规范化系统管理。
忘记看mount –bind导致数据库丢失一例
Ubuntu 8.04 Server 原来MySQL的datadir是/var/lib/mysql/目录。因为/var分区比较小，我在一个LVM卷里创建了和库同名的两个目录，并用mount –bind把它绑在原来的数据目录的库目录上： mount –bind LVM/mysql/db1 /var/lib/mysql/db1 mount –bind LVM/mysql/db2 /var/lib/mysql/db2 某一天，/var/lib/mysql/下保存的InnoDB日志占满了/var分区的所有空间。无奈，我只好把数据库目录整个挪到LVM去。因为设置mount –bind的时间太久，我都忘记这个事了。于是我先删除了LVM/mysql目录（因为这个目录看起来比较旧）然后把/var/lib/mysql目录挪过来。于是，丢失了所有的数据……
感受AppArmor
ubuntu 8.04 server 今天 /var/ 分区装满了，于是把 /var/lib/mysql/ 目录给挪到别处，结果重启动 MySQL 失败。日志显示 mysqld 会尝试创建一个 hostname.lower-test 文件，以确定对 datadir 目录有写权限 我 su 到 mysql 用户，进目录，发现可以创建文件 于是想到可能是安全框架的问题。找了一下 /etc/apparmor.d/usr.sbin.mysqld 文件里写着/usr/sbin/mysqld可以访问的目录和权限。把新的目录加进去，就正常了
MySQL 跨库操作导致master-slave复制失败一例
最近我们的wowo网站的slave数据库经常出现INSERT操作时，email字段主键冲突导致无法继续执行的问题。但INSERT插入的那条数据之前已经存在于数据库中了。而在主库上，这条INSERT语句却执行正常。 我们根据email地址，找到了这个用户的注册来源，发现其中记录的UC_UID竟然和slave中的UID不同。 研究了一下binlog，发现是这样的 某个用户注册了wowo，于是在ucenter和ucenterhome库各有一条记录 该用户修改了email地址 该用户用旧的email又注册了一个用户，于是有了一个新的UID号 在执行到第三步的时候，slave数据库出现错误。 再对mysqlbinlog进行了繁琐搜寻，终于找到了问题所在： 修改email地址的时候，网站上的php程序用当前库为ucenterhome的一个mysql连接，跨库修改了ucenter库，而这个跨库的修改没有计入binlog，于是slave那里存储的还是旧的email地址。该用户用旧email地址又注册了一次的时候，slave发生了主键冲突问题。 最后，我取消了master数据库上的binlog-do-db选项，解决了这个问题。
