You can transfer data from any supported database type to any supported database type. You can choose to transfer a single domain or multiple domains. To maximize availability, data may be distributed across multiple databases and shared between multiple lines of production.
Domains are the database or schema objects that can be transferred in parts, such as Release, Community, Customization, Feekback, LikeMinds, DB2® Content Manager Runtime Edition (JCR), Place Center (placecntr), Search Center (searchcntr) and Quickr Admin (qkradmin). Separating your data allows you to share domains across multiple portals. You can also spread the different domains across different database types. For example, you can choose to leave LikeMinds data on your default database and move all other data to another database.
Data is categorized into four categories. You need to decide how the categories should be distributed into different databases.
defines the portal server setup, such as database connection, object factories, and deployment descriptors. This type of data typically is constant during the time a server node is running. Configuration data is typically kept in property files and is either protected by file system security or application server administration rights.Release data
are all portal content definitions, rules, and rights that are designed externally then brought into the portal by a staging process, such as Page Hierarchy, available Portlets and Themes, Templates, Credential Slots, Personalization Rules, and Policies. These resources are typically not modified during production and need administrative rights to do so. Administrators typically create release data on an integration server and stage it to the production system. Release data are protected by access control and contain only data, not code.Customization data
In an environment that consists of multiple lines of production, one copy of the release data exists per cluster. Administrators must make sure that the content of the release databases is consistent across the different lines, in particular after modification of the release data on the production system.
is associated with a particular user only and cannot be shared across users or user groups. Typical examples are PortletData or Implicitly Derived Pages. Because this data is scoped to a single user only, access control protection is simplified. Community data
In an environment that consists of multiple lines of production, customization data is kept in a database that is shared across the lines of production. Therefore the data is automatically in synchronization across the lines of production.
are all resources that are typically modified during production, such as shared documents or application resources. Typically users and groups are allowed to modify or delete shared resources. Community Resources are protected by access control. Because documents are a preferred class of shared resources supported with its own storage mechanism, this type of resource has two subcategories:
all the documents using this storage mechanism.Application data
all the other shared application data, which are not documents.
In an environment that consists of multiple lines of production, community data is kept in a database that is shared across the lines of production. Therefore the data is automatically in synchronization across the lines of production.
Separation of the portal data lets you store each category in its own set of database tables or the file system. The set of databases tables for one of these resources are called database domains. These database domains can now be moved into different databases, which can even be shared with other portal installations.
The list of supported database domains are listed in the following table.
Table 1. Supported database domains
|Database domain||Sharable||Storage method|
The separation of the domains can be used to support production environments, where the production nodes are split into separate clusters. They can run independently, but share the same Community and Customization database domains. Each of these clusters is called a line of production.
JCR domains cannot be shared between different Web Content Management clusters or servers. Each distinct cluster or server in your Web Content Management system must use a separate JCR domain. For example:
Table 2. Example of JCR domains
|Development Server||Authoring Cluster||Staging Server||Delivery Cluster|
|JCR Domain 1||JCR Domain 2||JCR Domain 3||JCR Domain 4|
For maintenance and staging purposes you can take a single line of production out of service while another line is still serving requests with the old data. After the first production line is updated and back in service again, the second line is updated using the same approach. Updates of data in the shared domain are critical because they influence the other production line.
The capacity of the entire environment should be greater than the intended use so that individual servers can be taken out of production without affecting application availability. To ensure that all of the system resources are available for the portal, production systems should be dedicated to the portal and should not run any other server software that is not related to the portal.
Parent topic: Database considerations: qp85