-
小试 MariaDB Galera Cluster
前些时, 难得老板关注新技术, 哈哈, 我于是有机会尝试一下数据库服务器集群. 什么是 Galera Cluster? 简单的说就是3个或以上的 MariaDB 服务器相互作为镜像. 详细介绍在这里. 我按照 Digital Ocean 的指点, 用 AWS 上 3 个虚拟机做了个最小的集群, 下面是我的一些心得(针对 MariaDB 10.0.17): 首先集群的成员个数一定是奇数, 也就3, 5, 7… 因为有的时候个别成员的数据出现异样的时候, 整个集群会以”少数服从多数”的方式修正数据. 虽然集群是 master – master 方式进行数据同步的, 但如果多个成员同时更新相同的数据集合时, 集群内就很容易出现冲突, 这也就降低了性能以及可靠度. 目前我觉得可行的应用方式, 就是将所有的数据更新(insert, update, delete)都集中到一个成员上, 然后所有的查询(select)可以由所有成员分担. 就好像传统的 master – slave 方式, 嗯, 比较失望, 不过至少倚靠 HAProxy, 当一个成员挂了会自动有另一个来接替, 也不会耽误太多的事情. 估计还有一段距离才能把 Galera…
-
LVM 快照(snapshot)的第二种用法
之前我已总结了 LVM 快照的第一种用法: 利用 LVM 在线抓取 MySQL 数据库快照, 也可以扩展到任何需要在线生成磁盘快照的应用. 自 LVM 2.0 以来, 镜像分区不只是只读的, 而且可写. 而写入快照分区的一种应用就是造”沙盒(sandbox)”, 在 Xen VM 环境的具体步骤如下: 1, 假设供测试的虚拟机 test, 分区是 /dev/vm/test-disk, 为其生成 10GB 快照分区 test-ss: lvcreate -s -n test-ss -L10G /dev/vm/test-disk 2, 将 test 虚拟机关机, 可以 ssh root@test “shutdown -h now” 或者 xm shutdown test 3, 复制 /etc/xen/test.conf 到 test-s1.conf, 并将磁盘分区…
-
利用 LVM 在线抓取 MySQL 数据库快照
续 小试分身 MySQL Replication, 上次是按照 MySQL 教程做的, 比较死板(或者说, 安全), 但需要锁住数据库, 也就是说, 用户一端的感觉就是服务器出问题了… 而如果通知用户服务器要下线一段时间的话, 又会引起不明真相的用户的莫名猜疑. 那么就需要一种在几秒中之内完成生成镜像的操作, 于是我就想到了 LVM snapshot. Google 了一番, 我看到已经有成功先例了, 步骤如下: 1, 确认 MySQL 的数据区(缺省 /var/lib/mysql) 是在 LVM 上, 假设是 /dev/VOLUME_GROUP/data 2, 开一个 MySQL session, 执行并记录 show master status 的输出: flush tables with read lock; show master status; 3, 在另一个 terminal 执行: lvcreate -s…
-
Linux 命令行上的文字处理
总是有些用户, 明明是自己手抖点错了, 却偏偏要怪服务器出问题. 如果让我选择相信一个人还是一台机器, 那… 还是选机器比较放心. 当然也不能冤枉好人, 于是如何从若干 GB 的服务器日志里找到线索就成为解决问题的关键了. 首先是 grep. grep 就好像是个过滤器, 将无关的内容滤掉, 却从不漏下真相. 假设服务器日志是 server.log, 其中包含时间, 地点, 人物: 1, 找出所有含 beijing 的记录 grep beijing server.log 2, 包含 2013-12-01 当天, 在 beijing 关于 user 的记录 grep -E -e ‘2013-12-01.*beijing.*user’ server.log 3, 也可以将 grep 串联起来, 逐步缩小包围圈, 这样如果个别记录不符合时间, 地点, 人物的顺序, 也不会被漏掉. 当然我觉得日志还是规矩一点的好. grep ‘2013-12-01’ server.log…
-
用 MariaDB 替换 MySQL
自从 MySQL 被邪恶的 Oracle 收购后, 貌似就到了后娘手里, 基本没什么发展. 不过还好, 原创班子已另起炉灶, 在 MySQL 5.5 的基础上做出很多改良, 发布了 MariaDB 5.5. 另外一个好消息就是终于看到了国人在开源圈子里的贡献: MariaDB 10.x 分支就包含了来自淘宝的两处贡献: https://mariadb.com/kb/en/what-is-mariadb-100/ <–在这页上找 taobao 即可. 希望这样的案例越来越多吧. 免费使用开源软件, 在事业成功之后回馈开源社区, 这是个良性循环. 目前我试用了 MariaDB 5.5, 是 MySQL 5.5 的完美替代品. 安装方法在此: https://downloads.mariadb.org/mariadb/repositories/#mirror=aarnet_pty_ltd&distro=Debian&distro_release=squeeze&version=5.5 另外如果用 Ruby 的 mysql2 gem 的话, 需要安装 libmariadbclient-dev(debian/ubuntu). 而如果 innotop 这个小工具不灵的话, 很可能需要安装 libterm-readkey-perl. 🙂
-
小试分身 MySQL Replication
打理数据库服务器, 再怎么优化终究会面临一台再强的服务器也不够用的时候. 那就使用多台服务器做 Replication 吧. 先从2台 MySQL 服务器开始, 一台为主, 另一台为从. 基本的步骤是(装系统/装软件/配置网络连接什么的就略过了… 1, 在主服务器的配置(/etc/mysql/my.cnf)里添加 [mysqld] log-bin=/var/log/mysql/mysql-bin.log server-id=1 然后重新启动 mysql 服务. 2, 在从服务器的配置里添加 [mysqld] server-id=2 然后重新启动. 3, 在主服务器上添加 replication 专用用户, 例如 repl create user ‘repl’@’%.<domain.name>’ identified by ‘<pass>’ ; grant replication slave on *.* to ‘repl’@’%.<domain.name>’ ; flush privileges ; 4, 锁定主数据库, 记录 bin-log 指针位置并导出数据 flush tables…
-
笔记: Xen VM 里面的 MySQL 服务器优化
我一直都对公司 Xen VM 的数据库服务器不满, 因为实在是太慢了. 但是几百个 GB 的商业数据我可不敢动, 于是先在测试服务器上证实一下我的想法. 测试环境是: Dom0: Debian 6 Xen Hypervisor 64-bit, Xen 4.0 DomU: Debian 6 64-bit MySQL server 5.1, innodb_file_per_table, pool=1GB, log=256MB 硬盘就是普通的 SATA 7200RPM, VM 用的是 LVM 分区 然后我用之前写的一个小程序做批量更新, 32K 记录. 缺省配置下, 运行时长达到24分钟, 而优化后则只需要27秒. 差不多60倍?? 我都有点不敢相信了. 下面是对应的配置和测试数据. 每次更改配置后都会重启 MySQL, 因此不大可能是缓存在起作用. Updating 32606 records (client table), InnoDB table, autocommit=true,…
-
CloudFront CDN 一箭双雕
今天, 终于启动了 Amazon CloudFront CDN 服务. 之前老板交给我两个任务: 减少数据中心托管服务器的数据流量, 因为费用相当高 改善服务质量, 降低用户等待时间 于是我建议尝试 CDN(Content Delivery Network) 服务, 一举解决两个问题. 初步测试后, 皆大欢喜, 除了数据中心, 因为下个月他们给我们账单上的数字会小很多. 使用 CloudFront 很简单, 假设目前的图片服务器是 assets.mysite.com, 只需要把 assets 设置成 CNAME, 指向自己 CloudFront 账号里的地址(xxxxxx.cloudfront.net), 然后给原来的 assets 一个新名字, 例如 assetsdirect.mysite.com, 让 ClouldFront 将 assetsdirect 设置为源. 等待全部更改生效后, 就可以了. PS. 本 Blog 使用了 CloudFlare 提供的免费 CDN 服务, 特此表示感谢. 🙂