-
-
-
标签
API Backup bbPress Beta BuddyPress Bugs Cat Chinese Code Database Domain Drupal Effects Final Function Fushun Global Helix Server Language Linux Live Writer Mapping Multisite MySQL Network Pjblog Plugins RC RealPlayer Sandbox Slug Style Tags Test Theme Translate Update Upgrade vsftpd Web Wedding Windows WordPress MU WP Chinese Group WPCNG分类
- Asides (96)
- Computer Graphics (10)
- Cooking (3)
- Gallery (10)
- Streaming Media (17)
- System (13)
- Talk (118)
- WordPress (86)
- Work (33)
最新评论
-
| | | |
按标签归档:Database
14 条实用的 MySQL 查询语句
在使用 WordPress 的过程中,某些时候需要修正一些数据库方面的问题。相比之下,直接在数据库中执行查询语句是最便捷的。在这里,提供了 14 条非常实用的查询语句,可以帮助遇到类似问题的用户解决相应的问题。 如何执行 MySQL 查询语句 通常情况下,我们可以直接进入服务器的 MySQL 命令行中执行。也可以使用非常著名的 WEB 程序 PHPMyAdmin 进行查询。如果我们想在 WordPress 后台直接进行查询,还可以使用 SQL Executionner 这个插件对数据库进行操作。 注意:虽然以下提供的查询语句都已经经过测试。但是请不要直接在生产环境下运行,或者经过一定的测试再执行,毕竟每个人的站点环境可能略有不同。操作之前切记要对数据库进行备份操作。
规模化 WordPress 站点 Part 1:使用 MySQL 异步复制和 HyperDB
我们在使用 WordPress 的过程中,或多或少都会考虑到一个问题。那就是如何让自己的站点承载更大的访问量。或者说,在用户对您的站点进行访问的时候,页面的访问既完整又快速。 对于小型站点,我们通常的做法是使用 Cache 来提高服务器响应速度。不可否认,像 WordPress Super Cache 一类的缓存插件,在提高网站访问速度,降低服务器负担方面做的非常好。它可以将站点内很多相对变动不是很频繁的内容生成静态化的页面,可以有效降低数据库查询次数。无形中,提高了页面返回速度。给用户带来更好的体验。 但世事无绝对,缓存类的插件有时也无法胜任所有的服务器优化工作。总有些方面是缓存插件无法做到的。这个时候,我们就需要考虑换一种方式来加快网站访问速度了。 对于 MySQL 数据库的查询,有时是无法避免的。例如相对比较活跃的站点,页面变更比较频繁的站点。以及要求事实行非常强的网站。这个时候,就需要考虑 MySQL 的查询能力了。 而单一的服务器或单独一个 MySQL 数据库,在很多方面都无法完成大型网站的要求。这个时候,我们可以考虑使用集群数据库或者类似的数据库架构来保障网站的响应速度。 本文主要讨论的内容是使用 MySQL 异步复制(Replication)结合由 WordPress 开发的 HyperDB 来实现基于 WordPress 的大型网站部分服务器功能的架设。
我的 WordPress 站点合并过程
合并之前,我大概有或曾经有共三到四个站点。全部安装的是 WordPress。由于个人时间不是很多,照顾多个站点实在是有点力不从心。最后决定把多个站点合并到一起。这样既省时间也省了空间。 还好,我多个站点架设的环境都是一样的。合并起来不会出现数据库数据不兼容的问题。而且我在合并的过程中,并不是直接用 PMA 导出数据进行合并。而是应用到了 WordPress 后台自己的导出导入功能。 比较简单的方法,就是将不想继续开放的站点,使用后台导出功能,将站内的文章到处成 XML 文件。导出的数据包括日志、页面、分类、标签、附件信息等。等导出这些文件后。分别在想保留的这个站点的后台进行导入。附件也可以由程序自动从原来的站点下载并存放在目标站点中。 不过,这样操作以后,问题就出现了。大家可能知道,WordPress 数据库中的 wp-posts 这个表中有一个 guid 键值。这里记录了文章的最原始 URL 信息。无论你将数据导入到什么地方。这个信息是不变的。而当你批量修改了这个键值中的域名后。就出现了文章的 ID 重复的问题。虽然不影响直接的页面访问,但是对于 RSS 订阅等操作可能会有所影响。 那么,我是如何进行后续的整理操作的呢?请接着往下看。
WordPress 2.3 Final 发布了
各位乡亲,各位父老。报告大家一个好消息。 WordPress 2.3 Final 终于如期发布了,经过了一个多月的公开测试,核心程序已经相~~~当~~~地稳定了。撰写这篇文章地时候,还需要使用 SVN 才能拿到 Final 版的 WordPress 。不过当你看到这篇文章的时候,也许已经可以从官方站上直接下载了。 这次的升级,照比 2.2 以及以前的版本,增加了一个咣咣实用地功能,那就是传说中地 Tagging 支持。具体啥叫 Tagging 我想就不用俺介绍了把?只要你不是外星人,而且使用过一段 BLOG 。都应该知道地一个玩意。而且好处大大地。
站点调整基本结束
经过将近一个星期的时间,陆续把原来的主站(Drupal站)和博客站(Pjblog站)合并到一起。而现在这个站点又想使用Wordpress作为站点的程序。所以这期间经历了两次数据迁移的过程。
数据库清理告一段落!
忙活了差不多一天,用最笨的方法把这个站的数据库清理了一下。 原本以为能在网上找到什么吗对清理Drupal数据库有帮助的东西。可是找来找去也没有。算了,还是用咱自己勤劳的双手(寒一个)自己解决吧。
通过POST方式获取Helix Server的在线信息
RealNetworks 的 Helix Server 9.0.3.916 for Linux 版。多台服务器同时提供服务,需要做到负载平衡和服务器的实时监控,要做到以上要求,就需要实时的获取服务器的信息。 在 Helix 的控制台中发现了 Server Monitor 中的 Custom Logging 有个 HTTPPOST 方式,Helix 可以通过 HTTP 的 Post 方式将服务器的信息发送出去。 系统环境: 流媒体:Helix Server 9.03 (9.0.3.916) Web:Apache 2.0.50 + PHP 5.0.2 + MySQL 4.0.21 系统:RedHat Enterprise Linux … 继续阅读
Helix Server使用Flat File型数据库
大家都知道Helix Server支持连接ODBC各类数据库,在其中最常用的末过于ACCESS和MSSQL,但是在实际应用中这2者都有缺陷。 用Helix Server连接ACCESS时间长了就挂接不上数据库,而且ACCESS本身就是桌面型数据库,并发支持的不好,不适合多用户操作,更不适合应用在网络VOD这样操作数据库频繁的应用中,所以可以淘汰了;MSSQL数据库是微软出品的超大型数据库,可以胜任各种复杂任务,但是用Helix Server连接MSSQL也有问题,估计是因为Helix Server对ODBC支持的不好的原因,MSSQL不能释放Helix Server对数据库的调用资源,时间长了对系统资源造成极大浪费,MSSQL占用的内存和系统进程越来越多。



