Skip to content

Latest commit

 

History

History
85 lines (54 loc) · 2.51 KB

2.0.4.rst

File metadata and controls

85 lines (54 loc) · 2.51 KB
Raw

Version 2.0.4

Released on 2017/07/06.

Note

If you are upgrading a cluster, you must be running CrateDB :ref:`version_1.1.3` or higher before you upgrade to 2.0.4.

If you want to perform a rolling upgrade, your current CrateDB version number must be :ref:`version_2.0.0`. If you want to upgrade from a version prior to this, the upgrade will introduce all of the breaking changes listed for :ref:`version_2.0.0`, and will require a full restart upgrade.

Consult the upgrade notes for :ref:`Version 2.0.0 <version_2.0.0_upgrade_notes>` when upgrading.

Warning

If you're using CrateDB's BLOB storage you should consult the Upgrade Notes.

Before upgrading, you should back up your data.

Table of contents

Upgrade Notes

Due to a bug introduced in :ref:`version_2.0.0` that can cause loss of BLOB data, it is necessary to perform a rolling upgrade if you're running a version greater than or equal to 2.0.0 and using BLOB tables.

Additionally, the number of replicas needs to be set to at least 1 for all blob tables and you need to make sure that data is fully replicated before continuing.

Only then you may upgrade one node after each other.

Changelog

Changes

  • The recovery_after_time node check now fails if it would prevent the gateway.expected_nodes setting from having any effect.

Fixes

  • Fixed SELECT settings['gateway']['recover_after_time'] FROM sys.cluster so it returns the correct value.

  • Fixed an issue that caused blob data to be deleted upon node shutdown.

  • Fix thread-safety issue for :ref:`scalar functions <scalar-functions>` md5 and sha1.

  • information.schema.tables now returns the default routing hash function if none is present in the table metadata.

  • Fixed an issue that caused an exception to be thrown when using COUNT(*) with :ref:`subselects <gloss-subquery>` that return one row, e.g.:

    SELECT count(*) FROM t1 WHERE id > (SELECT max(col1) FROM t2)

  • Throw proper exception when using the _raw column inside the where clause instead of silently ignoring it.