From 383bbd9e43335e4793acd18af109115174b4cc71 Mon Sep 17 00:00:00 2001
From: David Trattnig <david.trattnig@o94.at>
Date: Thu, 1 Oct 2020 15:07:29 +0200
Subject: [PATCH] Improved wording of heading.
---
README.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/README.md b/README.md
index 659d1b7..d3c58bc 100644
--- a/README.md
+++ b/README.md
@@ -8,7 +8,7 @@
- [Single Deployment](#single-deployment)
- [Redundant Deployment](#redundant-deployment)
- [Managing Active Engine State](#managing-active-engine-state)
- - [High Availability Playlog Synchronization](#high-availability-playlog-synchronization)
+ - [Playlog Synchronization for High Availability deployment scenarios](#playlog-synchronization-for-high-availability-deployment-scenarios)
- [Active Sync](#active-sync)
- [Passive Sync](#passive-sync)
- [Getting started](#getting-started)
@@ -83,7 +83,7 @@ the active engine state to the *Sync Node*.
> In your live deployment you might not want to expose the API directly on the web. For security reasons it's highly recommended to guard it using something like NGINX,
acting as a reverse proxy to shield your API.
-#### High Availability Playlog Synchronization
+#### Playlog Synchronization for High Availability deployment scenarios
Usually when some new audio source starts playing, AURA Engine logs it to its local Engine API instance via some REST call. Now, the *Local API server* stores this information in its
local database. Next, it also performs a POST request to the *Synchronization API Server*. This *Sync Node* checks if this request is coming from the currently active engine instance.
--
GitLab