Merge pull request #2522 from EnterpriseDB/release/2022-04-05

Release: 2022-04-05

product_docs/docs/eprs/6.2/02_overview/02_replication_concepts_and_definitions/04_mmr_replication.mdx

@@ -10,7 +10,7 @@ The following definitions are used when referring to multi-master replication sy
 
 A primary node is a database participating in a multi-master replication system.
 
-The database (primary node) in which the publication is initially defined is specially designated as the `primary definition node (PDN)`. There can be only one primary definition node at any given time, however, it is possible to change which primary node is the primary definition node. When it is important to make a distinction between the primary definition node and all other primary nodes that are not the primary definition node, the latter are referred to as `non-PDN nodes`.
+The database (primary node) in which the publication is initially defined is specially designated as the `primary definition node (MDN)`. There can be only one primary definition node at any given time, however, it is possible to change which primary node is the primary definition node. When it is important to make a distinction between the primary definition node and all other primary nodes that are not the primary definition node, the latter are referred to as `non-MDN nodes`.
 
 The primary definition node has the following significance:
 

product_docs/docs/eprs/6.2/02_overview/02_replication_concepts_and_definitions/13_table_filters.mdx

@@ -95,7 +95,7 @@ The `REPLICA IDENTITY FULL` setting is required on tables in the following datab
 
 -   In a single-master replication system, table filters are defined in the primary database. Thus, the publication tables in the primary database requiring filter definitions must be altered to a `REPLICA IDENTITY FULL` setting, but only if the publication is not a snapshot-only publication. See [Snapshot-Only Publications](07_snapshot_only_publications/#snapshot_only_publications) for information on snapshot-only publications.
 -   In a multi-master replication system, table filters are defined in the primary definition node. Thus, publication tables in the primary definition node requiring filter definitions must be altered to a `REPLICA IDENTITY FULL` setting.
--   In a multi-master replication system, non-PDN nodes should not have their tables’ `REPLICA IDENTITY` option set to `FULL` unless transactions are expected to be targeted on those non-PDN nodes, and the transactions are to be filtered when they are replicated to the other primary nodes.
+-   In a multi-master replication system, non-MDN nodes should not have their tables’ `REPLICA IDENTITY` option set to `FULL` unless transactions are expected to be targeted on those non-MDN nodes, and the transactions are to be filtered when they are replicated to the other primary nodes.
 
 The `REPLICA IDENTITY FULL` setting on a source table ensures that certain types of transactions on the source table result in the proper updates to the target tables on which filters have been enabled.
 

product_docs/docs/eprs/6.2/02_overview/03_replication_server_components_and_architecture/01_physical_components.mdx

@@ -48,7 +48,7 @@ The following sections describe each component in more detail.
 
 The publication server creates and manages the metadata for publications. When a publication is created, the publication server creates database objects in the control schema of the publication database to record metadata about the publication.
 
-Whenever a primary node is added to a multi-master replication system, the publication server creates database objects in the control schema of the primary node for recording metadata. For non-PDN nodes, the publication server also calls EnterpriseDB’s Migration Toolkit to create the publication table definitions if so chosen at primary node creation time.
+Whenever a primary node is added to a multi-master replication system, the publication server creates database objects in the control schema of the primary node for recording metadata. For non-MDN nodes, the publication server also calls EnterpriseDB’s Migration Toolkit to create the publication table definitions if so chosen at primary node creation time.
 
 !!! Note
     See [Control Schema and Control Schema Objects](#control_schema_and_objects) for information on the control schema.

product_docs/docs/eprs/6.2/02_overview/04_design_replication_system/02_design_considerations.mdx

@@ -29,7 +29,7 @@ Keep the following points in mind when designing a replication system:
     - Repeat the same process for the publications. 
     - After all replication system logical components have been removed (except for possibly the publication server and subscription server) you can drop any of the physical database objects in Oracle, SQL Server, or Postgres. Do not drop the control schema objects manually, for example by using an SQL command line utility. Doing so may cause the xDB Replication Console and xDB Replication Server CLI to become inoperable. (See [Deleting the Control Schema and Control Schema Objects](../../10_appendix/03_resolving_problems/04_troubleshooting_areas/#del_control_schema_and%20objects) if this problem occurs.) Deleting the replication system logical components using the xDB Replication Console or xDB Replication Server CLI automatically drops the control schema objects from the physical database.
 -   The order of removal of a multi-master replication system is as follows: 
-    - Remove the replication system logical components using the xDB Replication Console or xDB Replication Server CLI starting with the publication database definitions of the non-PDN nodes. 
+    - Remove the replication system logical components using the xDB Replication Console or xDB Replication Server CLI starting with the publication database definitions of the non-MDN nodes. 
     - Remove the publication from under the primary definition node. 
     - Remove the publication database definition of the primary definition node. 
     - After all replication system logical components have been removed (except for possibly the publication server) you can drop any of the physical database objects in Postgres. Do not drop the control schema objects manually, for example by using an SQL command line utility. Doing so may cause the xDB Replication Console and xDB Replication Server CLI to become inoperable.

product_docs/docs/eprs/6.2/05_smr_operation/01_prerequisites/04_preparing_pub_database.mdx

@@ -36,14 +36,17 @@ The setup instructions for using an Oracle 12c publication database or subscript
 
 **Step 1:** Create a database user name for the publication database user. The publication database user name must have a password, and it must have the ability to create a database session. The publication database user becomes the owner of the control schema objects that will be created in the publication database to track, control, and record the replication process and history.
 
-!!! Note
-    (For Oracle 12c Pluggable Database): The publication database user can be an Oracle local user or a common user. The local user exists within and has access to only a single, user-created pluggable database (PDB), which is to be used as the publication database. Common user names typically begin with `C##` or `c##` and can access multiple pluggable databases.
+!!! Note Notes
+    - (For Oracle 12c Pluggable Database): The publication database user can be an Oracle local user or a common user. The local user exists within and has access to only a single, user-created pluggable database (PDB), which is to be used as the publication database. Common user names typically begin with `C##` or `c##` and can access multiple pluggable databases.
 
-!!! Note
-    (For Oracle 12c Pluggable Database): Creation and granting of privileges for a local user must be done while connected to the pluggable database to be used as the publication database. Creation of a common user must be done within the Oracle 12c root container `CDB$ROOT`. Granting of privileges to the common user must be done while connected to the pluggable database to be used as the publication database.
+    - (For Oracle 12c Pluggable Database): Creation and granting of privileges for a local user must be done while connected to the pluggable database to be used as the publication database. Creation of a common user must be done within the Oracle 12c root container `CDB$ROOT`. Granting of privileges to the common user must be done while connected to the pluggable database to be used as the publication database.
 
-!!! Note
-    (For Oracle 12c Non-Container Database): Creation and granting of privileges to the publication database user are performed in the same manner as for Oracle versions prior to 12c.
+    - (For Oracle 12c Non-Container Database): Creation and granting of privileges to the publication database user are performed in the same manner as for Oracle versions prior to 12c.
+
+    - If you enable flashback functionality for the Oracle published table, you must also give the publication database user flashback privileges for the table.  
+      ```
+      GRANT flashback ON schema_name.table_name to pubuser;
+      ```
 
 When creating the publication database definition, the publication database user name is entered in the Publication Service – Add Database dialog box (see [Adding a Publication Database](../02_creating_publication/02_adding_pub_database/#adding_pub_database)).
 

product_docs/docs/eprs/6.2/06_mmr_operation/02_creating_publication_mmr.mdx

@@ -69,7 +69,7 @@ When the publication database definition is successfully saved, a Publication Da
 
 **Figure 6-4: Replication tree after adding the primary definition node**
 
-The label `PDN` appears at the end of the node in the replication tree and in addition, the `PDN` field is set to Yes in the Property window to indicate this is the primary definition node.
+The label `MDN` appears at the end of the node in the replication tree and in addition, the `MDN` field is set to Yes in the Property window to indicate this is the primary definition node.
 
 <div id="add_pub_mmr" class="registered_link"></div>
 

product_docs/docs/eprs/6.2/06_mmr_operation/03_creating_primary_nodes.mdx

@@ -87,7 +87,7 @@ When the publication database definition is successfully saved, a Publication Da
 
 **Figure 6-17: Replication tree after adding an additional primary node**
 
-Unlike the primary definition node, the label PDN does not appear at the end of the node in the replication tree. The PDN field is set to No in the Property window to indicate this is not the primary definition node.
+Unlike the primary definition node, the label MDN does not appear at the end of the node in the replication tree. The MDN field is set to No in the Property window to indicate this is not the primary definition node.
 
 In addition, a Publication node appears under the newly added primary node. This Publication node represents the publication in the primary definition node, which is replicated to the primary node.
 

product_docs/docs/eprs/6.2/06_mmr_operation/10_switching_pdn.mdx

@@ -10,36 +10,18 @@ After the multi-master replication system is created, you can switch the role of
 
 **Step 2:** Select the Publication Database node corresponding to the primary node that you wish to set as the primary definition node.
 
-![Selecting the primary node to set as the master definition node](../images/image178.png)
 
-**Figure 6-69: Selecting the primary node to set as the primary definition node**
+**Step 3:** Click the secondary mouse button on the Publication Database node and choose `Set as MDN`.
 
-**Step 3:** Click the secondary mouse button on the Publication Database node and choose `Set as PDN`.
 
-![Setting the master definition node](../images/image179.png)
+**Step 4:** In the `Set as MDN` confirmation box, click the `Yes` button.
 
-**Figure 6-70: Setting the primary definition node**
-
-**Step 4:** In the `Set as PDN` confirmation box, click the `Yes` button.
-
-![Set as PDN confirmation](../images/image180.png)
-
-**Figure 6-71: Set as PDN confirmation**
 
 **Step 5:** The selected master node is now the master definition node.
 
-![Database promoted to master definition node](../images/image181.png)
-
-**Figure 6-72: Database promoted to primary definition node**
-
-**Step 6:** The value `Yes` in the PDN field of the Property window indicates this database is the primary definition node.
-
-!!! Note
-    The new primary definition node is moved to the top of the replication tree in the xDB Replication Console.
 
-![Master definition node (PDN) indicated by ‘Yes’ in the Property window](../images/image182.png)
+**Step 6:** The value `Yes` in the MDN field of the Property window indicates this database is the primary definition node.
 
-**Figure 6-73: Primary definition node (PDN) indicated by ‘Yes’ in the Property window**
+The new primary definition node is moved to the top of the replication tree in the xDB Replication Console.
 
-!!! Note
-    You should now perform a synchronization replication to ensure that the new primary definition node is synchronized with the other primary nodes. See [Performing Synchronization Replication](05_on_demand_replication_mmr/#perform_synchronization_replication_mmr) for directions on performing a synchronization replication.
+You should now perform a synchronization replication to ensure that the new primary definition node is synchronized with the other primary nodes. See [Performing Synchronization Replication](05_on_demand_replication_mmr/#perform_synchronization_replication_mmr) for directions on performing a synchronization replication.

product_docs/docs/eprs/6.2/07_common_operations/06_managing_publication/06_removing_pub.mdx

@@ -6,7 +6,7 @@ title: "Removing a Publication"
 
 In a single-master replication system, a publication can be removed before its associated subscriptions are removed. See [Removing a Subscription](../../05_smr_operation/05_managing_subscription/05_removing_subscription/#removing_subscription) for directions to remove a subscription.
 
-In a multi-master replication system, the publication is removed from under the Publication Database node representing the primary definition node. Before a publication can be removed, all non-PDN nodes must be removed. See [Removing a Publication Database](07_removing_pub_database/#removing_pub_database) for directions to remove a publication database definition of a primary node.
+In a multi-master replication system, the publication is removed from under the Publication Database node representing the primary definition node. Before a publication can be removed, all non-MDN nodes must be removed. See [Removing a Publication Database](07_removing_pub_database/#removing_pub_database) for directions to remove a publication database definition of a primary node.
 
 Removing a publication does not delete the publication tables in the publication database. It removes the identity and association of these tables to xDB Replication Server so the tables remain in the database until the DBA deletes them with the `DROP TABLE SQL` statement.
 

product_docs/docs/eprs/6.2/07_common_operations/06_managing_publication/07_removing_pub_database.mdx

@@ -20,7 +20,7 @@ Removing the Publication Database node representing the primary definition node
 
 -   If the multi-master replication system is the only xDB replication system (that is, there are no single-master replication systems), then switch the controller database to the primary definition node if the designated controller database is not currently the same database as the primary definition node.
 -   If there are one or more single-master replication systems in addition to the multi-master replication system, switch the controller database to a Postgres publication database of a single-master replication system. If none of the single-master publication databases is of type Postgres, and there are more than one Oracle or SQL Server publication databases, then you must create a Postgres publication database for a single-master replication system just for the purpose of designating it as the controller database.
--   All Publication Database nodes representing non-PDN nodes must be removed. Repeat the process described in this section for each such primary node.
+-   All Publication Database nodes representing non-MDN nodes must be removed. Repeat the process described in this section for each such primary node.
 -   The publication under the Publication Database node representing the primary definition node must be removed. See [Removing a Publication](06_removing_pub/#removing_pub) for directions on removing a publication.
 -   Remove the Publication Database node representing the primary definition node using the process described in this section.
 

product_docs/docs/eprs/6.2/07_common_operations/09_offline_snapshot.mdx

@@ -4,7 +4,7 @@ title: "Loading Tables From an External Data Source (Offline Snapshot)"
 
 <div id="offline_snapshot" class="registered_link"></div>
 
-There may be circumstances when you want to initially load your target tables (subscription tables of a single-master replication system, or non-PDN nodes of a multi-master replication system) using a method other than the snapshot replication functionality of xDB Replication Server. This is referred to as using an offline snapshot.
+There may be circumstances when you want to initially load your target tables (subscription tables of a single-master replication system, or non-MDN nodes of a multi-master replication system) using a method other than the snapshot replication functionality of xDB Replication Server. This is referred to as using an offline snapshot.
 
 For example, you might initially load the tables by running the Migration Toolkit from the command line or by using a backup from an external data source. When you load the target tables using an offline snapshot, special preparations must be taken to account for the following deviations from the default target table creation and loading process:
 

product_docs/docs/eprs/6.2/07_common_operations/11_using_ssl_connections.mdx

@@ -16,8 +16,8 @@ For a single-master replication system, the following connections can be made to
 
 For a multi-master replication system, the following connections can be made to Postgres databases enabled with SSL:
 
--   Publication server connection to the primary definition node and the non-PDN nodes.
--   Migration Toolkit connection to the primary definition node and the non-PDN nodes.
+-   Publication server connection to the primary definition node and the non-MDN nodes.
+-   Migration Toolkit connection to the primary definition node and the non-MDN nodes.
 
 !!! Note
     SSL connections are not used from the xDB Replication Console or the xDB Replication Server Command Line Interface. The xDB user interfaces communicate with the publication server and subscription server, which in turn connect to the publication/subscription databases or primary nodes.
@@ -376,7 +376,7 @@ The SSL URL option informs Java to use SSL when the publication server or subscr
 The configuration steps where these options are specified are as follows:
 
 -   For using SSL connections in a single-master replication system, the URL options must be specified as shown in Section [Adding a Publication Database](../05_smr_operation/02_creating_publication/02_adding_pub_database/#adding_pub_database) for the publication database and in Section [Adding a Subscription Database](../05_smr_operation/03_creating_subscription/02_adding_subscription_database/#adding_subscription_database) for the subscription databases.
--   For using SSL connections in a multi-master replication system, the URL options must be specified as shown in Section [Adding the Primary definition node](../06_mmr_operation/02_creating_publication_mmr/#adding_pdn) for the primary definition node and in Section [Creating Additional Primary nodes](../06_mmr_operation/03_creating_primary_nodes/#creating_primary_nodes) for the non-PDN nodes.
+-   For using SSL connections in a multi-master replication system, the URL options must be specified as shown in Section [Adding the Primary definition node](../06_mmr_operation/02_creating_publication_mmr/#adding_pdn) for the primary definition node and in Section [Creating Additional Primary nodes](../06_mmr_operation/03_creating_primary_nodes/#creating_primary_nodes) for the non-MDN nodes.
 
 Earlier we created self-signed certificates for the database server by specifying the value of the CN field as the database user name (for example, postgres or enterprisedb, and so on). In this case, we use the “verify-ca” value for sslmode parameter to indicate the server certificate is validated against the CA. We do this because the hostname given in the command Add Database or Update Database could not be verified against CN value present certificate, which is the database user name.