diff --git a/assets/css/index.css b/assets/css/index.css index bdbb02f086..2e63117dd4 100644 --- a/assets/css/index.css +++ b/assets/css/index.css @@ -23,16 +23,28 @@ section.prose { @apply font-geist } -.prose h1, -.prose h3, -.prose h4, -.prose h5, -.prose h6 { - @apply font-normal; +.prose h1 { + @apply text-4xl font-normal break-words; } .prose h2 { - @apply text-lg font-medium pb-3 border-b border-b-redis-pen-700 border-opacity-50; + @apply text-2xl font-medium pb-3 border-b border-b-redis-pen-700 border-opacity-50; +} + +.prose h3 { + @apply text-xl font-semibold; +} + +.prose h4 { + @apply text-lg font-medium; +} + +.prose h5 { + @apply text-base font-medium; +} + +.prose h6 { + @apply text-sm font-medium; } .prose p, .prose ol, .prose ul { @@ -47,10 +59,6 @@ section.prose { @apply bg-none font-monogeist; } -.prose h1 { - @apply text-4xl break-words; -} - .prose h1[id], .prose h2[id], .prose h3[id], diff --git a/content/develop/use/keyspace-notifications.md b/content/develop/use/keyspace-notifications.md index bfff7d2e99..ebc98e8f0e 100644 --- a/content/develop/use/keyspace-notifications.md +++ b/content/develop/use/keyspace-notifications.md @@ -83,6 +83,8 @@ following table: e Evicted events (events generated when a key is evicted for maxmemory) m Key miss events (events generated when a key that doesn't exist is accessed) n New key events (Note: not included in the 'A' class) + o Overwritten events (events generated every time a key is overwritten) + c Type-changed events (events generated every time a key's type changes) A Alias for "g$lshztxed", so that the "AKE" string means all the events except "m" and "n". At least `K` or `E` should be present in the string, otherwise no event @@ -150,6 +152,8 @@ Different commands generate different kind of events according to the following * Every time a key with a time to live associated is removed from the data set because it expired, an `expired` event is generated. * Every time a key is evicted from the data set in order to free memory as a result of the `maxmemory` policy, an `evicted` event is generated. * Every time a new key is added to the data set, a `new` event is generated. +* Every time a key is being overwritten, an `overwritten` event is generated. +* Every time a key's type changes, a `type_changed` event is generated. **IMPORTANT** all the commands generate events only if the target key is really modified. For instance an [`SREM`]({{< relref "/commands/srem" >}}) deleting a non-existing element from a Set will not actually change the value of the key, so no event will be generated. diff --git a/content/operate/rc/databases/configuration/data-eviction-policies.md b/content/operate/rc/databases/configuration/data-eviction-policies.md index 89844228f0..e29f399ab3 100644 --- a/content/operate/rc/databases/configuration/data-eviction-policies.md +++ b/content/operate/rc/databases/configuration/data-eviction-policies.md @@ -35,7 +35,17 @@ For each database, you can choose from these data eviction policies: ## Prevent data eviction -Redis Cloud supports [Auto Tiering]({{< relref "/operate/rs/databases/auto-tiering/" >}}) +Redis Cloud supports [Auto Tiering]({{< relref "/operate/rs/databases/auto-tiering/" >}}) to prevent data eviction but maintain high performance. Auto Tiering can extend your database across RAM and Flash Memory and intelligently manage "hot" (active) data in RAM and "cold" (less active) data in Flash memory (SSD). + +## Active-Passive replication considerations + +When using [Active-Passive replication]({{< relref "/operate/rc/databases/migrate-databases#sync-using-active-passive" >}}), eviction and expiration only operate on the source (active) database. The target database does not evict or expire data while Active-Passive is enabled. + +Do not write to the target database while Active-Passive is enabled. Doing so can cause the following issues: + +- The target database cannot rely on eviction or expiration to manage local writes, requiring sufficient memory to handle both replicated data and local writes. +- Local writes create differences between the source and target databases, causing replicated commands to behave differently on each database. +- Inconsistent data can cause replicated commands to fail with errors, which will cause the synchronization process to exit and break replication. \ No newline at end of file diff --git a/content/operate/rc/databases/migrate-databases.md b/content/operate/rc/databases/migrate-databases.md index 0c009311b1..a00a592987 100644 --- a/content/operate/rc/databases/migrate-databases.md +++ b/content/operate/rc/databases/migrate-databases.md @@ -56,7 +56,7 @@ Before you use Active-Passive, be aware of the following limitations: - An error will appear when syncing the two databases if the source and target databases are hosted on different Redis Cloud accounts. [Contact support](https://redis.io/support/) if you want to migrate a database between accounts using Active-Passive. -- As long as Active-Passive is enabled, data in the target database will not expire and will not be evicted regardless of the set [data eviction policy]({{< relref "/operate/rc/databases/configuration/data-eviction-policies.md" >}}). We recommend that you turn off Active-Passive after the databases are synced. +- As long as Active-Passive is enabled, data in the target database will not expire and will not be evicted regardless of the set [data eviction policy]({{< relref "/operate/rc/databases/configuration/data-eviction-policies.md" >}}). **Do not write to the target database while Active-Passive is enabled.** We recommend that you turn off Active-Passive after the databases are synced. - Turning on Active-Passive will flush the target database. Make sure that your target database has no important data before you turn on Active-Passive. {{< /note >}} @@ -135,7 +135,11 @@ Follow these detailed steps to migrate data using Active-Passive syncing: {{When the data is migrated, the target database status displays `Synced`.}} -Active-Passive sync lets you migrate data while apps and other connections are using the source database. Once the data is migrated, you should migrate active connections to the target database. +Active-Passive sync lets you migrate data while apps and other connections are using the source database. Once the data is migrated, you should migrate active connections to the target database. + +{{< warning >}} +Do not write to the target database until turning off Active-Passive. Writing to the target database of an Active-Passive setup can cause data consistency issues and replication failures. See [Active-Passive replication considerations]({{< relref "/operate/rc/databases/configuration/data-eviction-policies.md#active-passive-replication-considerations" >}}) for more information. +{{< /warning >}} ## Active-Passive memory requirements