With Tungsten Replicator Continuent is trying to deliver a better master/slave replication system. Their goal: scalability, reliability with seamless failover, no performance loss.

From their website:
The Tungsten Replicator implements open source database-neutral master/slave replication. Master/slave replication is a highly flexible technology that can solve a wide variety of problems including the following:

* Availability - Failing over to a slave database if your master database dies
* Performance Scaling - Spreading reads across many copies of data
* Cross-Site Clustering - Maintaining active database replicas across WANs
* Change Data Capture - Extracting changes to load data warehouses or update other systems
* Zero Downtime Upgrade - Performing upgrades on a slave server which then becomes the master

The Tungsten Replicator architecture is flexible and designed to support addition of new databases easily. It includes pluggable extractor and applier modules to help transfer data from master to slave.

read more

AdSense发布商和AdWords 广告商以及用户组成了一个相辅相成的体系，当网站内容和广告为用户带去价值的时候，用户才会访问网站和点击广告，发布商才能获得流量和收入，广告商才能获得客户；而只有当来自发布商网站的点击为广告商带来了良好的营销效果的时候，广告商才会继续在发布商的网站上投放广告。

为了维护这个体系的良性循环，我们制定了一系列的政策，用来保障良好的用户体验和有效的广告点击，帮助发布商获得稳定的用户来源和广告投入，从而最终实现发布商、广告商和用户的三方共赢。

因此，在投放广告的时侯，您应该先了解 AdSense 的政策，并确保自己投放的广告符合政策。

在以往的经验中，发布商对一些政策的具体规定提出了疑问，我们针对这些政策进行了详细的说明和介绍。为了避免您今后遇到相同的问题，建议您现在就读一下这些政策详解，避免违反政策的行为发生。

• 什么是成人内容？政策详细解读http://adsense.googlechinablog.com/2007/10/adsense_23.html
• 什么是版权材料？政策详细解读
  http://adsense.googlechinablog.com/2007/10/adsense_30.html
• 什么是鼓励点击？政策详细解读
  http://adsense.googlechinablog.com/2007/10/adsense_18.html
• 什么是误导性展示？政策详细解读
  http://adsense.googlechinablog.com/2007/09/adsense_04.html

了解并遵守 AdSense 政策，同时全力制作高品质的网站内容，将会帮助您获得更多的用户和广告来源，从而提高您的收益。

Over a year ago I wrote about pretty nasty Innodb Recovery Bug. I ran in the same situation again (different system, different customer) and went to see the status of the bug… and it is still open.

You may thing it is minor issue but in fact with large buffer pool this bug makes database virtually unrecoverable (if 10% of progress in 2hours qualifies as that). It is especially nasty as it is quite hard to predict. Both customers had MySQL crash recovery happening in reasonable time… most of the times until they run into this problem.

So what is the point ? Have modest expectations about when your favorite MySQL bugs are fixed (This is actually Innodb one, so Innobase/Oracle is responsible for fixing it not MySQL/Sun but there are MySQL bugs not fixed for years too). Look for workarounds or ways to fix things yourself.

In particular case workaround was rather easy - reducing Innodb buffer pool size to 4GB instead of 24G and disabling innodb_flush_method=O_DIRECT so OS cache can be used for IOs. This made database to complete crash recovery in 30 minutes.

---

Entry posted by peter | No comment

Add to: | | | |