Skip to content

Commit

Permalink
RS Fuji 7.4.2 release (#3099)
Browse files Browse the repository at this point in the history
* RS: TLS 1.3 (#3021)

* Added TLS 1.3, removed TLS 1.0 & 1.1

* DOC-2445 Added TLS cipher suite screenshots & new UI instructions

* DOC-2445 TLS protocols screenshots and UI instructions

* DOC-2445 TLS 1.3 updates for rladmin & REST API references

* DOC-2445 More updates for TLS protocols and ciphers docs

* Apply suggestions from code review

Co-authored-by: mich-elle-luna <[email protected]>

* DOC-2445 Added TLS 1.3 and cipher suites to internode encryption

* DOC-2445 Feedback updates

* Feedback update - changed data plane encryption to data internode encryption

* DOC-2445 DOC-3217 Fixed screenshots for TLS protocols & ciphers

* DOC-2445 DOC-3217 Fixed edit TLS ciphers screenshot

---------

Co-authored-by: mich-elle-luna <[email protected]>

* RS: Bundle 2 Redis Stack feature sets (#3069)

* DOC-3274 Changes to support 2 Redis Stack feature sets

* DOC-3274 Feedback updates

* Update port-configurations.md (#3075)

Port 3345 is now also reserved.
Thus, changed "3333-3344" to "3333-3345"

* Update product-lifecycle.md (#3055)

Instead of deleting the note now, we can update it with the release of Fuji (7.4) @rrelledge

* DOC-3213 Deprecate /debuginfo REST API requests & document new paths (#3053)

* RS: Supported platform updates & Amazon Linux note (#3052)

* DOC-2447 Add RHEL 9 & retire RHEL 7

* Product lifecycle update

* DOC-3168 Known issue for RS 7.4.2 & Amazon Linux 2

* Remove RHEL 9 for now

* Added RHEL 8.9 to supported platforms

* RS: UI updates for Active-Active docs (#3046)

* DOC-2218 Causal consistency new UI updates

* DOC-2217 Manage Active-Active DBs new UI updates

* New UI updates for create database buttons

* DOC-2216 Update create Active-Active DB for new UI

* Fix role to add participating cluster

* DOC-3133 New UI instructions to create an Active-Active JSON DB & changed modules to capabilities

* Added in-page reference link

* DOC-3133 New UI instructions to create an Active-Active JSON DB

* DOC-3133 New UI instructions to create an Active-Active JSON DB

* DOC-2211 New UI updates for migrate to Active-Active doc

* DOC-2215 New UI updates for Active-Active quickstart

* DOC-2211 Migrate to Active-Active new UI screenshots

* DOC-2215 Active-Active quickstart new UI screenshots

* DOC-2216 Updated create Active-Active database screenshot

* DOC-2215 Active-Active quickstart updates

* DOC-2216 Small create Active-Active database edits

* DOC-2217 Add UI steps to remove participating cluster

* DOC-3255 Updated cluster license screenshot in RS quickstarts to remove sales email

* RS UI DB defaults: add endpoint config & remove replica HA & S3 import (#3062)

* DOC-3214 Removed Replica HA & S3 URL from database defaults

* DOC-3214 Removed Replica HA database defaults UI steps, fixed defaults note, & added screenshot

* DOC-3073 DB defaults UI updates: endpoint config, DB proxy, & shards placement

* DOC-3073 Feedback updates for default DB version & proxy policies

* DOC-3214 Deprecated cluster-level replica HA policy

* RS: New maintenance mode parameters (#3077)

* DOC-3275 New parameters for rladmin node maintenance_mode on

* DOC-3275 More rladmin node maintenance_mode updates

* DOC-3275 More rladmin node maintenance_mode updates

* DOC-3275 New parameters for node maintenance mode actions in the RS REST API

* DOC-3275 Added node snapshots REST API reference & examples for node maintenance_on REST API request

* RS: rlcheck reference options & tests (#3080)

* DOC-3287 rlcheck reference - added options & tests

* DOC-3287 Feedback updates

* DOC-3286 IPv6 for internal traffic (#3084)

* RS: LDAP auth timeout setting (#3085)

* DOC-3297 LDAP auth timeout UI setting

* DOC-3296 LDAP auth timeout REST API setting

* DOC-3299 Added /actions/bdb/bdb_uid RS REST API reference (#3086)

* RS: 7.4.2 Fuji release notes draft (#3089)

* DOC-2982 RS 7.4.2 Fuji release notes draft

* DOC-2982 TLS feedback updates for release notes

* DOC-2982 Maintenance mode feedback updates for release notes

* DOC-2982 Modules feedback updates for release notes

* DOC-3300 DOC-3302 Database auto recovery (#3087)

* DOC-3341 New status field for user REST API GET requests

* DOC-2982 Adding some links to the Fuji release notes

* DOC-2982 Adding more links to the Fuji release notes

* DOC-3076 RS 7.4 version selector updates

* DOC-2982 Updated RedisBloom versions in Fuji release notes

* Removed empty known issues section

* DOC-3300 Feedback update - clarifying auto recovery wait time

* Update _index.md

Need to update the os support: remove rhel 7 and oel7. Add this to the highlights as well.
Need to update security deprecations to security retirement 
Thanks!

* Marked OEL 7 as EOL in supported platforms table

* DOC-2993 Added Fuji build number and MD5 checksums to release notes

* Updated Fuji release month

* Added end of support notice for RHEL 7 and Oracle Linux 7

* Added deprecation notices for the legacy UI & Redis DB v6.0

* DOC-2993 Updated Fuji build number and MD5 checksums in release notes

* RHEL 9 support

* Updated 7.2 EOL

* Updated cluster upgrade paths & bundled DB versions

* Known limitation - list of legacy UI features not yet available in the new UI

* Fixed text for RHEL 9 md5 checksums

* Fixed 7.2 EOL & clarified full IPv6 support

---------

Co-authored-by: mich-elle-luna <[email protected]>
Co-authored-by: yoavredis <[email protected]>
Co-authored-by: adisht <[email protected]>
  • Loading branch information
4 people authored Feb 6, 2024
1 parent b91a679 commit 3e2d42b
Show file tree
Hide file tree
Showing 98 changed files with 2,321 additions and 799 deletions.
7 changes: 7 additions & 0 deletions content/embeds/json-active-active-command-differences.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
## Command differences

Some JSON commands work differently for Active-Active databases.

### `JSON.CLEAR`

[`JSON.CLEAR`](https://redis.io/commands/json.clear/) resets JSON arrays and objects. It supports concurrent updates to JSON documents from different instances in an Active-Active database and allows the results to be merged.
324 changes: 324 additions & 0 deletions content/embeds/json-active-active-conflict-resolution.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,324 @@
## Conflict resolution rules

With Active-Active databases, it's possible for two different instances to try to run write operations on the same data at the same time. If this happens, conflicts can arise when the replicas attempt to sync these changes with each other. Conflict resolution rules determine how the database handles conflicting operations.

There are two types of conflict resolution:

1. Merge:

- The operations are associative.

- Merges the results of both operations.

1. Win over:

- The operations are not associative.

- One operation wins the conflict and sets the value.

- Ignores the losing operation.

The following conflict resolution rules show how Active-Active databases resolve conflicts for various JSON commands.

### Assign different types to a key

**Conflict**

Two instances concurrently assign values of different types to the same key within a JSON document.

For example:

Instance 1 assigns an object to a key within a JSON document.

Instance 2 assigns an array to the same key.

**Resolution type**

Win over

**Resolution rule**

The instance with the smaller ID wins, so the key becomes an object in the given example.

**Example**

| Time | Description | Instance 1 | Instance 2 |
| :---: | :--- | :--- | :--- |
| t1 | Set the same key to an object or an array | JSON.SET doc $.a '{}' | JSON.SET doc $.a '[]' |
| t2 | Add data to the object and array | <nobr>JSON.SET doc $.a.x '“y”'</nobr> <br /><br /> Result: <br /> {"a": {"x": "y"}} | <nobr>JSON.SET doc $.a '["z"]'</nobr> <br /><br /> Result: <br /> {“a”: ["z"]} |
| t3 | Active-Active synchronization | – Sync – | – Sync – |
| t4 | Instance 1 wins | JSON.GET doc $ <br /><br /> Result: <br /> {"a": {"x": "y"}} | JSON.GET doc $ <br /><br /> Result: <br /> {"a": {"x": "y"}} |

### Create versus create

**Conflict**

Two instances concurrently use `JSON.SET` to assign a new JSON document to the same key.

**Resolution type**

Win over

**Resolution rule**

The instance with the smaller ID wins.

**Example**

| Time | Description | Instance 1 | Instance 2 |
| :---: | :--- | :--- | :--- |
| t1 | Create a new JSON document | <nobr>JSON.SET doc $ '{"field": "a"}'</nobr> | <nobr>JSON.SET doc $ '{"field": "b"}'</nobr> |
| t2 | Active-Active synchronization | – Sync – | – Sync – |
| t3 | Instance 1 wins | JSON.GET doc $ <br /><br /> Result: <br /> {"field": "a"} | JSON.GET doc $ <br /><br /> Result: <br /> {"field": "a"} |

### Create versus update

**Conflict**

Instance 1 creates a new document and assigns it to an existing key with `JSON.SET`.

Instance 2 updates the existing content of the same key with `JSON.SET`.

**Resolution type**

Win over

**Resolution rule**

The operation that creates a new document wins.

**Example**

| Time | Description | Instance 1 | Instance 2 |
| :---: | :--- | :--- | :--- |
| t1 | The document exists on both instances | JSON.GET doc $ <br /><br /> Result: <br /> {"field1": "value1"} | JSON.GET doc $ <br /><br /> Result: <br /> {"field1": "value1"} |
| t2 | Instance 1 creates a new document; instance 2 updates the existing document | <nobr>JSON.SET doc $ '{"field2": "value2"}'</nobr> | <nobr>JSON.SET doc $.field1 '[1, 2, 3]'</nobr> |
| t3 | Active-Active synchronization | – Sync – | – Sync – |
| t4 | Instance 1 wins | JSON.GET doc . <br /><br /> Result: <br /> {"field2": "value2"} | JSON.GET doc . <br /><br /> Result: <br /> {"field2": "value2"} |

### Delete versus create

**Conflict**

Instance 1 deletes a JSON document with `JSON.DEL`.

Instance 2 uses `JSON.SET` to create a new JSON document and assign it to the key deleted by instance 1.

**Resolution type**

Win over

**Resolution rule**

Document creation wins over deletion.

**Example**

| Time | Description | Instance 1 | Instance 2 |
| :---: | :--- | :--- | :--- |
| t1 | The document exists on both instances | JSON.GET doc $ <br /><br /> Result: <br /> {"field1": "value1"} | JSON.GET doc $ <br /><br /> Result: <br /> {"field1": "value1"} |
| t2 | Instance 1 deletes the document; instance 2 creates a new document | JSON.DEL doc | <nobr>JSON.SET doc $ '{"field1": "value2"}'</nobr> |
| t3 | Active-Active synchronization | – Sync – | – Sync – |
| t4 | Instance 2 wins | JSON.GET doc $ <br /><br /> Result: <br /> <nobr>{"field1": "value2"}</nobr> | JSON.GET doc $ <br /><br /> Result: <br /> {"field1": "value2"} |

### Delete versus update

**Conflict**

Instance 1 deletes a JSON document with `JSON.DEL`.

Instance 2 updates the content of the same document with `JSON.SET`.

**Resolution type**

Win over

**Resolution rule**

Document deletion wins over updates.

**Example**

| Time | Description | Instance 1 | Instance 2 |
| :---: | :--- | :--- | :--- |
| t1 | The document exists on both instances | JSON.GET doc $ <br /><br /> Result: <br /> <nobr>{"field1": "value1"}</nobr> | JSON.GET doc $ <br /><br /> Result: <br /> {"field1": "value1"} |
| t2 | Instance 1 deletes the document; instance 2 updates it | JSON.DEL doc | <nobr>JSON.SET doc $.field1 '[1, 2, 3]'</nobr> |
| t3 | Active-Active synchronization | – Sync – | – Sync – |
| t4 | Instance 1 wins | JSON.GET doc $ <br /><br /> Result: <br /> (nil) | JSON.GET doc $ <br /><br /> Result: <br /> (nil) |

### Update versus update

**Conflict**

Instance 1 updates a field inside a JSON document with `JSON.SET`.

Instance 2 updates the same field with a different value.

**Resolution type**

Win over

**Resolution rule**

The instance with the smallest ID wins.

**Example**

| Time | Description | Instance 1 | Instance 2 |
| :---: | :--- | :--- | :--- |
| t1 | The document exists on both instances | JSON.GET doc $ <br /><br /> Result: <br /> {"field": "a"} | JSON.GET doc $ <br /><br /> Result: <br /> {"field": "a"} |
| t2 | Update the same field with different data | <nobr>JSON.SET doc $.field "b"</nobr> | <nobr>JSON.SET doc $.field "c"</nobr> |
| t3 | Active-Active synchronization | – Sync – | – Sync – |
| t4 | Instance 1 wins | JSON.GET doc $ <br /><br /> Result: <br /> {"field": "b"} | JSON.GET doc $ <br /><br /> Result: <br /> {"field": "b"} |

### Update versus clear

The version of RedisJSON prior to v2.2 has two different ways to reset the content of a JSON object:

- Assign a new empty JSON object:

```sh
JSON.SET doc $.colors '{}'
```

If you use this method, it cannot be merged with a concurrent update.

- For each key, remove it with `JSON.DEL`:

```sh
JSON.DEL doc $.colors.blue
```

With this method, it can merge the reset with concurrent updates.

As of RedisJSON v2.2, you can use the `JSON.CLEAR` command to reset the JSON document without removing each key manually. This method also lets concurrent updates be merged.

#### Assign an empty object

**Conflict**

Instance 1 adds "red" to the existing "colors" object with `JSON.SET`.

Instance 2 assigns a new empty object for "colors".

**Resolution type**

Win over

**Resolution rule**

Document creation wins over the update, so the result will be an empty object.

**Example**

| Time | Description | Instance 1 | Instance 2 |
| :---: | :--- | :--- | :--- |
| t1 | The document exists on both instances | JSON.GET doc $ <br /><br /> Result: <br /> {"colors": {"blue": "#0000ff"}} | JSON.GET doc $ <br /><br /> Result: <br /> {"colors": {"blue": "#0000ff"}} |
| t2 | Instance 1 adds a new color; instance 2 resets colors to an empty object | <nobr>JSON.SET doc $.colors.red ‘#ff0000’</nobr> | JSON.SET doc $.colors ‘{}’ |
| t3 | Instance 2 adds a new color | | <nobr>JSON.SET doc $.colors.green ‘#00ff00’</nobr> |
| t4 | | JSON.GET doc $ <br /><br /> Result: <br /> {"colors": {"blue": "#0000ff", "red": "#ff0000"}} | JSON.GET doc $ <br /><br /> Result: <br /> {"colors": {"green": "#00ff00"}} |
| t5 | Active-Active synchronization | – Sync – | – Sync – |
| t6 | Instance 2 wins | JSON.GET doc $ <br /><br /> Result: <br /> {"colors": {"green": "#00ff00"}} | JSON.GET doc $ <br /><br /> Result: <br /> {"colors": {"green": "#00ff00"}} |

#### Use `JSON.CLEAR`

**Conflict**

Instance 1 adds "red" to the existing "colors" object with `JSON.SET`.

Instance 2 clears the "colors" object with `JSON.CLEAR` and adds "green" to "colors".

**Resolution type**

Merge

**Resolution rule**

Merges the results of all operations.

**Example**

| Time | Description | Instance 1 | Instance 2 |
| :---: | :--- | :--- | :--- |
| t1 | The document exists on both instances | JSON.GET doc $ <br /><br /> Result: <br /> {"colors": {"blue": "#0000ff"}} | JSON.GET doc $ <br /><br /> Result: <br /> {"colors": {"blue": "#0000ff"}} |
| t2 | Instance 1 adds a new color; instance 2 resets the colors | <nobr>JSON.SET doc $.colors.red ‘#ff0000’</nobr> | JSON.CLEAR doc $.colors |
| t3 | | JSON.GET doc $ <br /><br /> Result: <br /> {"colors": {"blue": "#0000ff", "red": "#ff0000"}} | JSON.GET doc $ <br /><br /> Result: <br /> {"colors": {}} |
| t4 | Instance 2 adds a new color | | <nobr>JSON.SET doc $.colors.green ‘#00ff00’</nobr> |
| t5 | | | JSON.GET doc $ <br /><br /> Result: <br /> {"colors": {"green": "#00ff00"}} |
| t6 | Active-Active synchronization | – Sync – | – Sync – |
| t7 | Merges the results of both instances | JSON.GET doc $ <br /><br /> Result: <br /> {"colors": {"red": "#ff0000", "green": "#00ff00"}} | JSON.GET doc $ <br /><br /> Result: <br /> {"colors": {"red": "#ff0000", "green": "#00ff00"}} |

### Update versus update array

**Conflict**

Two instances update the same existing array with different content.

**Resolution type**

Merge

**Resolution rule**

Merges the results of all operations on the array. Preserves the original element order from each instance.

**Example**

| Time | Description | Instance 1 | Instance 2 |
| :---: | :--- | :--- | :--- |
| t1 | The document exists on both instances | JSON.GET doc $ <br /><br /> Result: <br /> '["a", "b", "c"]' | JSON.GET doc $ <br /><br /> Result: <br /> '["a", "b", "c"]' |
| t2 | Instance 1 removes an array element; instance 2 adds one | JSON.ARRPOP doc $ 1 <br /><br /> Result: <br /> ["a", "c"] | <nobr>JSON.ARRINSERT doc $ 0 ‘“y”’</nobr> <br /><br /> Result: <br /> ["y", "a", "b", "c"] |
| t3 | Both instances add another element to the array | <nobr>JSON.ARRINSERT doc $ 1 ‘“x”’</nobr> <br /><br /> Result: <br /> ["a", "x", "c"] | <nobr>JSON.ARRINSERT doc $ 2 ‘“z”’</nobr> <br /><br /> Result: <br /> ["y", "a", "z", "b", "c"] |
| t4 | Active-Active synchronization | – Sync – | – Sync – |
| t5 | Merge results from both instances | JSON.GET doc $ <br /><br /> Result: <br /> ["y", "a", "x", "z", "c"] | JSON.GET doc $ <br /><br /> Result: <br /> ["y", "a", "x", "z", "c"] |

### Update versus delete array element

**Conflict**

Instance 1 removes an element from a JSON array with `JSON.ARRPOP`.

Instance 2 updates the same element that instance 1 removes.

**Resolution type**

Win over

**Resolution rule**

Deletion wins over updates.

**Example**

| Time | Description | Instance 1 | Instance 2 |
| :---: | :--- | :--- | :--- |
| t1 | The document exists on both instances | JSON.GET doc $ <br /><br /> Result: <br /> {“todo”: [{“title”: “buy milk”, “done”: false}]} | JSON.GET doc $ <br /><br /> Result: <br /> {“todo”: [{“title”: “buy milk”, “done”: false}]} |
| t2 | Instance 1 removes an array element; instance 2 updates the same element | <nobr>JSON.ARRPOP doc $.todo 0</nobr> | <nobr>JSON.SET doc '$.todo[0]["done"]' 'true'</nobr> |
| t3 | | JSON.GET doc $ <br /><br /> Result: <br /> {“todo”: []} | JSON.GET doc $ <br /><br /> Result: <br /> [{“title”: “buy milk”, “done”: true}]} |
| t4 | Active-Active synchronization | – Sync – | – Sync – |
| t5 | Instance 1 wins | JSON.GET doc $ <br /><br /> Result: <br /> doc = {“todo”: []} | JSON.GET doc $ <br /><br /> Result: <br /> doc = {“todo”: []} |

### Update versus update object

**Conflict**

Both instances update the same existing object with different content.

**Resolution type**

Merge

**Resolution rule**

Merges the results of all operations on the object.

**Example**

| Time | Description | Instance 1 | Instance 2 |
| :---: | :--- | :--- | :--- |
| t1 | The document exists on both instances | JSON.GET doc $ <br /><br /> Result: <br /> '{"grocery": []}' | JSON.GET doc $ <br /><br /> Result: <br /> '{"grocery": []}' |
| t2 | Add new elements to the array | <nobr>JSON.ARRAPPEND doc $.grocery ‘“eggs”’</nobr> | JSON.ARRAPPEND doc $.grocery ‘“milk”’ |
| t3 | Add new elements to the array | JSON.ARRAPPEND doc $.grocery ‘“ham”’ | <nobr>JSON.ARRAPPEND doc $.grocery ‘“flour”’</nobr> |
| t4 | | JSON.GET doc $ <br /><br /> Result: <br /> {"grocery":["eggs", "ham"]} | JSON.GET doc $ <br /><br /> Result: <br /> {"grocery":["milk", "flour"]} |
| t5 | Active-Active synchronization | – Sync – | – Sync – |
| t6 | Merges the results from both instances | JSON.GET doc . <br /><br /> Result: <br /> {"grocery":["eggs","ham","milk", "flour"]} | JSON.GET doc . <br /><br /> Result: <br /> {"grocery":["eggs","ham","milk", "flour" ]} |
Loading

0 comments on commit 3e2d42b

Please sign in to comment.