"\u003cp\u003eMysql5.5慢查询开启有些改变,在my.cnf的 [mysqld]　section 添加以下几行即可．注意一定要在[mysqld]块，否则不起作用.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003elong_query_time = 0.001\nslow-query-log = ON\nslow_query_log_file = /usr/local/mysql/data/slow.log\nlog-queries-not-using-indexes = on\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e===================================================\u003c/p\u003e\n\u003cp\u003emysql有一个功能就是可以log下来运行的比较慢的sql语句，默认是没有这个log的，为了开启这个功能，要修改my.cnf或者在mysql启动的时候加入一些参数。\n如果在my.cnf里面修改，需增加如下几行\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003elong_query_time = 10\nslow_query_log  = /var/log/slow.log\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003elong_query_time 是指执行超过多久的sql会被log下来，这里是10秒。\nslow_query_log  设置把日志写在那里，为空的时 …\u003c/p\u003e"

"\u003cp\u003e【51CTO独家特稿】笔者目前是一位外企linux/unix系统工程师与项目实施工程师，而FreeBSD一直作为我们企业内部的开发服务器，具有稳定和高效的特点。本文根据笔者经验总结了十四条FreeBSD的优化策略。如无其它，以下所指FreeBSD均指FreeBSD 8.0_release。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一、提高ports安装速度\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eFreeBSD中的ports安装工具默认工具是用fetch，下载时经常出现龟速现象。为了提高ports安装速度，我推荐axel工具。相关make.conf文件配置步骤如下：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e\n\n cd /usr/ports/ftp/axel\n\n\n\n\n make install\n\n\n\n\n #修改/et/make.conf\n\n\n\n\n vi /etc/make.conf\n\n\n\n\n #加入以下内容\n\n\n\n\n FETCH_CMD=axel\n\n\n\n\n FETCH_BEFORE_ARGS= -n 10 -a\n\n\n\n\n FETCH_AFTER_ARGS=\n\n\n\n\n DISABLE_SIZE=yes …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e一般来说，你有两种可供选择的备份MySQL的方式—-mysqldump 或者mysqlhotcopy。\u003c/p\u003e\n\u003cp\u003emysqldump可以备份各种类型的数据表，但是mysqlhotcopy \u003ca href=\"http://dev.mysql.com/doc/refman/5.0/en/backup.html\"\u003e只适合\u003c/a\u003e 备份MyISAM和ISAM的数据表。所以使用mysqlhotcopy之前，你必须确认你的数据表是不 是有其他的存储引擎(storage engines)的。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHow To：\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003emysqldump -u root -p*** DBNAME | gzip -f\u0026gt;/backup/dbname.’date +%w’.dump.gz\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003emysqlhotcopy DBNAME -u root -p *** /backup\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e**两者速度：**因为 mysqlhotcopy会直接拷贝存储数据的文件，所以其速度是依赖于磁盘操作的速度，较之mysqldump要快些。下面是两种方式备份同一个数据的 时候的时间消耗比较：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003emysqldump  耗时22分39秒（gzip 压缩后文件大小为747M.）\u003c/li\u003e\n\u003cli\u003emysqlhotcopy  耗时6分07秒（tar gzip打包压缩后文件大小为1014M.）\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e参考： …\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2010/06/3455232156_dc09e11b22_o.jpg\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/3455232156_dc09e11b22_o.jpg\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://www.flickr.com/photos/26825745@N06/3455232156/\" title=\"replication by orczhou, on Flickr\"\u003ereplication by orczhou, on Flickr\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e在使用MySQL的应用中，如果你的MySQL Server压力逐渐增大，在应用层优化已经到了一定瓶颈时，那么你应该首先考虑 \u003ca href=\"http://dev.mysql.com/doc/refman/5.0/en/replication.html\"\u003eMySQL Replication\u003c/a\u003e。本文将利用图示的方式简单的描述出MySQL Replication是如何工作的。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e如何同步\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e主库将所有的更新操作，写入二进制日志。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e从库运行”IO线程”（Slave IO Thread）读取主库的二进制日志。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e从库运行”SQL线程”（Slave SQL Thread）执行IO线程（Slave IO Thread）读取的日志中的SQL,从而保持和主库的一致。\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003cstrong\u003e如何分配请求\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e目前，这部分需要在应用层实现。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e执行更新SQL(UPDATE，INSERT，DELETE)时，请求主库。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e执行查询SQL(SELECT)时，请求从库。\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e所以，当你的应用(Application)SELECT请求所占的比率越大，那么Relication就会越有效。\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003eExplain ID详解\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e含义：select查询的序列号，是一组数字，表示的是查询中执行select子句或者是操作表的顺序。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eid的情况有三种，分别是：\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eid相同表示加载表的顺序是从上到下。\u003c/li\u003e\n\u003cli\u003eid不同id值越大，优先级越高，越先被执行。\u003c/li\u003e\n\u003cli\u003eid有相同，也有不同，同时存在。id相同的可以认为是一组，从上往下顺序执行；在所有的组中，id的值越大，优先级越高，越先执行。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e再看一个查询计划的例子：\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://blog.haohtml.com/wp-content/uploads/2010/06/mysql_explain.png\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/mysql_explain.png\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e执行顺序依次为 4 -\u0026gt; 3 -\u0026gt; 2 \u0026gt; 1 \u0026gt; NULL\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e第一行：id列为1，表示第一个select，select_type列的primary表示该查询为外层查询，table列被标记为，表示查询结果来自一个衍生表，其中3代表该查询衍生自第三个select查询，即id为3的select。[select d1.name……]\u003c/p\u003e\n\u003cp\u003e第二行：id为3，表示该查询的执行次序为2（4→3），是整个查询中第三个select的一部分。因查询包含在from中，所以为derived。[select id,name from t1 where other_column=”]\u003c/p\u003e\n\u003cp\u003e第三 …\u003c/p\u003e"

"\u003cp\u003e章文嵩博士（LVS开源项目创始人）进入淘宝好几个月了，今天是他第一次讲解LVS的实现原理。作为DBA的一员，终于近距离膜拜了大牛。\n讲解的内容就不具体介绍了，在\u003ca href=\"http://www.linuxvirtualserver.org/whatis.html\"\u003eLVS 官方网站\u003c/a\u003e上面可以找到。PPT的内容和网站上基本上一样，只是讲解人是章博士本人。我在这整理一下自己的理解，不对请大家指正。 ^_^\u003c/p\u003e\n\u003cp\u003e组成LVS最重要的部分有三个：请求分发服务器、处理服务器、共享存储。\u003c/p\u003e\n\u003cp\u003e典型的Web集群并不需要共享存储，只有请求分发服务器和处理服务器，如下图所示：\n[\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/LVS_WEB-300x245.jpg\" alt=\"\"\u003e][2]\n如果完成请求需要基于数据，那么共享存储就是LVS必须的组件了。LVS邮件服务器集群如下所示：\n[\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/LVS_MAIL.jpg\" alt=\"\"\u003e][3]\n目前能应用于LVS的MySQL集群只能是NDB Cluster，因为MySQL众多的存储引擎中，只有NDB Cluster实现了共享存储的功能。\n在NDB Cluster中，SQL Node相当于处理服务器，Data Node相当于共享存储。LVS可以让应用程序的开发更加简单，开发人员并不需要知道执行SQL的数据库服务器到底是哪一个，但是可以获得自己想要的数 据。而NDB Cluster提供的数据拆分和扩容功能，保证了数据库的可扩 …\u003c/p\u003e"

"\u003cp\u003emysqldump是非常重要的MySQL备份工具。然而在长年累月的使用过程中，TAOBAO多次出现了因mysqldump意外终止而导致备份 失败的情况。\n以下是我们经常遇到的问题：\u003c/p\u003e\n\u003cp\u003e1、Lost connection to MySQL server at ‘reading initial communication packet’：\n这个主要是因为DNS不稳定导致的。如果做了网络隔离，MySQL处于一个相对安全的网络环境，那么开启skip-name-resolve选项将会最大 程度避免这个问题。\u003c/p\u003e\n\u003cp\u003e2、Lost connection to MySQL server at ‘reading authorization packet’：\n从MySQL获取一个可用的连接是多次握手的结果。在多次握手的过程中，网络波动会导致握手失败。增加connect_timeout可以解决这个问题； 然而增加connect_timeout并不能防止网络故障的发生，反而会引起MySQL线程占用。最好的解决办法是让mysqldump重新发起连接请 求。\u003c/p\u003e\n\u003cp\u003e3、Lost connection to MySQL …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e“And God said, Let there be network: and there was timeout”\u003c/strong\u003e\n在使用MySQL的过程中，你是否遇到了众多让人百思不得其解的Timeout？\n那么这些Timeout之后，到底是代码问题，还是不为人知的匠心独具？\n本期Out-man，讲述咱们MySQL DBA自己的Timeout。\u003c/p\u003e\n\u003cp\u003e先看一下比较常见的Timeout参数和相关解释：\n\u003cstrong\u003econnect_timeout\u003c/strong\u003e\nThe number of seconds that the mysqld server waits for a connect packet before responding with Bad handshake.\n\u003cstrong\u003einteractive_timeout\u003c/strong\u003e\nThe number of seconds the server waits for activity on an interactive connection before closing it.\n\u003cstrong\u003ewait_timeout\u003c/strong\u003e\nThe number of seconds the server waits for …\u003c/p\u003e"

"\u003cp\u003e在经历了2009年的分布式启步之后，经过改造的数据库系统性能得到极大的提升，但这个变化仍然不构成今天这篇文章的主题，我想要说的是另外一方面的变 化，这个变化在某种程度上影响着当前DBA的角色变化问题。\u003c/p\u003e\n\u003cp\u003e在分布式数据库时代，开发DBA的开发支持工作相比于以前，会有更多的系统思考问题的机会，会结合应用来设计量身定做的分布式数据库系统，如果一个DBA 对业务有着深刻的理解，深刻理解数据库原理，既具有整体性的架构思维，又有一些关键细节把握能力的时候，设计一套分布式系统是水到渠成的事。对于开发支持 的一些工作，比如SQL审核，表结构变更，数据订正，历史迁移，如果没有工具的支持，那做起来还是比较吃力的。这些方面，我们还有许多的道路要走，怎么样 改变目前的现状。\u003c/p\u003e\n\u003cp\u003e在分布式数据库时代，系统DBA的运维要求难度在某方面有所降低，整个应用因为在容错性方面做了比较多的努力，比如down掉一个数据库时，对于整个应用 系统的健康运行影响较小,运维的压力相对减少。相比于集中式的数据库环境下的运维，在另外一个层面运维难度又有所增加，第一，运维的机器数量呈几何指数的 增长，由于大量采用低端机器，集群中某个机器出问题的 …\u003c/p\u003e"

"\u003cp\u003e微软的\u003ca href=\"http://msdn.microsoft.com/en-us/library/ms229042.aspx\" title=\"框架设计规范\"\u003e框架设计规范\u003c/a\u003e{#h.u8}是 设计的准则，它期望所有的微软类库和独立开发者都能够遵循这一准则。随着每个.NET框架版本的发布，以及在行业内的测试，它们的版本也得到了精化。通过 Cwalina与Abram所著的\u003ca href=\"http://blogs.msdn.com/brada/archive/2008/10/14/framework-design-guidelines-2nd-edition-order-yours-now.aspx\" title=\"《框架设计规范》第二版\"\u003e《框 架设计规范》第二版\u003c/a\u003e{#t.q.}的发布，我们可以看到微软在今后几年的发展方向。\u003c/p\u003e\n\u003cp\u003e或许最令人惊讶的事实是日渐增长的对于测试驱动开发和依赖注入的重视。在可重用框架的场景下，通过测试驱动开发设计出的框架是真实可用的，而不是简 单地推理。他们希望这样可以反过来杜绝某种趋势，那就是过度复杂地设计一些根本不会用到的功能。\u003c/p\u003e\n\u003cp\u003e谈到这一问题，就不得不指出的是微软当前正在推动的一个活动，即针对所有库的第1个版本进行最低限度设计。这不同于在第一次就要试图将所有事情做 对，微软推荐在最开始只需要满足需求中绝对需要的特性。Abrams和Cwalina建议在最初并不需要考虑扩展性，只有到需求变得非常清晰的时候，才在 后一个版本中考虑。从某个方面来讲，这是微软旧有传统的回归，它只会在第三个版本中提供真正完成的应用程序。\u003c/p\u003e\n\u003cp\u003e在其它领域，微软则完全没有改变。他们仍然强调所谓的“基坑成功（Pit of …\u003c/p\u003e"

"\u003cp\u003e统架构师角色关键的一方面就是衡量相互冲突的需求、决定解决方案，常常要牺牲一个方面来换取另一个方面。随着系统变得越来越大、越来越复杂，越来越多关于 如何构建应用的传统智慧正在受到挑战。比如说，去年3月在伦敦召开的QCon会议上，Dan Pritchard谈论了eBay的架构。他的介绍随后得到了很多的报道，其中一个主要的结论就是eBay不使用事务，用数据一致性上的损失来换取系统整 体伸缩性和性能上相当大的改进。\u003c/p\u003e\n\u003cp\u003eInfoQ接着Dan Pritchard在QCon会议上的谈话与他继续讨论，以获得更多信息：\u003c/p\u003e\n\u003cp\u003e为什么eBay不使用事务，或者为什么可以决定不采取应用级事务？\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e我们并非一概不使用事务。我们只是不使用跨物理资源的事务，因为它会造成多个组件之间出现依赖。组件可以是应用服务器和数据库。（例如在客户端控制 的事务中，）一个客户端的失败会长久地阻塞数据库资源、超出我们的忍受程度。我们也不使用分布式事务，因为让应用依赖于多个数据库会降低客户端实际的可用 性。相反，我们选择缺少事务的设计，并加入失效模式，失效模式可以使客户端甚至在发生数据库可用性问题的时候也能继续进行。\u003c/p\u003e\n\u003cp\u003e应用级事务总是有些问题。 …\u003c/p\u003e\u003c/blockquote\u003e"

"\u003cp\u003e在前一期 \u003ca href=\"http://www.chedong.com/blog/archives/001447.html\"\u003e山寨交流会\u003c/a\u003e 上： \u003ca href=\"http://home.51.com/diary.view.php?user=gusingchen\u0026amp;id=10038668\"\u003e桂 新\u003c/a\u003e 说他会将良好的构架和一套完整的监控系统作为两个非常重要的基础来抓，良好的架构一步到位这点很难做到（对于发展速度并不确定的小公司来说，架 构过大也是一个成本上的风险），但对于后者：一套完整监控系统我是非常认同的。对于目前普遍缺乏测试的Web应用开发过程来说，监控几乎就是测试很重要的 一部分；而系统监控本身，也可以帮助及时发现很多问题并量化优化的效果。而系统的扩展和调优的大部分技巧都可以从《构建可扩展的Web站点》(作者是 Flickr的开发者)一书中看到。为了减少不必要的调优（盲目的调优是危害很大的），建议从这2章开始看起： 第8章《瓶颈》发现和第10章《统计数据，检测和报警》；有了这些瓶颈检查结果和统计监测/报警系统后，再有针对性的看其他章节做系统调优。\u003c/p\u003e\n\u003cp\u003e以下是我在 \u003ca href=\"http://chedong.blogbus.com/logs/29595744.html\"\u003e博客大巴\u003c/a\u003e 开 发中的一些实践小结：\u003c/p\u003e\n\u003cp\u003e1 数据库相关\u003c/p\u003e\n\u003cp\u003e1.1 系统应用层面出问题我一般都习惯性的先去看数据库群的连接数统计：大部分应用最后的瓶颈都在于单表数据量过大后，数据存取慢导致的并发连接数过多的问题，\u003c/p\u003e\n\u003cp\u003e1.2 解决这个问题目前的主要策略就是分片( \u003ca href=\"http://www.dbanotes.net/database/database_sharding.html\"\u003eshare nothing\u003c/a\u003e)，单个数 …\u003c/p\u003e"

"\u003cp\u003e在前不久结束的 \u003ca href=\"http://qconsf.com/\"\u003eQCon 2008\u003c/a\u003e 上，MySpace 的首席架构师 \u003ca href=\"http://jaoo.dk/london-2008/speaker/Dan+Farino\"\u003eDan Farino\u003c/a\u003e 做了题为 \u003ca href=\"http://qconsf.com/sf2008/file?path=/qcon-sanfran-2008/slides//DanFarino_Myspace.pdf\"\u003eBehind the Scenes at MySpace.com\u003c/a\u003e (PDF 下载)的技术演讲。\u003c/p\u003e\n\u003ch4 id=\"架构概况\"\u003e架构概况\u003c/h4\u003e\n\u003cp\u003e超过 4,500 台 Web 服务器，配置为 Windows 2003/IIS 6.0/ASP.NET ；超过 1200 台 Cache 服务器，64 位的 Windows 2003，超过 500 台的数据库服务器，配置为 64 位的 Windows 2003，数据库为 SQL Server 2005 。\u003c/p\u003e\n\u003cp\u003e之前曾有一篇 \u003ca href=\"http://www.baselinemag.com/c/a/Projects-Networks-and-Storage/Inside-MySpacecom/\"\u003e揭 秘 MySpace 架构\u003c/a\u003e的文章，也有中文版本《 \u003ca href=\"http://www.kuqin.com/system-analysis/20071230/3238.html\"\u003e亿万用户网站 MySpace的成功秘密\u003c/a\u003e》！\u003c/p\u003e\n\u003ch4 id=\"运维数据收集\"\u003e运维数据收集\u003c/h4\u003e\n\u003cp\u003e其实这个演讲我感觉主要讲的是这个数据收集模块 🙂 MySpace 的方案倒是让我们看到了在超大规模的 Windows 环境下如何进行数据收集的。\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2010/06/1626170.png\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/1626170.png\" alt=\"myspace系统架构\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e每个客户端通过一个 TCP 连接到收集上服务器。收集的信息包括：Windows 性能计数器 Performance Counters、 WMI 对象(定制后的 WMI 对象)、事件日志、 硬件数据等等。收集器服 …\u003c/p\u003e"

"\u003cp\u003e从老高的近期工作总结中看到：\u003c/p\u003e\n\u003cp\u003e目前的技术状况是基于自行设计的 PHP 框架，跑在 PHP 5.2 + MySQL 5.1 下，PHP 使用 Fastcgi 模式，WebServer 选择了 Nginx。搜索功能基于 Lucene 开发。缓存代理使用 Varnish。\u003c/p\u003e\n\u003cp\u003e对老高进行了一次非正式采访，聊了不少内容，整理了一下和大家分享。(谁是高春辉? 这个不要介绍了吧，请 Google! )\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e历史情况\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eFenng: 原来大约是用什么? 框架用的什么？\n高春辉: 你说老系统？Apache 1.3 , DB 是 MySQL 4.0。新框架是团队自己写的，定制了一些东西吧，主要强调的是性能和方便、简单。另外把针对 YSlow 的优化也做进去了。\nFenng: 单说现在用的框架，大约投入了多少个人/天 ?\n高春辉: 从全年开始考虑写，一直不断的写 — 具体时间不好说。反正是不少了 🙂\nFenng: 看了你 Blog 中的描述，有个小疑惑：没使用面向 DB 的 Cache 层?\n高春辉: 我文中说的 Data accessor 就算是了。目前是拿 PHP 做的，Client+Server 集成在一 …\u003c/p\u003e"

"\u003cp\u003e基于ID的分片机制实现存储的分布化会遇到一个问题：固定存储空间随着时间增加再次达到系统的空间/负载的瓶颈。观察了一下Flickr的图片存储 地址：好像是在定期启用新的集群，各个时期的域名分布如下：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003ca href=\"http://farm1.static.flickr.com\"\u003ehttp://farm1.static.flickr.com\u003c/a\u003e 2006年中以前；\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://farm2.static.flickr.com\"\u003ehttp://farm2.static.flickr.com\u003c/a\u003e 2006年底；\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://farm3.static.flickr.com\"\u003ehttp://farm3.static.flickr.com\u003c/a\u003e 2007年底；\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://farm4.static.flickr.com\"\u003ehttp://farm4.static.flickr.com\u003c/a\u003e 2008年底；\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e\u003ca href=\"http://www.kuqin.com/shuping/20081003/20540.html\"\u003e《构建可扩展的Web站点》\u003c/a\u003e 上 没有提到这个策略，猜测Flickr应该是不断在启用新的服务器集群，当地一个集群用到90%的时候，开始启用下一个集群。一个用户的所有图片地址则存储 在数据库中：记录会包含当时的存储所在的集群：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003euser_foo – farm1.static……/20060124_003.jpg\u003c/p\u003e\n\u003cp\u003e\\ farm1.static……/20060324_005.jpg\u003c/p\u003e\n\u003cp\u003e\\ farm1.static……/20060824_021.jpg\u003c/p\u003e\n\u003cp\u003e\\ …\u003c/p\u003e\u003c/blockquote\u003e"