你在这里


MySQL

在阿里云RDS数据库服务器中将MySQL InnoDB引擎表转为压缩格式

James Qi 2015年10月26日 - 16:56 发布

  今年以来将我们以前托管或者租用的服务器全面转向阿里云,除了采用ECS服务器以外,还有一项重要的是采用了RDS数据库服务器,这对于服务的稳定性、各项指标的监控、调优等都有帮助。

  不过随着近期更多数据库转到RDS上,空间的占用、IOPS的升高等问题也越来越明显,增加RDS空间、升级RDS规格肯定是有用的,但一味这样做的话,费用会明显飙升,还是得想办法优化。

  前一阵子也《试用阿里云RDS的MySQL压缩存储引擎TokuDB》,但因为文件数太多超过系统限制而放弃,也尝试过MyISAM引擎和InnoDB引擎的压缩方式,但阿里云客服说MyISAM已经不支持,所以剩下压缩这种方式现在又拿出来尝试。

试用阿里云RDS的MySQL压缩存储引擎TokuDB

James Qi 2015年7月12日 - 22:09 发布

  以前就用过自己搭建MySQL服务器的两种存储引擎MyISAM和InnoDB(也用过一点Memory方式),在今年初转向阿里云关系型数据库服务RDS的时候,看到可调参数中有一个TokuDB,不过不太了解也没有管。

  最近同事转给我阿里云介绍TokuDB的文章,其中压缩存储的特性对我们来说很有吸引力,因为我们的数据库一般都偏大,已经转到阿里云的就有几百个GB了,加上以后要转的肯定是TB数量级的,而且目前还是用的MyISAM,如果用InnoDB的话,那还要扩大数倍,仅仅是存储的费用就让人难以承受。但MyISAM存在表容易损坏的问题,往后用的人越来越少,Drupal 7 以后默认的支持引擎都改为InnoDB,阿里云也推荐不要使用MyISAM。

  据说这个TokuDB与InnoDB的特性很类似,而改用压缩方式后特别适合大数据时代的应用,但数据的压缩解压必定带来CPU在这方面的消耗,这不是大的问题,我关注的主要是IOPS和连接数是否会增加,如果这两个参数基本维持稳定的话,用CPU来换存储空间还是值得的、有余地的。

  虽然今天是周末,但也还是找了几篇文章、网站查看:

Drupal 7 Ubercart在MySQL 5.6中需要使用InnoDB引擎

James Qi 2015年7月10日 - 09:50 发布

  以前使用的MySQL存储引擎考虑到用多块硬盘放置各个库以便分散负载都是固定为MyISAM,现在搬迁到阿里云RDS后,考虑到查询效率及空间大小也保持继续用MyISAM。不过今天同事发现一个销售数据的网站在购物车结算的时候报错:

PDOException: SQLSTATE[HY000]: General error: 1785 When @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1, updates to non-transactional tables can only be done in either autocommitted statements or single-statement transactions,

  在网上搜索了一下,说是不支持事务的问题,奇怪了以前在MySQL 5.1用MyISAM却是好的,也许是MySQL升级到5.6之后的问题吧。我对数据库的所有表进行了批量转换为InnoDB后,报错就消失了。好在销售网站的数据量不大、访问量也小,转换后对于RDS容量和速度都不会有影响。

MySQL迁移到新数据库服务器后负载急剧升高的问题

James Qi 2015年2月26日 - 10:51 发布

  春节前忙着把一些网站从自己独立托管的服务器搬迁到阿里云的平台中去,以前自己的服务器都是购买的顶配硬件(几年前就是16核、64G内存、8块硬盘),安装Linux+Apache+MySQL+PHP在同一台机器上,现在用了云服务器ECS做Web服务器,用云数据库RDS做MySQL服务,应该来说更合理,不过实际运行中也遇到问题。

  先搬迁了几个小的网站,数据量不大、访问量不大,所以搬迁过去没有什么大的负载,ECS/RDS以及带宽什么都很富裕。但在搬迁一个数据量偏大、访问量也较大的网站时遇到问题,RDS的CPU总是100%,不运行自动检测超时MySQL进程并自动杀死该进程的脚本就完全不行,运行后算是可以维持,但一部分页面超时报错。

  我查看了一下,主要是MediaWiki的包含动态页面列表DPL扩展的页面报错,怀疑是RDS配置选的过低,数次升级硬件配置、费用也在不断升高,从260M到600M、1200M、2400M都还是不行,后来不知道怎么碰巧就好了,此后负载一直非常低、用高配置RDS明显有很大浪费,于是我又申请了一个新的RDS,准备迁移数据后退掉老的高配RDS,但在新的RDS上遇到同样的问题,从260M升级到600M、1200M后问题依然存在,我知道再升级也没用,还是有其它问题。

列出MySQL数据库服务器上所有库和表及引擎属性

James Qi 2014年5月2日 - 23:30 发布

  最近在对国内服务器进行硬盘的替换升级的时候,发现有一台服务器把数据库迁移到新硬盘后,以前的老硬盘依然非常繁忙(用iostat检查),仔细查看后,发现有一些MySQL数据库用的InnoDB格式,即使把数据库目录搬迁后,实际数据依然放置在以前的硬盘上。

  Drupal 7默认是采用InnoDB数据库引擎以利用其一些独特的特性,但我们的系列网站数据量很大,需要分散放置各子网站的数据库才好,所以我们都是改为使用MyISAM数据库,以前曾经修改过Drupal的Core文件来实现数据库引擎的变更,但这在Drupal系统升级的时候就丢失了,这样导致一些新建网站的数据库表,以及一些老网站中部分升级新产生的数据表,都采用了InnoDB引擎。

  以前发现上面这样的情况,我们都是单独修改引擎或者用程序批量修改,这在我以前的一篇博客文章《将Drupal 7默认的MySQL引擎从InnoDB改为MyISAM》中有记录,现在依然采用这个办法来批量修改。

Drupal页面内容的批量查找、替换的几种办法

James Qi 2013年5月22日 - 14:36 发布

  Drupal网站搭建好、数据导入或者编辑完成后,如果需要大批量修改内容,可以有多种办法:

1、最原始:MySQL语句

  找到MySQL数据库中需要修改的内容放置的字段,用MySQL UPDATE语句来直接替换,其运行效率最高,但实现不方便、出错后无法挽回、页面时间没有变化;

2、最傻瓜:Scanner模块

  今天找到一个用于search和replace的模块Scanner,安装试了一下,很容易使用,替换后是生成一个新的版本,如果有问题可以批量还原,选项也很丰富:大小写敏感查找、全词查询、加前后缀设置、正则表达式查找、分类查找、分内容类型查询、自定义字段查找、只查找不替换等;

3、最灵活:PHP程序

  以前也曾经编写过PHP程序来实现一些查找、替换,这就可以相当灵活,将各种条件进行组合,各种方式查找匹配,各种字段用于替换等,是否生成新版本可以控制,只是编写起来麻烦一些。

自由标签:

PHP程序匹配网站内页之间的互相链接

James Qi 2013年5月9日 - 09:19 发布

  今年初在搭建Profile Report网站时写了一篇《系列网站之间相同主题内页的互相链接》,当时主要是用VB编写程序来对导出的两个csv文件进行比较,然后计算出可以链接的node id,再用PHP程序或者人工的办法来添加链接,整个过程比较繁琐、自动化程序不高。

  此后又尝试了添加更多的数据到这个站,并进行按照省份分类等工作,就采取了PHP程序+MySQL数据库的方式,搜索匹配的效率大大提高,运行时间缩短很多。

  近期我们新增了一下几个网站:

自由标签:

Drupal多语言网站中MySQL数据库locales_source表过大的问题

James Qi 2013年3月8日 - 14:04 发布

  在《Drupal的MySQL过度膨胀,清理缓存、翻译表》这篇2012年8月的博文中,提到有些非英文网站的locales_source表不断变大的问题,当时在网上找了一些资料,临时先用删除表中某些特征的数据来解决,半年后再次逐步变大导致网站访问困难,又编写了一个自动删除表中记录的脚本来解决,但始终是治标不治本。

  这些天在对其它网站进行多语言扩充的时候,发现有些网站也有类似问题,都是locales_source中包含大量不需要进行翻译的内容,再次查找资料并逐步调试,终于是找到问题的根源并可以解决了,有两种情况:

Drupal网站内容类型、字段名称、页面数量的读取

James Qi 2013年3月4日 - 18:59 发布

  这些天在做系列网站的时候,遇到多个子网站、每个子网站都有多个内容类型,希望在首页展示内容类型、包含的字段名称以及页面数量,以前是人工来读取的,但网站多了就很麻烦,而且以后不便更新,这次用Drupal的API调用及SQL语句来实现了。

  站内读取的例子:http://hangye.mingluji.com/it/,源代码:

自由标签:

更改Drupal生成Sitemap中的最后修改时间

James Qi 2013年1月8日 - 10:15 发布

  用Drupal搭建网站中,我们通常是初期导入大量数据,后来再反复修改分类、Views、显示模板、菜单等项目来改善用户体验,特别是显示模板可能会在几个月、几年后多次修改,甚至是重要的全面修改,显示内容已经面目全非了,但搜索引擎的快照中还是以前的内容,没有及时重新抓取、更新排名。

  搜索引擎应该是基本参照网站的xmlsitemap中的页面最后修改时间lastmod、更新频率changefreq来决定是否回来抓取、多长时间回来抓取的,而Drupal生成的sitemap中某个页面的最后更改时间很可能就是当初创建的时间,但显示内容因为模板修改而早就不同了,造成修改后的内容无法及时被搜索引擎发现。

  这几天实验了一下,用一段php程序批量将Drupal页面的node时间($node->changed、$node->revision_timestamp)修改为当前时间或者比较早的时间后,再重建sitemap(可用drupal菜单rebuild xmlsitemap或者drush xmlsitemap-rebuild),确实可以达到修改sitemap中页面最后修改时间的目的。

自由标签:

页面

订阅 RSS - MySQL