Skip to content
Snippets Groups Projects
user avatar
Vladimir Davydov authored
Space truncation that we have now is not atomic: we recreate all indexes
of the truncated space one by one. This can result in nasty failures if
a tuple insertion races with the space truncation and sees some indexes
truncated and others not.

This patch redesigns space truncation as follows:

 - Truncate is now triggered by bumping a counter in a new system space
   called _truncate. As before, space truncation is implemented by
   recreating all of its indexes, but now this is done internally in one
   go, inside the space alter trigger. This makes the operation atomic.

 - New indexes are created with Handler::createIndex method, old indexes
   are deleted with Index::~Index. Neither Index::commitCreate nor
   Index::commitDrop are called in case of truncation, in contrast to
   space alter. Since memtx needs to release tuples referenced by old
   indexes, and vinyl needs to log space truncation in the metadata log,
   new Handler methods are introduced, prepareTruncateSpace and
   commitTruncateSpace, which are passed the old and new spaces. They
   are called before and after truncate record is written to WAL,
   respectively.

 - Since Handler::commitTruncateSpace must not fail while vylog write
   obviously may, we reuse the technique used by commitCreate and
   commitDrop methods of VinylIndex, namely leave the record we failed
   to write in vylog buffer to be either flushed along with the next
   write or replayed on WAL recovery. To be able to detect if truncation
   was logged while recovering WAL, we introduce a new vylog record
   type, VY_LOG_TRUNCATE_INDEX which takes truncate_count as a key: if
   on WAL recovery index truncate_count happens to be <= space
   truncate_count, then it it means that truncation was not logged and
   we need to log it again.

Closes #618
Closes #2060
353bcdc5
History

Tarantool

Build Status Code Coverage Telegram Slack Gitter Google Groups

http://tarantool.org

Tarantool is an in-memory database and application server.

Key features of the application server:

  • 100% compatible drop-in replacement for Lua 5.1, based on LuaJIT 2.1. Simply use #!/usr/bin/tarantool instead of #!/usr/bin/lua in your script.
  • full support for Lua modules and a rich set of own modules, including cooperative multitasking, non-blocking I/O, access to external databases, etc

Key features of the database:

  • MsgPack data format and MsgPack based client-server protocol
  • two data engines: 100% in-memory with optional persistence and a 2-level disk-based B-tree, to use with large data sets
  • multiple index types: HASH, TREE, RTREE, BITSET
  • asynchronous master-master replication
  • authentication and access control
  • the database is just a C extension to the app server and can be turned off

Supported platforms are Linux/x86 and FreeBSD/x86, Mac OS X.

Tarantool is ideal for data-enriched components of scalable Web architecture: queue servers, caches, stateful Web applications.

To download and install Tarantool as a binary package for your OS, please visit https://tarantool.org/download.html.

To build Tarantool from source, see detailed instructions in the Tarantool documentation at https://tarantool.org/doc/dev_guide/building_from_source.html.

Please report bugs at http://github.com/tarantool/tarantool/issues We also warmly welcome your feedback in the discussion mailing list, tarantool@googlegroups.com.

Thank you for your interest in Tarantool!