LinkedQL Replicate

DOCS • CLI

---

Command: linkedql replicate

Replicate schema histories in a second database.

What it does: diffs two database instances by schema histories and replicates any changes in first database in second database; typically used for migration.

Usage

For online replication, use the --online flag. (REQUIRED)

npx linkedql replicate --online

Use the --swap flag to have the databases switch roles:

npx linkedql replicate --online --swap

For offline replication, use the --offline flag. (REQUIRED)

npx linkedql replicate --offline

Concepts

Target and origin databases

• Target database: the database where changes are to be replicated; typically, your production database.
• Origin database: the database where changes have been made; typically, your development database.

Online and offline replication

• Online replication: target database replicates origin database using origin database's Linked QL client. This is applicable where origin database is reachable from target database; e.g. where both databases are online databases or where both are local databases.

  Here, you export the additional database client (i.e. the origin database's Linked QL client) from your driver.js file as origin:

  ./database/driver.js

  export default async function() {
      return // your default Linked QL client (being the *target* database)
  }
  export async function origin() {
      return // your origin Linked QL client (being the *origin* database)
  }

• Offline replication: target database replicates origin database using origin database's histories dump.

  Here, you have your origin database's histories dumped ahead of replication, typically during your application's build process:

  ./package.json

  {
      "scripts": {
          "build": "linkedql dump-histories && other things"
      }
  }

Replication

The actual replication process via the linkedql replicate command, typically done as part of your application's deployment process:

./package.json

{
    "scripts": {
        "deploy": "linkedql replicate --online && other things"
    }
}

Conflicts

A situation caused when target database is modified outside of a replication process and thus goes out of sync with origin database. Currently Linked QL does not implement any conflict resolution mechanism; conflicts are thrown and the replication process is aborted.

Conflicts happen when target database is directly modified with a DDL operation: CREATE, ALTER, DROP, RENAME. But it is OK to directly rollback or rollforward existing savepoints in a target database. Those savepoints are realigned with corresponding origin savepoints during replication. (Well, then, that comes as a light form of conflict resolution.)

You can configure Linked DB to recognise your master database and thus disallow direct modifications on the database. Simply set the Linked DB's config.database_role config to master:

Direct DLL operations on master database, outside of a replication process, will now result in an error.