Table of Contents Previous Next


2 Overview : 2.3 xDB Replication Server Components and Architecture

This section describes the components and architecture of xDB Replication Server. Section 2.3.1 describes the executable programs, files, and databases that comprise xDB Replication Server. Section 2.3.2 defines the logical components of a replication system and how they correspond to the programs and databases. Section 2.3.3 illustrates some examples of replication systems.
Publication server. The program that configures the publication database and master nodes for replication and performs replication.
Subscription server. The program that configures the subscription database for replication and initiates replication. The subscription server is used only in single-master replication systems.
xDB Replication Configuration file. Text file containing connection and authentication information used by the publication server and subscription server upon startup to connect to a publication database designated as the controller database. Also used to authenticate registration of the publication server and subscription server from the user interface when creating a replication system.
xDB Startup Configuration file. Text file containing installation and configuration information used for the Java Runtime Environment when the publication server and subscription server are started.
Note: See Section 2.3.1.11 for information on the control schema.
Note: The subscription server is required only for single-master replication systems. The subscription server does not need to be running, nor even installed if only multi-master replication systems are in use.
Parameters admin_user and admin_password are determined during the xDB Replication Server installation process. See Chapter 3 for how the content of these parameters are determined.
Parameters database, user, password, port, host, and type are set with the connection and authentication information of the first publication database definition you create with the xDB Replication Console or xDB Replication Server CLI. This database is designated as the controller database. See Section 2.3.1.12 for information on the controller database. See Section 5.2.2 for creating a publication database definition for a single-master replication system. See Section 6.2.2 for creating the publication database definition for a multi-master replication system.
Note: The passwords for the admin user name and the controller database user name are encrypted. Should you change either of these passwords, you must modify the corresponding password parameters in the xDB Replication Configuration file to contain the encrypted form of the new password. See Section 10.4.2 for directions on how to generate the encrypted form of a password.
See Section 3.5 for the file system location of the xDB Replication Configuration file.
In -Xmsnnnm nnn specifies the minimum Java heap size in megabytes. In -Xmxnnnm nnn specifies the maximum Java heap size in megabytes
The JAVA_EXECUTABLE_PATH parameter specifies the location of the Java runtime program as identified by the xDB Replication Server installer during the installation process. The setting of this parameter may be subsequently changed to a different JRE installation if so desired.
The JAVA_MINIMUM_VERSION parameter specifies the earliest version of the Java Runtime Environment that can be used with xDB Replication Server. This setting must not be changed.
The JAVA_BITNESS_REQUIRED parameter must not be altered. If the installed value is modified, or if it does not match the bitness of the Java virtual machine as identified by JAVA_EXECUTABLE_PATH, a number of errors may occur, which include failure of the publication and subscription servers to start and registration failure of the xDB Replication Server product.
See Section 5.1.1 for information on setting the JAVA_HEAP_SIZE parameter.
See Section 5.1.6.1 for information on the PUBPORT and SUBPORT parameters.
See Section 3.5 for the file system location of the xDB Startup Configuration file.
See Chapter 4 for information on the user interface of the xDB Replication Console.
Chapter 8 provides directions for using xDB Replication Server CLI.
Note: The subscription database applies only to single-master replication systems.
2.3.1.9 Master Node
The control schema is a conceptual term referring to the collection of metadata database objects that define the logical and physical structure of, and enable the operation and maintenance of xDB Replication Server single-master and multi-master replication systems.
These metadata database objects, referred to as control schema objects consist of tables, sequences, functions, procedures, triggers, packages, etc.
Note: For log-based single-master and multi-master replication systems, changes are extracted from the database server WAL files instead of being stored in control schema objects. See Section 2.2.10 for information on the log-based method.
The slave (subscription) database of single-master replication systems contains one, single table as its metadata database object. The term, subscription metadata object, is specifically used to refer to this database object in the subscription database. The general terms, control schema and control schema objects refer to the database objects in the publication databases.
Note: If the controller database is an Oracle or a SQL Server publication database, then a second Oracle or SQL Server publication database cannot be added to create a second single-master replication system. In order for xDB Replication Server to run more than one single-master replication systems consisting of Oracle or SQL Server publication databases, a Postgres publication database must be designated as the controller database.
Each of these steps creates a logical component that is represented by a node in the replication tree of the xDB Replication Console. See Chapter 4 for a description of the xDB Replication Console. A brief description of these components is given in the following sections.
Section 5.2.1 gives directions for registering a publication server for a single-master replication system. See Section 6.2.1 for a multi-master replication system.
Subordinate to a registered publication server, two nodes representing the replication system type appear. One is identified by the label SMR for single-master replication and the other has the label MMR for multi-master replication.
Note: Currently, there can only be one multi-master replication system per publication server.
Section 5.2.2 discusses creating a publication database definition for a single-master replication system. See sections 6.2.2 and 6.3 for a multi-master replication system.
2.3.2.4 Publication
Section 5.2.3 discusses creating a publication for a single-master replication system. See Section 6.2.3 for a multi-master replication system.
Note: The subscription server applies only to single-master replication systems. You do not register a subscription server when creating a multi-master replication system.
Section 5.3.1 gives directions for registering a subscription server.
Note: The subscription database definition applies only to single-master replication systems. You do not create a subscription database definition when creating a multi-master replication system.
Section 5.3.2 discusses creating a subscription database definition.
2.3.2.7 Subscription
Note: The subscription applies only to single-master replication systems. You do not create a subscription when creating a multi-master replication system.
Section 5.3.3 discusses creating a subscription.
A publication database definition is created subordinate to the SMR type node under the publication server. The Oracle database user name pubuser is specified in the definition along with the database network location and database identifier. When you create a user named pubuser in Oracle, a schema named pubuser is automatically created by Oracle at the same time. The publication server creates the control schema objects in the pubuser control schema for the replication system’s metadata when you create the publication database definition.
A publication named pub is created subordinate to the publication database definition. The publication consists of table A in schema S1 and tables B and C in schema S2.
A subscription database definition is created subordinate to the subscription server. The Postgres database user name subuser is specified in the definition along with the database network location and database identifier.
A subscription named sub is created subordinate to the subscription database definition. When the subscription is created, the subscription server creates schemas named S1 and S2 in the subscription database. The table definitions for tables A, B, and C are also created at this time. When replication occurs, the publication server populates these tables with rows from the publication.
See Chapter 4 for an introduction to the xDB Replication Console.
A publication database definition is created subordinate to the SMR type node under the publication server. The SQL Server login pubuser is specified in the definition along with the database network location and database identifier. The schema pubuser was created during the publication database preparation step as described in Section 5.1.4.2. The pubuser schema along with the control schema consisting of three physical schemas _edb_replicator_pub, _edb_replicator_sub, and _edb_scheduler are populated with the control schema objects for the replication system’s metadata when you create the publication database definition.
A publication named pub is created subordinate to the publication database definition. The publication consists of table A in schema S1 and tables B and C in schema S2.
A subscription database definition is created subordinate to the subscription server. The Postgres database user name subuser is specified in the definition along with the database network location and database identifier.
A subscription named sub is created subordinate to the subscription database definition. When the subscription is created, the subscription server creates schemas named S1 and S2 in the subscription database. The table definitions for tables A, B, and C are also created at this time. When replication occurs, the publication server populates these tables with rows from the publication.
See Chapter 4 for an introduction to the xDB Replication Console.
A publication database definition is created subordinate to the SMR type node under the publication server. The Postgres database user name pubuser is specified in the definition along with the database network location and database identifier. The publication server creates the control schema consisting of three physical schemas _edb_replicator_pub, _edb_replicator_sub, and _edb_scheduler and populates them with the control schema objects for the replication system’s metadata when you create the publication database definition.
A publication named pub is created subordinate to the publication database definition. The publication consists of table A in schema S1 and tables B and C in schema S2.
A subscription database definition is created subordinate to the subscription server. The Oracle database user name subuser is specified in the definition along with the database network location and database identifier.
A subscription named sub is created subordinate to the subscription database definition. When you create a user named subuser in Oracle, a schema named subuser is automatically created by Oracle at the same time. The table definitions for tables A, B, and C are created in schema subuser when you create subscription sub. When replication occurs, the publication server populates these tables with rows from the publication.
See Chapter 4 for an introduction to the xDB Replication Console.
A publication database definition is created subordinate to the SMR type node under the publication server. The Postgres database user name pubuser is specified in the definition along with the database network location and database identifier. The publication server creates the control schema consisting of three physical schemas _edb_replicator_pub, _edb_replicator_sub, and _edb_scheduler and populates them with the control schema objects for the replication system’s metadata when you create the publication database definition.
A publication named pub is created subordinate to the publication database definition. The publication consists of table A in schema S1 and tables B and C in schema S2.
A subscription database definition is created subordinate to the subscription server. The SQL Server login subuser is specified in the definition along with the database network location and database identifier.
A subscription named sub is created subordinate to the subscription database definition. When the subscription is created, the subscription server creates schemas named S1 and S2 in the subscription database. The table definitions for tables A, B, and C are also created at this time. When replication occurs, the publication server populates these tables with rows from the publication.
See Chapter 4 for an introduction to the xDB Replication Console.
A publication database definition is created subordinate to the MMR type node under the publication server. This first publication database definition identifies the master definition node. The Postgres database user name mmruser_a is specified in the definition along with the database network location and database identifier. The publication server creates the control schema consisting of three physical schemas _edb_replicator_pub, _edb_replicator_sub, and _edb_scheduler and populates them with the control schema objects for the replication system’s metadata when you create the publication database definition.
A publication named pub is created subordinate to the publication database definition. The publication consists of table A in schema S1 and tables B and C in schema S2.
When you add the second master node, you can choose to have the publication server create schemas S1 and S2 and the table definitions for A, B, and C for you, or you could have manually created the schemas and table definitions beforehand. The publication server creates the control schema consisting of three physical schemas _edb_replicator_pub, _edb_replicator_sub, and _edb_scheduler under which it creates the control schema objects to store the master node’s metadata. When defining the master node, you can choose to have the publication server populate these tables with rows from the publication at this time, or you can defer table loading to a later point in time.
See Chapter 4 for an introduction to the xDB Replication Console.

2 Overview : 2.3 xDB Replication Server Components and Architecture

Table of Contents Previous Next