Botond Dénes eba310163d multishard_combining_reader: fix handling of non-strictly monotonous positions
The shard readers under a multishard reader are paused after every
operation executed on them. When paused they can be evicted at any time.
When this happens, they will be re-created lazily on the next
operation, with a start position such that they continue reading from
where the evicted reader left off. This start position is determined
from the last fragment seen by the previous reader. When this position
is clustering position, the reader will be recreated such that it reads
the clustering range (from the half-read partition): (last-ckey, +inf).
This can cause problems if the last fragment seen by the evicted reader
was a range-tombstone. Range tombstones can share the same clustering
position with other range tombstones and potentially one clustering row.
This means that when the reader is recreated, it will start from the
next clustering position, ignoring any unread fragments that share the
same position as the last seen range tombstone.
To fix, ensure that on each fill-buffer call, the buffer contains all
fragments for the last position. To this end, when the last fragment in
the buffer is a range tombstone (with pos x), we continue reading until
we see a fragment with a position y that is greater. This way it is
ensured that we have seen all fragments for pos x and it is safe to
resume the read, starting from after position x.
2019-04-26 11:38:12 +03:00
2019-03-22 09:08:51 +08:00
2019-04-21 18:12:58 +03:00
2018-11-21 00:01:44 +02:00
2018-08-01 16:50:58 +01:00
2018-12-03 11:18:02 +02:00
2018-11-26 18:59:41 +01:00
2019-03-28 14:21:10 +02:00
2019-04-20 09:16:53 +03:00
2018-11-27 13:01:02 +02:00
2018-06-19 16:26:51 +03:00
2018-11-21 00:01:44 +02:00
2018-11-21 00:01:44 +02:00
2018-11-21 00:01:44 +02:00
2018-11-21 00:01:44 +02:00
2019-03-28 14:21:10 +02:00
2019-02-20 08:03:46 -08:00
2018-11-21 00:01:44 +02:00
2018-02-14 14:15:59 -05:00
2019-01-22 15:34:32 +02:00
2019-02-20 08:03:46 -08:00
2019-02-20 08:03:46 -08:00
2018-11-01 13:16:17 +00:00
2019-03-28 14:21:10 +02:00
2019-04-23 16:13:39 +02:00
2019-02-11 09:25:25 +01:00
2018-11-28 23:54:03 +01:00
2018-11-21 00:01:44 +02:00
2018-11-21 00:01:44 +02:00
2018-11-21 00:01:44 +02:00
2018-11-21 00:01:44 +02:00
2018-12-12 16:49:01 +08:00

Scylla

Quick-start

$ git submodule update --init --recursive
$ sudo ./install-dependencies.sh
$ ./configure.py --mode=release
$ ninja-build -j4 # Assuming 4 system threads.
$ ./build/release/scylla
$ # Rejoice!

Please see HACKING.md for detailed information on building and developing Scylla.

Note: GCC >= 8.1.1 is require to compile Scylla.

Note: See frozen toolchain for a way to build and run on an older distribution.

Running Scylla

  • Run Scylla
./build/release/scylla

  • run Scylla with one CPU and ./tmp as data directory
./build/release/scylla --datadir tmp --commitlog-directory tmp --smp 1
  • For more run options:
./build/release/scylla --help

Building Fedora RPM

As a pre-requisite, you need to install Mock on your machine:

# Install mock:
sudo yum install mock

# Add user to the "mock" group:
usermod -a -G mock $USER && newgrp mock

Then, to build an RPM, run:

./dist/redhat/build_rpm.sh

The built RPM is stored in /var/lib/mock/<configuration>/result directory. For example, on Fedora 21 mock reports the following:

INFO: Done(scylla-server-0.00-1.fc21.src.rpm) Config(default) 20 minutes 7 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-21-x86_64/result

Building Fedora-based Docker image

Build a Docker image with:

cd dist/docker
docker build -t <image-name> .

Run the image with:

docker run -p $(hostname -i):9042:9042 -i -t <image name>

Contributing to Scylla

Guidelines for contributing

Description
No description provided
Readme 271 MiB
Languages
C++ 72.7%
Python 26.1%
CMake 0.3%
GAP 0.3%
Shell 0.3%