Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replication Server 6.2 Content Conversion #1083

Closed
wants to merge 5 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
The table of contents is too big for display.
Diff view
Diff view
  •  
  •  
  •  
12 changes: 12 additions & 0 deletions product_docs/docs/eprs/6.2/01_introduction/01_whats_new.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
---
title: "What’s New"
---

<div id="whats_new" class="registered_link"></div>

The following features have been added to xDB Replication Server version 6.1 to create xDB Replication Server version 6.2:

> - Registering your xDB Replication Server product with an EnterpriseDB product license key is no longer required. Thus, all components related to registering the product have been removed. The following are the removed components: 1) the Product Registration dialog box accessed from the xDB Replication Console Help menu, 2) the `license_key` parameter located in the xDB Replication Configuration file, and 3) the xDB Replication Server CLI `registerkey` command.
> - Partitioned tables created using the declarative partitioning feature of PostgreSQL and Advanced Server version 10 and later can now be replicated in a log-based single-master or multi-master replication system. For more information, see [Replicating Postgres Partitioned Tables](../07_common_operations/10_replicating_postgres_partitioned_tables/#replicating_postgres_partitioned_tables).
> - In a single-master replication system, removal of a table from a publication that has one or more existing subscriptions is now permitted as long as the table to be removed is not the parent referenced in a foreign key constraint from a child table that is not being removed as well. Previously, no tables from a publication in a single-master replication system could be removed if there are existing subscriptions. For more information, see [Removing Tables from a Publication](../07_common_operations/06_managing_publication/03_updating_pub/#remove_tables_from_pub).
> - Versions 11 and 12 of PostgreSQL and Advanced Server are now supported.
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
---
title: "Conventions Used in this Guide"
---

<div id="conventions_used" class="registered_link"></div>

The following is a list of other conventions used throughout this document.

- This guide applies to both Linux and Windows systems. Directory paths are presented in the Linux format with forward slashes. When working on Windows systems, start the directory path with the drive letter followed by a colon and substitute back slashes for forward slashes.
- Much of the information in this document applies interchangeably to PostgreSQL and EDB Postgres Advanced Server. The term Postgres is used to generically refer to both PostgreSQL and Advanced Server. When a distinction needs to be made between these two database systems, the specific names, PostgreSQL or Advanced Server are used.
- The installation directory path of the PostgreSQL or Advanced Server products is referred to as `POSTGRES_INSTALL_HOME`. For PostgreSQL Linux installations, this defaults to `/opt/PostgreSQL/x.x` for version `10` and earlier. For later versions, use the PostgreSQL community packages. For PostgreSQL Windows installations, this defaults to `C:\Program Files\PostgreSQL\x.x`. For Advanced Server Linux installations accomplished using the interactive installer for version 10 and earlier, this defaults to `/opt/PostgresPlus/x.xAS or /opt/edb/asx.x`. For Advanced Server Linux installations accomplished using an RPM package, this defaults to `/usr/ppas-x.x or /usr/edb/asx.x`. For Advanced Server Windows installations, this defaults to `C:\Program Files\PostgresPlus\x.xAS` or `C:\Program Files\edb\asx.x`. The product version number is represented by `x.x` or by `xx` for version `10` and later.
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
---
title: "Certified and Supported Product Versions"
---

The following database product versions may be used with xDB Replication Server:

- PostgreSQL versions 9.6, 10, 11, 12, and 13
- Advanced Server versions 9.6, 10, 11, 12, and 13
- Oracle 10g Release 2 version 10.2.0.1.0 has been explicitly certified. Newer minor versions in the 10.2 line are supported as well.
- Oracle 11g Release 2 version 11.2.0.2.0 has been explicitly certified. Newer minor versions in the 11.2 line are supported as well.
- Oracle 12c version 12.1.0.2.0 has been explicitly certified. Newer minor versions in the 12.1 line are supported as well.
- SQL Server 2008 version 10.50.1617.0 has been explicitly certified. Newer minor versions in the 10.50 line are supported as well.
- SQL Server 2012 version 11.0.6020.0 has been explicitly certified. Newer minor versions in the 11.0 line are supported as well.
- SQL Server 2014 version 12.0.5000.0 has been explicitly certified. Newer minor versions in the 12.0 line are supported as well.

Contact your EnterpriseDB Account Manager or [[email protected]](mailto:[email protected]) if you require support for other platforms.

**A Note Regarding Oracle RAC and Oracle Exadata**

xDB Replication server has not been tested and is not officially supported for use with Oracle RAC and Exadata, but may work when connected to a single persistent node. To determine its ability to work with RAC or Exadata, please contact your EDB representative.
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
---
title: "Supported JDK Versions"
---

The xDB Replication Server is certified to work with the following Java platforms:

| **Operating Systems** | **JDK Versions** |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `CentOS 7 and 8`<br /> | - Red Hat OpenJDK 7 <br /> - Red Hat OpenJDK 8 <br /> |
| `PPCLE RHEL7` | <br /><br /><br />Red Hat OpenJDK 8<br /><br /> |
| `RHEL 7`<br /> | - Red Hat OpenJDK 7 <br /> - Red Hat OpenJDK 8 <br /> - Oracle JDK 7 <br /> - Oracle JDK 8 <br /> |
| `Windows 2012 R2, 2016, and 2019`<br /> | - Red Hat OpenJDK 7 <br /> - Red Hat OpenJDK 8 <br /> |
| `Debian 10` | <br /><br /><br />Red Hat OpenJDK 11<br /><br /> |

**Certified Java Platforms**

!!! Note
EDB Postgres Replication Server 6.2 is no longer supported on `CentOS/RHEL/OEL 6.x` platforms. It is strongly recommended that EDB products running on these platforms should be migrated to a supported platform.
53 changes: 53 additions & 0 deletions product_docs/docs/eprs/6.2/01_introduction/index.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
---
title: "Introduction"
---

<div id="introduction" class="registered_link"></div>

This document describes the installation, configuration, architecture, and operation of the <span class="title-ref">EDB xDB Replication Server</span>. EDB xDB (cross database) Replication Server (referred to hereafter as <span class="title-ref">xDB Replication Server</span>) is an asynchronous replication system available for PostgreSQL and for EDB Postgres Advanced Server. The latter will be referred to simply as <span class="title-ref">Advanced Server</span>.

xDB Replication Server can be used to implement replication systems based on either of two different replication models – single-master (primary-to-secondary) replication or multi-master replication.

Regardless of the chosen replication model, xDB Replication Server is extremely flexible and easy to use.

For single-master replication, PostgreSQL, Advanced Server, Oracle, and Microsoft SQL Server are supported in an assortment of configurations (including cascading replication) allowing organizations to utilize it in multiple use cases with a variety of benefits.

The following are some combinations of cross database replications that xDB Replication Server supports for single-master replication:

- From Oracle to PostgreSQL
- From Oracle to Advanced Server
- From SQL Server to PostgreSQL
- From SQL Server to Advanced Server
- From Advanced Server to Oracle
- From PostgreSQL to SQL Server
- From Advanced Server to SQL Server
- Between PostgreSQL and Advanced Server
- From PostgreSQL to Oracle (WAL mode)
- From PostgreSQL to Oracle (trigger mode)

!!! Note
Oracle Real Application Clusters (RAC) and Oracle Exadata are not supported by xDB Replication Server. These Oracle products have not been evaluated nor certified with xDB Replication Server.

For multi-master replication, xDB Replication Server supports the following configurations:

- Between PostgreSQL database servers
- Between PostgreSQL database servers and Advanced Servers in PostgreSQL compatible mode

The reader is assumed to have basic SQL knowledge and basic Oracle, SQL Server, or PostgreSQL database administration skills (whichever are applicable) so that databases, users, schemas, and tables can be created and database object privileges assigned.

- The remainder of Chapter 1 describes conventions used throughout this user’s guide along with suggested sections to read based upon your purpose for using this guide.
- Chapter [Overview](../02_overview/#overview) provides an overview of xDB Replication Server including basic replication concepts and definitions, architecture and components of xDB Replication Server, and design guidelines for setting up a replication system.
- Chapter [Installation and Uninstallation](../03_installation/#installation) gives instructions for installing and uninstalling xDB Replication Server.
- Chapter [Introduction to the xDB Replication Console](../04_intro_xdb_console/#intro_xdb_console) provides an overview of the xDB Replication Console, the graphical user interface for using xDB Replication Server.
- Chapter [Single-Master Replication Operation](../05_smr_operation/#smr_operation) gives instructions for the configuration and operation of xDB Replication Server for single-master replication systems.
- Chapter [Multi-Master Replication Operation](../06_mmr_operation/#mmr_operation) gives instructions for the configuration and operation of xDB Replication Server for multi-master replication systems.
- Chapter [Common Operations](../07_common_operations/#common_operations) describes operations that are common to both single-master and multi-master replication systems.
- Chapter [xDB Replication Server Command Line Interface](../08_xdb_cli/#xdb_cli) describes the xDB Replication Server Command Line Interface, an alternative to the graphical user interface for xDB Replication Server configuration and management.
- Chapter [Data Validator](../09_data_validator/#data_validator) gives instructions for configuration and usage of the Data Validator.
- Chapter [Appendix](../10_appendix/#appendix) is an appendix containing troubleshooting tips, a list of error messages, their causes and resolutions, permitted combinations of database servers in a replication system, xDB Replication Server product upgrade procedures, and other miscellaneous technical information.

<div class="toctree" maxdepth="3">

whats_new conventions_used certified_supported_versions supported_jdk_versions

</div>
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
---
title: "Offloading Reporting and Business Intelligence Queries"
---

<div id="offloading_reporting_and_bi_queries" class="registered_link"></div>

In this use case, users take all or just a subset of data from a production OLTP system and replicate it to another database whose sole purpose is to support reporting queries. This can have multiple benefits:

1. Reporting loads are removed from the OLTP system, improving transaction processing performance.
2. Query performance improves as well without being subordinated to transactions on the system.
3. In Oracle installations, the reporting server duties can be handled by a product like Advanced Server reducing licensing costs for a reporting server.
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
---
title: "Using Warm Standby Servers"
---

<div id="using_warm_standby" class="registered_link"></div>

When many organizations wish to improve the availability of their data, a cost effective solution is often the use of warm standby servers. These are database servers kept up to date with the online system through replication that can be brought online quickly in the event of a failure in the production system. Warm standby servers can also be used for regular maintenance by gracefully switching over to the standby server so that the production server can be brought offline for regular maintenance.
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
---
title: "Testing Systems in Parallel"
---

<div id="testing_systems_in_parallel" class="registered_link"></div>

Often times, upgrading or moving to a new database system requires that the old and new systems be up and running in parallel to allow for testing and comparing results in real time. Replication can be employed in this use case and is frequently used in development and testing environments.
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
---
title: "Migrating Data"
---

<div id="migrating_data" class="registered_link"></div>

Similar to running in parallel, is the situation where data may be migrated from one system to another in a sort of *seeding* operation. Replication can be very effective in this situation by quickly copying data.

Some reasons to consider multi-master replication include the following:
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
---
title: "Write Availability"
---

<div id="write_availability" class="registered_link"></div>

In single-master replication, only the primary database is available for writes. The secondary databases are read-only for applications. If the replicated target databases must be available for write access as well, multi-master replication can be employed for the same use cases as outlined for single-master replication, but with the additional advantage of write access to the secondary.
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
---
title: "Write Scalability"
---

<div id="write_scalability" class="registered_link"></div>

In write-intensive applications, multi-master replication allows you to utilize multiple database servers on separate hosts to process write transactions independently of each other on their own primary databases. Changes can then be reconciled across primary databases according to your chosen schedule.
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
---
title: "Localized Data Access"
---

<div id="localized_data_access" class="registered_link"></div>

In a geographically dispersed application, local access to the database can be provided to regions of clients. Having the database servers physically close to clients can reduce latency with the database. Multi-master replication allows you to employ a WAN connected network of primary databases that can be geographically close to groups of clients, yet maintain data consistency across primary databases.
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
---
title: "Why Use Replication"
---

<div id="why_replication" class="registered_link"></div>

Replication of data can be employed in a variety of use cases in organizations where it is important to use the same data in multiple settings. This allows users to work with ‘real’ data that will yield ‘real’ results that are reliable in more than one setting. Support of both single-master and multi-master replication gives xDB Replication Server a broad range of supported use cases.

Some of the more popular uses of single-master replication include the following:

<div class="toctree" maxdepth="4">

offloading_reporting_and_bi_queries using_warm_standby testing_systems_in_parallel migrating_data write_availability write_scalability localized_data_access

</div>
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
---
title: "Comparison of Single-Master and Multi-Master Replication"
---

<div id="smr_mmr_comparison" class="registered_link"></div>

In write-intensive applications, multi-master replication allows you to utilize multiple database servers on separate hosts to process write transactions independently of each other on their own primary databases. Changes can then be reconciled across primary databases according to your chosen schedule.

There are two models of replication systems supported by xDB Replication Server:

- **Single-Master Replication (SMR).** Changes (inserts, updates, and deletions) to table rows are allowed to occur in a designated primary database. These changes are replicated to tables in one or more secondary databases. The replicated tables in the secondary databases are not permitted to accept any changes except from its designated primary database. (This is also known as primary-to-secondary replication.)
- **Multi-Master Replication (MMR).** Two or more databases are designated in which tables with the same table definitions and initial row sets are created. Changes (inserts, updates, and deletions) to table rows are allowed to occur in any database. Changes to table rows in any given database are replicated to their counterpart tables in every other database.

For a single-master replication system, a variety of configurations are supported including:

- Replication between PostgreSQL and Advanced Server databases (between products in either direction)
- Replication in either direction between Oracle and Advanced Server
- Replication in either direction between SQL Server and PostgreSQL
- Replication in either direction between SQL Server and Advanced Server
- Replication in either direction between PostgreSQL and Oracle

For multi-master replication, the participating database servers in a given multi-master replication system must be of the same type:

- PostgreSQL database servers
- PostgreSQL database servers and Advanced Servers operating in PostgreSQL compatible mode
- Advanced Servers operating in PostgreSQL compatible mode
- Advanced Servers operating in Oracle compatible mode

!!! Note
A given database cannot simultaneously participate in both a single-master replication system and a multi-master replication system.
Loading