• 共享
  • ?
  • 个人档案 ▼
  • 社区 ▼
  • 应用程序 ▼

博客

  • 我的博客
  • 公共博客
  • 我的更新

此社区可以包含贵组织以外的成员。 Portal administration and performance

  • 登录以进行参与

▼ 标签

▼ 类似的条目

How to achieve bette...

博客: Thoughts from...
AjayMPatil 31000030FM
更新时间
共有 0 个人对此内容点赞点赞的项目 0
无评论评论 0

SQL1782N on Create D...

博客: Thoughts from...
AjayMPatil 31000030FM
更新时间
共有 0 个人对此内容点赞点赞的项目 0
无评论评论 0

Enhance healthcare s...

博客: Storage ISV
SandeepZende 2700073BPY
更新时间
共有 0 个人对此内容点赞点赞的项目 0
无评论评论 0

Historical Database ...

博客: Network and S...
Toni_Id 060001M7HX
更新时间
共有 3 个人对此内容点赞点赞的项目 3
无评论评论 0

How a Single Databas...

博客: CSE-WebSphere...
Andres Voldman 06000265WS
更新时间
共有 0 个人对此内容点赞点赞的项目 0
无评论评论 0

▼ 类似构想

Statistics in Netezz...

构想博客: IBM PureData-...
DeepashriKrishnaraja 270001C7Y3
更新时间
得票 1 评论评论 3

▼ 归档

  • 2018年3月
  • 2017年12月
  • 2017年10月
  • 2017年9月
  • 2017年2月
  • 2017年1月
  • 2016年10月
  • 2016年9月
  • 2016年7月
  • 2016年5月
  • 2016年3月
  • 2016年2月
  • 2015年11月
  • 2015年10月
  • 2015年9月
  • 2015年6月
  • 2015年4月
  • 2015年3月
  • 2015年2月
  • 2015年1月
  • 2014年11月
  • 2014年9月
  • 2014年7月
  • 2014年6月
  • 2014年4月
  • 2014年3月
  • 2013年10月
  • 2013年8月
  • 2013年6月
  • 2013年5月
  • 2013年3月
  • 2013年2月
  • 2012年11月
  • 2012年10月
  • 2012年9月
  • 2012年8月
  • 2012年7月
  • 2012年6月
  • 2012年3月
  • 2011年11月
  • 2011年9月
  • 2011年8月
  • 2011年6月
  • 2011年5月
  • 2011年2月
  • 2010年10月
  • 2010年9月
  • 2010年8月
  • 2009年7月
  • 2009年6月
  • 2009年3月
  • 2009年2月
  • 2008年8月
  • 2008年5月
  • 2008年4月
  • 2008年3月
  • 2008年2月
  • 2008年1月

▼ 链接

  • Portal L2 Blog
  • Thoughts on Web Content Manage...
  • Web Content Manager Forum
  • WebSphere Portal Forum
  • WebSphere Portal Security, Por...
  • WebSphere Portal zone

▼ 博客作者

Portal administration and performance

查看所有条目
单击此按钮可以刷新整个页面。用户可以转至“条目列表”区域查看新内容。) 条目列表

What database domains are sharable?

mlamb 100000SCY2 | | 标签:  clustering domain database ‎ | 6 条评论 ‎ | 9,565 次访问

In WP 6.0, we broke up our configuration and content repository databases into "domains", or database instances/schemas that are organized by function. The intention of these domains is to allow them to be located separately from each other, and in some instances, shared between multiple identical portal clusters. The domain-based organization also enabled some functional features, such as loose-coupling between customization data and static release data, but that isn't the subject of this blog entry.

Geographic deployments is core to WebSphere Portal's ability to deploy global portals and meet 24x7 uptime goals. To facilitate this, certain database domains must be shared across deployments, to ensure consistency of data for all end-users.

The database domains are:

  • release: contains static portal configuration, such as pages, portlets, and entitlements
  • community: contains community-oriented portal configuration, or that shared across a small group of users, but is not user-specific. Composite application instance configuration goes here.
  • customization: contains user-specific configuration, such as customized portlets and pages
  • likeminds: used to hold information about e-commerce selection trends across multiple users, and provides a recommendations engine for providing selections to end users based on similar purchase trends. Likeminds is a feature of the Personalization service.
  • feedback: used to hold information about what Personalization rules are being used, what parameters feed into those rules and what their results are. Feedback is a feature of the Personalization service.
  • wmm: used to hold user and group information that is otherwised not maintained by the underlying user repository, such as through the use of the "lookaside" feature. It can also serve as the user repository underneath a custom user registry based on the WMM APIs.
  • jcr: the Java content repository holds several different types of data, including WCM content, Personalization rules, and policy definitions.

The release, feedback, and likeminds domains should be unique per cluster. Since feedback and likeminds are rarely used, you can include their schemas along with the release domain in the same database instance if you like. Even if those features are in use, to keep the deployment simple, I still recommend maintaining them with the release domain. Keeping the release domain specific per cluster is essential for allowing one cluster to be serviced while allowing other identical clusters to remain in production.

The community, customization and wmm domains should be shared across all identical clusters, as they contain end-user information which must be common across these clusters. That means all clusters can either refer to the same DB instance that holds these three domains, or you can employ 2-way replication to keep them synchronized. If you use 2-way replication, the replication frequency should be less than the event that triggers a user-binding to a particular cluster. You do not want an end-user rerouted to a different cluster BEFORE their data is replicated over. The trigger depends on your global load balancing logic, but I prefer domain-based routing since it pretty much guarantees that a particular user will go to a particular cluster/datacenter unless there is a failure causing the user to be rerouted to another cluster. DNS-based routing is problematic because hostnames could be re-resolved at any time, even during a user's active session with a particular cluster.

The last domain, jcr, is special, because it can contain both release-oriented and user-oriented data. In general, though, I recommend that the JCR be treated as a release domain, since the vast majority of the data it contains comes from staging or authoring environments. Personalization rules and policy definitions are typically developed internally and staged out. WCM content is authored and can be syndicated out to multiple clusters simultaneously. Database based 2-way replication is not recommended or supported for the JCR as a means for reducing the amount of syndication required as it can cause problems with content visibility across all clusters. WCM uses a caching mechanism that relies on syndication as a cue to invalidate cache entries. Without it, users may not see updated content without the servers being restarted.

 

  • 添加评论 添加评论
  • 编辑
  • 更多操作 v
  • 隔离此条目
通知其他人
notification

发送电子邮件通知

+

隔离此条目

deleteEntry
duplicateEntry

标记为重复项

  • 上一个条目
  • 主页
  • 下一个条目
“博客条目”的订阅源 | “博客评论”的订阅源 | 此条目评论的订阅源