minor updates for 2.2 release (#5094)

docs/content/latest/api/ycql/ddl_create_index.md

@@ -82,11 +82,7 @@ Where
 - An error is raised if `index_name` already exists in the associated keyspace unless the `IF NOT EXISTS` option is used.
 - Indexes do not support TTL. An error is raised if data is inserted with TTL into a table with indexes.
 
-{{< note title="Note" >}}                                                                            
-
-When an index is created on an existing table, YugabyteDB will automatically backfill existing data
-into the index in an online manner (that is, while continuing to serve other concurrent writes and traffic). For more details 
-on how this is done, see [Online Index Backfill](https://github.com/yugabyte/yugabyte-db/blob/master/architecture/design/online-index-backfill.md)
+{{< note title="Note" >}}                                                                                                                                                         When an index is created on an existing table, YugabyteDB will automatically backfill existing data into the index in an online manner (that is, while continuing to serve other concurrent writes and traffic). For more details on how this is done, see [Online Index Backfill](https://github.com/yugabyte/yugabyte-db/blob/master/architecture/design/online-index-backfill.md)
 
 {{< /note >}}
 

docs/content/latest/manage/backup-restore/snapshots-ycql.md

@@ -33,23 +33,7 @@ showAsideToc: true
 
 </ul>
 
-You can create a backup for YugabyteDB using snapshots. Here are some points to keep in mind.
-
-- Distributed backups using snapshots
-  - Massively parallel, efficient for very large data sets
-  - Snapshots are not transactional across the whole table, but only on each tablet [#2086](https://github.com/YugaByte/yugabyte-db/issues/2086).
-  - Multi-table transactional snapshot is in the road map [#2084](https://github.com/YugaByte/yugabyte-db/issues/2084). 
-  - Single table snapshots don't work in YSQL [#2083](https://github.com/YugaByte/yugabyte-db/issues/2083).
-  - Yugabyte Platform automates these steps for you.
-- Implementation notes:
-  - Once the snapshot command is issued, you will “buffer” newly incoming writes to that tablet without writing them immediately.
-  - For the existing data: you flush it to disk and hardlink the files in a `.snapshots` directory on each tablet.
-  - These steps are pretty fast - small flush to disk and hardlinks. Most likely the incoming operations that were buffered will not timeout. 
-  - The buffered writes are now opened up for writes.
-  - The snapshot operation is done. Because YugabyteDB is an LSM database, these files will never get modified.
-  - If this takes longer, some ops can timeout but in practice, users should expect such slowness occasionally when using network storage (AWS EBS, Persistent Disk in GCP, SAN storage, etc.).
-
-In this tutorial, you will be using YCQL, but the same APIs are used in YSQL.
+You can create a transactonal backup for a YCQL table (which includes its associated secondary indexes) using snapshots.
 
 ## Step 1: Create a local cluster
 

docs/content/latest/reference/configuration/yugabyted.md

@@ -146,7 +146,13 @@ The port on which main webserver will run.
 
 The IP address or localhost name to which `yugabyted` will listen.
 
-##### --join *master-ip* [BETA]
+##### --join *master-ip*
+
+{{< note title="Note" >}}
+
+This feature is currently in [Beta](../../../../faq/general/#what-is-the-definition-of-the-beta-feature-tag).
+
+{{< /note >}}
 
 The IP address of the existing `yugabyted` server to which the new `yugabyted` server will join.
 

docs/content/latest/yedis/_index.md

@@ -15,25 +15,23 @@ menu:
     weight: 2900
 ---
 
-The YEDIS API allows YugabyteDB to function as a clustered, auto-sharded, globally distributed and persistent key-value database that is compatible with the Redis commands library. A Redis client can connect, send requests, and receive results from this API.
+The YEDIS API allows YugabyteDB to function as a persistent, resilient, auto-sharded, globally-distributed key-value database that is compatible with the Redis commands library. A Redis client can connect, send requests, and receive results from this API.
 
 {{< note title="Note" >}}
-While YEDIS supports many Redis data types (such as string, hash, set, sorted set and a new Timeseries type) and commands, there are some notable exceptions at present.
+<b>
+Yugabyte's current focus is on the two distributed SQL APIs, namely YSQL (Postgres-compatible fully-relational API) and YCQL (a semi-relational API with Cassandra QL roots). Given that YEDIS is not a focus, it must be viewed as a deprecated API for new application development purposes.
+</b>
+
+While YEDIS supports many Redis data types (such as string, hash, set, sorted set and a new timeseries type) and commands, there are some notable exceptions at present.
 
 * Only a subset of sorted set commands (ZCARD, ZADD, ZRANGEBYSCORE, ZREM, ZRANGE, ZREVRANGE, ZSCORE) have been implemented. Several commands like ZCOUNT, ZREVRANGEBYSCORE, ZRANK, ZREVRANK are not yet implemented.
+
 * List, Bitmaps, HyperLogLogs, GeoSpatial types/commands are not yet implemented.
 
-<b>
-In the near-term, YugabyteDB is not actively working on new feature or driver enhancements to the YEDIS API other than bug fixes and stability improvements. Current focus is on YSQL (Postgres-compatible distributed SQL API) and YCQL (a flexible-schema API with Cassandra QL roots).
-</b>
+* YugabyteDB is a full-featured disk-based database and does not have an in-memory only architecture like Redis.
 
-For key-value workloads that need persistence, elasticity and fault-tolerance, YCQL (with features
-like keyspaces, tables, role-based access control and more) is often a great fit, especially if the
-application is new rather than an existing one already written in Redis. The YCQL drivers are also
-more clustering aware in terms of routing the request directly to the node which hosts the row/key,
-and hence YCQL even performs marginally better than YEDIS for equivalent scenarios. In general, our
-new feature development (support for data types, built-ins, TLS, backups and more), correctness
-testing (using e.g., Jepsen) and performance work is in the YSQL and YCQL areas.  {{< /note >}}
+The above means that YEDIS is not a drop-in replacement to an existing Redis app. For key-value workloads that need persistence, elasticity and fault tolerance, YCQL (with features like keyspaces, tables, role-based access control and more) is often a great fit, especially if the application is new rather than an existing one already written in Redis. The YCQL drivers are also more clustering aware in terms of routing the request directly to the node which hosts the row/key, and hence YCQL even performs marginally better than YEDIS for equivalent scenarios. In general, our new feature development (support for data types, built-ins, TLS, backups and more), correctness testing (using e.g., Jepsen) and performance work is in the YSQL and YCQL areas.  
+{{< /note >}}
 
 
 <div class="row">