doc: remove info about outdated versions
This PR removes information about outdated versions, including disclaimers and information when a given feature was added. Now that the documentation is versioned, information about outdated versions is unnecessary (and makes the docs harder to read). Fixes https://github.com/scylladb/scylladb/issues/12110 Closes scylladb/scylladb#17430
This commit is contained in:
Anna Stuchlik
committed by
Avi Kivity
Avi Kivity
parent
93af3dd69b
commit
37237407f6
@@ -43,7 +43,4 @@ Hinted handoff is enabled and managed by these settings in :code:`scylla.yaml`:
|
||||
|
||||
Storing of the hint can also fail. Enabling hinted handoff therefore does not eliminate the need for repair; a user must recurrently :doc:`run a full repair </operating-scylla/procedures/maintenance/repair/>` to ensure data consistency across the cluster nodes.
|
||||
|
||||
Hinted handoff was released as production-ready in Scylla Open Source 3.0 and Scylla Enterprise 2019.1.
|
||||
|
||||
|
||||
.. include:: /rst_include/apache-copyrights.rst
|
||||
|
||||
@@ -94,7 +94,7 @@ columns effects of both statements are preserved:
|
||||
|
||||
Also note that ``INSERT`` does not support counters, while ``UPDATE`` does.
|
||||
|
||||
.. note:: New in Scylla Open Source 3.2, you can use the ``IF NOT EXISTS`` condition with the ``INSERT`` statement. When this is used, the insert is only made if the row does not exist prior to the insertion. Each such ``INSERT`` gets a globally unique timestamp. Using ``IF NOT EXISTS`` incurs a non-negligible performance cost (internally, as Paxos will be used), so use ``IF NOT EXISTS`` wisely.
|
||||
.. note:: You can use the ``IF NOT EXISTS`` condition with the ``INSERT`` statement. When this is used, the insert is only made if the row does not exist prior to the insertion. Each such ``INSERT`` gets a globally unique timestamp. Using ``IF NOT EXISTS`` incurs a non-negligible performance cost (internally, as Paxos will be used), so use ``IF NOT EXISTS`` wisely.
|
||||
|
||||
|
||||
If :ref:`enabled <cdc-options>` on a table, you can use UPDATE, INSERT, and DELETE statements with Change Data Capture (CDC) tables.
|
||||
|
||||
@@ -22,9 +22,6 @@
|
||||
Global Secondary Indexes
|
||||
------------------------
|
||||
|
||||
Global Secondary Indexes is production ready in Scylla Open Source 3.0 and Scylla Enterprise 2019.1.x
|
||||
|
||||
|
||||
CQL supports creating secondary indexes on tables, allowing queries on the table to use those indexes. A secondary index
|
||||
is identified by a name defined by:
|
||||
|
||||
|
||||
@@ -35,9 +35,6 @@ i3en instances
|
||||
^^^^^^^^^^^^^^
|
||||
i3en instances have up to 4x the networking bandwidth of i3 instances, enabling up to 100 Gbps of sustained network bandwidth.
|
||||
|
||||
i3en support is available for ScyllaDB Enterprise 2019.1.1 and higher and ScyllaDB Open Source 3.1 and higher.
|
||||
|
||||
|
||||
=========================== =========== ============ =====================
|
||||
Model vCPU Mem (GB) Storage (NVMe SSD)
|
||||
=========================== =========== ============ =====================
|
||||
@@ -70,8 +67,6 @@ See `Amazon EC2 I3en Instances <https://aws.amazon.com/ec2/instance-types/i3en/>
|
||||
|
||||
i4i instances
|
||||
^^^^^^^^^^^^^^
|
||||
i4i support is available for ScyllaDB Open Source 5.0 and later and ScyllaDB Enterprise 2021.1.10 and later.
|
||||
|
||||
=========================== =========== ============ =====================
|
||||
Model vCPU Mem (GB) Storage (NVMe SSD)
|
||||
=========================== =========== ============ =====================
|
||||
|
||||
@@ -6,8 +6,8 @@
|
||||
* :doc:`Scylla SStable </operating-scylla/admin-tools/scylla-sstable>` - Validates and dumps the content of SStables, generates a histogram, dumps the content of the SStable index.
|
||||
* :doc:`Scylla Types </operating-scylla/admin-tools/scylla-types/>` - Examines raw values obtained from SStables, logs, coredumps, etc.
|
||||
* :doc:`cassandra-stress </operating-scylla/admin-tools/cassandra-stress/>` A tool for benchmarking and load testing a Scylla and Cassandra clusters.
|
||||
* :doc:`SSTabledump - Scylla 3.0, Scylla Enterprise 2019.1 and newer versions </operating-scylla/admin-tools/sstabledump>`
|
||||
* :doc:`SSTableMetadata - Scylla 3.0, Scylla Enterprise 2019.1 and newer versions </operating-scylla/admin-tools/sstablemetadata>`
|
||||
* :doc:`SSTabledump </operating-scylla/admin-tools/sstabledump>`
|
||||
* :doc:`SSTableMetadata </operating-scylla/admin-tools/sstablemetadata>`
|
||||
* sstablelevelreset - Reset level to 0 on a selected set of SSTables that use LeveledCompactionStrategy (LCS).
|
||||
* sstablerepairedset - Mark specific SSTables as repaired or unrepaired.
|
||||
* `scyllatop <https://www.scylladb.com/2016/03/22/scyllatop/>`_ - A terminal base top-like tool for scylladb collectd/prometheus metrics.
|
||||
|
||||
@@ -5,7 +5,6 @@ SSTabledump
|
||||
Please consider switching to :doc:`Scylla SSTable </operating-scylla/admin-tools/scylla-sstable>`.
|
||||
|
||||
This tool allows you to converts SSTable into a JSON format file.
|
||||
SSTabledump supported when using Scylla 3.0, Scylla Enterprise 2019.1, and newer versions.
|
||||
If you need more flexibility or want to dump more than just the data-component, see :doc:`scylla-sstable </operating-scylla/admin-tools/scylla-sstable>`.
|
||||
|
||||
|
||||
|
||||
@@ -5,7 +5,6 @@ SSTableMetadata
|
||||
Please consider switching to :ref:`scylla sstable dump-statistics` and :ref:`scylla sstable dump-summary`.
|
||||
|
||||
SSTableMetadata prints metadata in ``Statistics.db`` and ``Summary.db`` about the specified SSTables to the console.
|
||||
This tool is supported in Scylla 3.0, Scylla Enterprise 2019.1, and newer versions.
|
||||
|
||||
Use the full path to the data file when executing the command.
|
||||
|
||||
|
||||
@@ -22,10 +22,4 @@ To clean up the data of a specific node and specific keyspace, use this command:
|
||||
|
||||
Make sure there are no topology changes before running cleanup. To validate, run ``nodetool status``, all nodes should be in status Up Normal (``UN``).
|
||||
|
||||
.. note::
|
||||
|
||||
If using Scylla Enterprise 2018.1.5, Scylla Open Source 2.2.0, 2.3.0 or lower version **Do not** run the ``nodetool cleanup`` command before upgrading to the latest release of your branch, see this issue_ for further information.
|
||||
|
||||
.. _issue: https://github.com/scylladb/scylla/issues/3872
|
||||
|
||||
.. include:: nodetool-index.rst
|
||||
|
||||
@@ -59,17 +59,6 @@ Procedure
|
||||
|
||||
* **seeds** - Specifies the IP address of an existing node in the cluster. The new node will use this IP to connect to the cluster and learn the cluster topology and state.
|
||||
|
||||
.. note::
|
||||
|
||||
In earlier versions of ScyllaDB, seed nodes assisted in gossip. Starting with Scylla Open Source 4.3 and Scylla Enterprise 2021.1, the seed concept in gossip has been removed. If you are using an earlier version of ScyllaDB, you need to configure the seeds parameter in the following way:
|
||||
|
||||
* Specify the list of the current seed nodes in the cluster.
|
||||
* Do not list the node you're adding as a seed node.
|
||||
|
||||
See :doc:`Scylla Seed Nodes</kb/seed-nodes>` for more information.
|
||||
|
||||
We recommend updating your ScyllaDB to version 4.3 or later (Open Source) or 2021.1 or later (Enterprise).
|
||||
|
||||
#. Start the ScyllaDB node with the following command:
|
||||
|
||||
.. include:: /rst_include/scylla-commands-start-index.rst
|
||||
@@ -117,10 +106,6 @@ Procedure
|
||||
|
||||
#. Wait until the new node becomes UN (Up Normal) in the output of :doc:`nodetool status </operating-scylla/nodetool-commands/status>` on one of the old nodes.
|
||||
|
||||
.. note::
|
||||
If you are using ScyllaDB Open Source 4.3 or later or ScyllaDB Enterprise 2021.1 or later and configure the list of seed nodes to participate in gossip, you can now edit the ``scylla.yaml`` files to add the new node as a seed node.
|
||||
You don't need to restart the Scylla service after modifying the seeds list in ``scylla.yaml``.
|
||||
|
||||
#. If you are using Scylla Monitoring, update the `monitoring stack <https://monitoring.docs.scylladb.com/stable/install/monitoring_stack.html#configure-scylla-nodes-from-files>`_ to monitor it. If you are using Scylla Manager, make sure you install the `Manager Agent <https://manager.docs.scylladb.com/stable/install-scylla-manager-agent.html>`_, and Manager can access it.
|
||||
|
||||
Handling Failures
|
||||
|
||||
@@ -83,8 +83,6 @@ To save bandwidth, add the ``prefer_local=true`` parameter. Scylla will use the
|
||||
5. Verify that the node added to the cluster
|
||||
``nodetool status``
|
||||
|
||||
6. If you are running a Scylla version earlier than Scylla Open Source 4.3 or Scylla Enterprise 2021.1, you need to update the seeds parameter in each node's scylla.yaml file to include the IP of at least one more seed node. See :ref:`Older Version Of Scylla <seeds-older-versions>` for details. You should specify at least two seed nodes per DC. Remember to use public IPs.
|
||||
|
||||
**For Example:**
|
||||
|
||||
In this example, we will show how to install a nine nodes cluster.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
Create a ScyllaDB Cluster on EC2 (Single or Multi Data Center)
|
||||
===============================================================
|
||||
|
||||
The easiest way to run a Scylla cluster on EC2 is by using `Scylla AMI <https://www.scylladb.com/download/?platform=aws>`_, which is Ubuntu-based since ScyllaDB Enterprise 2021.1.0 and
|
||||
ScyllaDB Open Source 4.5 (prior versions are CentOS-based). To use a different OS or your own `AMI <https://en.wikipedia.org/wiki/Amazon_Machine_Image>`_ (Amazon Machine Image) or set up a multi DC Scylla cluster,
|
||||
The easiest way to run a Scylla cluster on EC2 is by using `Scylla AMI <https://www.scylladb.com/download/?platform=aws>`_, which is Ubuntu-based.
|
||||
To use a different OS or your own `AMI <https://en.wikipedia.org/wiki/Amazon_Machine_Image>`_ (Amazon Machine Image) or set up a multi DC Scylla cluster,
|
||||
you need to configure the Scylla cluster on your own. This page guides you through this process.
|
||||
|
||||
A Scylla cluster on EC2 can be deployed as a single-DC cluster or a multi-DC cluster. The table below describes how to configure parameters in the ``scylla.yaml`` file for each node in your cluster for both cluster types.
|
||||
|
||||
@@ -46,15 +46,6 @@ Prerequisites
|
||||
---------
|
||||
Procedure
|
||||
---------
|
||||
.. note::
|
||||
If your Scylla version is earlier than Scylla Open Source 4.3 or Scylla Enterprise 2021.1, check if
|
||||
the dead node is a seed node by running ``cat /etc/scylla/scylla.yaml | grep seeds:``.
|
||||
|
||||
* If the dead node’s IP address is listed, the dead node is a seed node. Replace the seed node following the instructions in :doc:`Replacing a Dead Seed Node </operating-scylla/procedures/cluster-management/replace-seed-node>`.
|
||||
* If the dead node’s IP address is not listed, the dead node is not a seed node. Replace it according to the procedure below.
|
||||
|
||||
We recommend checking the seed nodes configuration of all nodes. Refer to :doc:`Seed Nodes</kb/seed-nodes>` for details
|
||||
|
||||
|
||||
#. Install Scylla on a new node, see :doc:`Getting Started</getting-started/index>` for further instructions. Follow the Scylla install procedure up to ``scylla.yaml`` configuration phase. Ensure that the Scylla version of the new node is identical to the other nodes in the cluster.
|
||||
|
||||
|
||||
@@ -6,8 +6,7 @@ In cases where you need to physically move hardware, or you have no other choice
|
||||
|
||||
**Before you begin**
|
||||
|
||||
* Confirm no applications are running that are using the cluster as backend storage.
|
||||
* (Only for versions prior to Scylla Open Source 4.3 and Scylla Enterprise 2021.1) Confirm that you know which nodes are the seed nodes. Seed nodes are specified in the ``scylla.yaml`` file.
|
||||
Confirm no applications are running that are using the cluster as backend storage.
|
||||
|
||||
**Procedure**
|
||||
|
||||
|
||||
@@ -6,16 +6,10 @@ In cases where you needed to shut down your cluster, use this procedure to bring
|
||||
|
||||
**Before you begin**
|
||||
|
||||
* Confirm that the cluster was shut down using the :doc:`shutdown procedure <safe-shutdown>`.
|
||||
* (Only for versions prior to Scylla Open Source 4.3 and Scylla Enterprise 2021.1) Confirm that you know which nodes are the seed nodes. Seed nodes are specified in the ``scylla.yaml`` file.
|
||||
Confirm that the cluster was shut down using the :doc:`shutdown procedure <safe-shutdown>`.
|
||||
|
||||
**Procedure**
|
||||
|
||||
.. note::
|
||||
If your Scylla version is earlier than Scylla Open Source 4.3 or Scylla Enterprise 2021.1, start the seed
|
||||
nodes first. Validate that the seed nodes have all returned to normal by running :doc:`nodetool status </operating-scylla/nodetool-commands/status/>`.
|
||||
If each seed node's status is listed as ``UN``, you can start the remaining nodes.
|
||||
|
||||
#. Start the nodes in parallel.
|
||||
|
||||
.. include:: /rst_include/scylla-commands-start-index.rst
|
||||
|
||||
@@ -37,7 +37,7 @@ In most cases, the proportion of data that is out of sync is very small. In a f
|
||||
Row-level Repair
|
||||
----------------
|
||||
|
||||
In previous versions of Scylla (prior to 3.1), repairs were done on the partition level. Scylla 3.1 introduced row-level repair where the repair process only transferred the mismatched rows, instead of the entire partition.
|
||||
ScyllaDB uses row-level repair.
|
||||
|
||||
Row-level repair improves Scylla in two ways:
|
||||
|
||||
|
||||
@@ -72,17 +72,6 @@ Gossip Configuration
|
||||
|
||||
Use :code:`NetworkTopologyStrategy` replication-strategy as it supports multi-DC for your keyspaces.
|
||||
|
||||
Seed Node Redundancy
|
||||
====================
|
||||
Scylla Open Source 4.3 and later and Scylla Enterprise 2021.1 and later are seedless. See `Seedless NoSQL: Getting Rid of Seed Nodes in ScyllaDB <https://www.scylladb.com/2020/09/22/seedless-nosql-getting-rid-of-seed-nodes-in-scylla/>`_.
|
||||
|
||||
If you are using an earlier Scylla version:
|
||||
|
||||
* Each DC needs to have multiple seed nodes.
|
||||
* We recommend having **2-3 seed nodes per DC**.
|
||||
|
||||
See :doc:`Scylla Seed Nodes </kb/seed-nodes/>` for details.
|
||||
|
||||
Performance
|
||||
-----------
|
||||
|
||||
|
||||
@@ -118,7 +118,7 @@ For example:
|
||||
IPv6 Addresses
|
||||
--------------
|
||||
|
||||
Starting with Scylla Open Source 3.2, Scylla Enterprise 2019.1.4, Manager 2.0, and Monitoring 3.0, you can use IPv6 addresses wherever an IPv4 address is used, including client-to-node and node-to-node communication, Scylla Manager to Scylla nodes (Scylla Manager Agent), and Monitoring to nodes.
|
||||
You can use IPv6 addresses wherever an IPv4 address is used, including client-to-node and node-to-node communication, Scylla Manager to Scylla nodes (Scylla Manager Agent), and Monitoring to nodes.
|
||||
|
||||
For example:
|
||||
|
||||
|
||||
@@ -47,9 +47,7 @@ For example:
|
||||
Using system tables to detect large partitions, rows, or cells
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Starting from scylla 2.3, large partitions are listed in the ``system.large_partitions`` table. See :doc:`Scylla Large Partitions Table </troubleshooting/large-partition-table/>` for more information.
|
||||
|
||||
Starting from scylla 3.1, large rows and large cells are listed similarly in the ``system.large_rows`` and ``system.large_cells`` tables, respectively. See :doc:`Scylla Large Rows and Cells Tables </troubleshooting/large-rows-large-cells-tables/>` for more information.
|
||||
Large rows and large cells are listed in the ``system.large_rows`` and ``system.large_cells`` tables, respectively. See :doc:`Scylla Large Rows and Cells Tables </troubleshooting/large-rows-large-cells-tables/>` for more information.
|
||||
|
||||
|
||||
When Compaction Creates an Error
|
||||
|
||||
@@ -16,7 +16,7 @@ Possible cause: The Scylla process is managed by systemd, and systemd expects it
|
||||
systemd[1]: scylla-server.service start operation timed out. Terminating.
|
||||
|
||||
|
||||
The timeout in systemd should be enough to always start the server, but some versions of Scylla prior to 3.0 suffered from an issue in which the startup process could be slowed down. Even in the absence of issues since the timeout is just a number, there may be extreme cases in which it is not enough.
|
||||
The timeout in systemd should be enough to always start the server. However, there may be extreme cases in which it is not enough.
|
||||
|
||||
Solution
|
||||
^^^^^^^^
|
||||
|
||||
@@ -3,5 +3,3 @@ Scylla Alternator: The Open Source DynamoDB-compatible API
|
||||
Project Alternator is an open-source project for an Amazon DynamoDB™-compatible API written in C++. The goal of this project is to deliver an open source alternative to Amazon’s DynamoDB, deployable wherever a user would want: on-premises, on other public clouds like Microsoft Azure or Google Cloud Platform, or still on AWS (for users who wish to take advantage of other aspects of Amazon’s market-leading cloud ecosystem, such as the high-density i3en instances).
|
||||
|
||||
DynamoDB users can keep their same client code unchanged.
|
||||
|
||||
Scylla Alternator is available as GA for Scylla Open Source 4.0 and Scylla Enterprise 2020.1.0
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
|
||||
.. note::
|
||||
CDC is production-ready (GA) from ScyllaDB Enterprise 2021.1.1.
|
||||
@@ -2,8 +2,6 @@
|
||||
Basic operations in CDC
|
||||
=======================
|
||||
|
||||
.. include:: /using-scylla/cdc/_common/cdc-experimental.rst
|
||||
|
||||
The CDC log table reflects operations that are performed on the base table. Different types of operations give different corresponding entries in the CDC log. These operations are:
|
||||
|
||||
* inserts,
|
||||
|
||||
@@ -5,8 +5,6 @@ CDC Overview
|
||||
|
||||
:abbr:`CDC (Change Data Capture)` is a feature that allows you to not only query the current state of a database's table, but also query the history of all changes made to the table.
|
||||
|
||||
.. include:: /using-scylla/cdc/_common/cdc-experimental.rst
|
||||
|
||||
As an example, suppose you made a sequence of changes to some table in the given order:
|
||||
|
||||
.. code-block:: cql
|
||||
|
||||
@@ -48,8 +48,6 @@ The preimage row is created if and only if the read returned the corresponding b
|
||||
|
||||
The deletion columns (``cdc$deleted_X``) are set to ``true`` for columns that have a ``null`` value in the preimage, but only for those columns that the write modified or for all columns if the ``full`` option for preimages is enabled. The deleted elements columns (``cdc$deleted_elements_X``, for non-frozen collections and UDTs) are not used by preimage rows and are set to ``null``.
|
||||
|
||||
.. note:: Prior to Scylla 4.6, the deletion columns (``cdc$deleted_X``) and deleted elements columns (``cdc$deleted_elements_X``, for non-frozen collections and UDTs) were always ``null``.
|
||||
|
||||
Consider the following example:
|
||||
|
||||
.. code-block:: cql
|
||||
|
||||
@@ -2,8 +2,6 @@
|
||||
Querying CDC Streams
|
||||
====================
|
||||
|
||||
.. include:: /using-scylla/cdc/_common/cdc-experimental.rst
|
||||
|
||||
Some use cases for CDC may require querying the log table periodically in short intervals. One way to do that would be to perform **partition scans**, where you don't specify the partition (in this case, the stream) which you want to query, for example:
|
||||
|
||||
.. code-block:: cql
|
||||
|
||||
@@ -19,8 +19,6 @@ Change Data Capture (CDC)
|
||||
|
||||
:abbr:`CDC (Change Data Capture)` is a feature that allows you to not only query the current state of a database's table, but also query the history of all changes made to the table.
|
||||
|
||||
.. include:: /using-scylla/cdc/_common/cdc-experimental.rst
|
||||
|
||||
.. panel-box::
|
||||
:title: Change Data Capture
|
||||
:id: "getting-started"
|
||||
|
||||
@@ -2,8 +2,6 @@
|
||||
Global Secondary Indexes
|
||||
===============================
|
||||
|
||||
Global Secondary Indexes is available as a production ready feature in Scylla Open Source and Scylla Enterprise (all supported versions).
|
||||
|
||||
The data model in Scylla partitions data between cluster nodes using a partition key, which is defined in the database schema. This is an efficient way to look up rows because you can find the node hosting the row by hashing the partition key.
|
||||
|
||||
However, this also means that finding a row using a non-partition key requires a full table scan which is inefficient.
|
||||
|
||||
Reference in New Issue
Block a user