[RELEASE] Scylla 1.7 RC2

[Tzach Livyatan]

The Scylla team is pleased to announce the release of Scylla 1.7 RC2, the second Release Candidate toward Scylla 1.7

The following issues were fixed since 1.7 RC1:

* Scylla Docker image: Prometheus port is now open by default #1827

* Scylla (and Cassandra) golang driver, gocql,  may crash when Probabilistic Tracing or Slow Query Log are enabled #2179

* Commitlog replay, after a Scylla restart, can fail with std::out_of_range  #2173

* scylla_setup: discarding blocks on large RAID volume takes much time with no feedback to the user #1896

* nodetool cfhistograms missing information #2155

More on Scylla 1.7 and download link below

Regards

Tzach

[1]  https://github.com/gocql/gocql

On Wed, Mar 22, 2017 at 1:52 PM, Tzach Livyatan <tz...@scylladb.com> wrote:

The Scylla team is pleased to announce the release of Scylla 1.7 RC1, the first Release Candidate toward  Scylla 1.7 

From now on only critical bugs, if any, will be fixed in branch-1.7. We will continue to fix bugs and add features on the master branch.

Scylla is an open source, Apache-Cassandra-compatible NoSQL database, with superior performance and consistently low latency. Find Scylla 1.7 repository for your Linux distro here. Use with caution; RC1 is not officially production-ready yet. Help us stabilize 1.7 by reporting bugs here. Please note only the last two minor releases of the Scylla open source project are supported. Once 1.7 is out, 1.5 and earlier versions will not be supported, and there will be no maintenance release for them.

Related Links     

* Get started with Scylla 1.7 

* Upgrade from 1.6.x to 1.7.y

* Report a problem

New features in Scylla 1.7

* Counters (Experimental) - Scylla now supports Counter as a native type. A counter column is a column whose value is a 64-bit signed integer and on which two operations are supported: incrementing and decrementing. More about Counters in CQL here[1]. Counter support is complete but will stay experimental till more testing and performance improvements.

To enable Counters add "experimental: true"

to scylla.yaml

* Java tools provided with Scylla[2] are upgraded to match Cassandra 3.0. In particular: 

  - sstableloader support Cassandra 3.0 sstable format, allowing easy migration from Cassandra 2.2 and 3.x clusters to Scylla

  - sstable2json was renamed to sstabledump

  - json2sstable,sstablekeys and token-generator were removed 

* CQL: Update to 3.3.1, to match Cassandra 2.2 release. The changes to CQL 3.3.1 are listed here [3]. More detailed compatibility matrix between Scylla 1.7 and Cassandra 2.2[5] and a list of gaps[4]

   More CQL updates:

* New data types: tiny int, smallint, date, and time  #1284

* Binary protocol v4 (required by the new data types).

* Support UNSET in prepared statements #2039

* Advertise Cassandra 2.2.8 version from Scylla so that drivers correctly detect the presence of CQL 3.3.1

* CQL aggregate functions don't support floating point data types #2168

* Debian Support. Experimental in 1.6, it is now ready for production.

* Scylla 1.7 new intra-node sharding algorithm improves performance on large clusters.  See below for description and impact.

* Improve performance by setting Linux scaling governor to "performance" (it is "powersave" on some Linux distros) #1895

System impacts - read carefully

* New intra-node sharding algorithm

The intra-node sharding algorithm determines how data is divided among cores in a node.  The change results in a better distribution of data among cores, especially in large clusters.  This improves performance across the cluster. By default, the new resharding algorithm is only applied to new clusters; upgraded installations continue to use the older algorithm. 

If you have a large cluster and suffer from uneven distribution of load across shards, you may want to switch to the new algorithm. To update an existing cluster (upgraded from 1.6) you should add the following to scylla.yaml

murmur3_partitioner_ignore_msb_bits: 12

and restart the scylla-server service.  Note, however, that after this the node will re-write all of the data according to the new format; this may temporarily use additional disk space and may impact performance and latency.

* Fix of #2046 (Memtables flushed too early on many-core machines) will increase disk usage by up to the amount of memory installed on the system. For example, If you have 128 GB RAM, commitlog will now occupy up to 128 GB of disk space. If your system storage is close to exhaustion, make sure to free some of it before the upgrade, or increase the amount of available storage.  Alternatively, set the commitlog_total_space_in_mb to an amount that will leave the system enough free space.

Noteworthy new and updated metrics in Scylla 1.7

There are many changes to metrics names between 1.6 to 1.7. For the full list see https://github.com/scylladb/scylla/wiki/Metrics-migration-1.6-to-1.7

If you are using scylla-grafana-monitoring, make sure to pull the latest release, and use 1.7 dashboards.

Noteworthy Bug fixes

* node_exporter, a Prometheus client reporting server metrics run as root #1968

* Writes to system keyspace tables are bypassing commitlog #1986

* Intentional short reads causing slowdown on sparsely populated tables #1995

* Wrong warning on low memory condition #2002

* System table "schema_columnfamilies"  "comparator" column value incompatible with Cassandra #2019

* Installation on clean debian8 produce errors for missing lspci #2035

* Adding a new node with authentication set - causes system_auth keyspace RF to become 1 for the entire cluster. With RF=1, a node down might mean no access to the cluster #2129

* streaming might fail when using compressed files, generating the following error message:

stream_transfer_task: Fail to send to ....: std::out_of_range (deque::_M_range_check: __n (which is 64)>= this->size() (which is 64)) #2143

* scanning and flush memtable may cause bad_alloc even if there is enough memory #2138

* Error during sstable flush may cause Scylla to exit #2122, #2121

* Using Node-to-node SSL gave the wrong logs message. It have been updated to  "Starting Encrypted Messaging Service on SSL port..." #1845

* Scylla may exit during repair process #2148

* scylla_setup: setting DISCARD RAID0 is broken on CentOS #2033

* Scylla housekeeping check for new version on restarts #1953

* Memtables were flushed too early on many-core machines, resulting in small sstables and high compaction load #2046 (see above for impact on disk space)

* Improved seastar performance on very large machines by reducing lock contention in the kernel during signal delivery

* Scylla generated std::bad_alloc error when running commitlog replay (after unexpected restart)  #2098

Known issues

Scylla AMI does not boot on c3.large (its does on other c3 instance types) #2186

sstablesplit generates 3.x sstables which are unreadable by Scylla  tools #23

[1] http://cassandra.apache.org/doc/latest/cql/types.html#native-types

[2] https://github.com/scylladb/scylla-tools-java

[3] https://github.com/apache/cassandra/blob/cassandra-2.2/doc/cql3/CQL.textile#changes

[4] https://github.com/scylladb/scylla/issues?q=is%3Aopen+is%3Aissue+label%3A%22cassandra+2.2+compatability%22

[5] http://docs.scylladb.com/cassandra-compatibility/

[Mani Gandham]

Questions;

1) Will 1.7 support microsecond resolution for timestamps?

2) To upgrade the intra-node sharding - what does "cluster" mean in this case? A entirely new ring or just a new dc/rack setting? Would adding new 1.7 nodes, decommissioning all 1.6 nodes, then changing the setting and restarting each node 1 by 1 work for upgrading an individual dc/rack? 

[Avi Kivity]

Hi, answers inline.

On 04/10/2017 04:28 AM, Mani Gandham wrote:

Questions;

1) Will 1.7 support microsecond resolution for timestamps?

I think earlier versions do too.  Tomek, doesn't 179b587d switch get_timestamp() to microsecond resolution?

Regardless, this only takes effect if you don't use client-side timestamps, which are recommended and I believe the default for the Java driver.

2) To upgrade the intra-node sharding - what does "cluster" mean in this case? A entirely new ring or just a new dc/rack setting? Would adding new 1.7 nodes, decommissioning all 1.6 nodes, then changing the setting and restarting each node 1 by 1 work for upgrading an individual dc/rack?

The configuration is per-node.  So a new cluster, a new data center, a new node added to an existing data center can and should start with the new configuration.  The only problem is with an existing node that has a large amount of data.

1.8 will allow upgrading a node in place, so unless you're really suffering from unbalanced shards, I recommend waiting for that version.

--
You received this message because you are subscribed to the Google Groups "ScyllaDB users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scylladb-user...@googlegroups.com.
To post to this group, send email to scyllad...@googlegroups.com.
Visit this group at https://groups.google.com/group/scylladb-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/scylladb-users/718ad484-601c-466a-953b-5702400f630b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tomasz Grabiec]

On Mon, Apr 10, 2017 at 9:07 AM, Avi Kivity <a...@scylladb.com> wrote:

Hi, answers inline.

On 04/10/2017 04:28 AM, Mani Gandham wrote:

Questions;

1) Will 1.7 support microsecond resolution for timestamps?

I think earlier versions do too.  Tomek, doesn't 179b587d switch get_timestamp() to microsecond resolution?

That commit is just a cleanup, did you mean d87d50dc64, that one was introduced in 1.7 .

 

Regardless, this only takes effect if you don't use client-side timestamps, which are recommended and I believe the default for the Java driver.

Right. 

Thought I recall that the Java driver switched from using millisecond to microsecond precision timestamps at some point. Still, that's independent of Scylla server version.

[Mani Gandham]

Got it, thank you.

[Avi Kivity]

On 04/10/2017 02:49 PM, Tomasz Grabiec wrote:

On Mon, Apr 10, 2017 at 9:07 AM, Avi Kivity <a...@scylladb.com> wrote:

Hi, answers inline.

On 04/10/2017 04:28 AM, Mani Gandham wrote:

Questions;

1) Will 1.7 support microsecond resolution for timestamps?

I think earlier versions do too.  Tomek, doesn't 179b587d switch get_timestamp() to microsecond resolution?

That commit is just a cleanup, did you mean d87d50dc64, that one was introduced in 1.7 .

Thanks for the correction, it did feel wrong to me and I remembered that there was some commit with the explicit change, but couldn't find it.