Merge remote-tracking branch 'upstream/release-5.1' into javadocs-warnings-fix
This commit is contained in:
Alec Grieser
commit
96a27fe626
8
Makefile
8
Makefile
|
|
@ -180,13 +180,13 @@ docpreview: javadoc godoc
|
|||
docpreview_clean:
|
||||
CLEAN_TARGETS= $(MAKE) -C documentation docpreview_clean
|
||||
|
||||
packages/foundationdb-docs-$(VERSION)-SNAPSHOT.tar.gz: FORCE javadoc godoc
|
||||
packages/foundationdb-docs-$(VERSION).tar.gz: FORCE javadoc godoc
|
||||
TARGETS= $(MAKE) -C documentation docpackage
|
||||
@mkdir -p packages
|
||||
@rm -f packages/foundationdb-docs-SNAPSHOT.tar.gz
|
||||
@cp documentation/sphinx/.dist/foundationdb-docs-$(VERSION)-SNAPSHOT.tar.gz packages/foundationdb-docs-$(VERSION)-SNAPSHOT.tar.gz
|
||||
@rm -f packages/foundationdb-docs-$(VERSION).tar.gz
|
||||
@cp documentation/sphinx/.dist/foundationdb-docs-$(VERSION).tar.gz packages/foundationdb-docs-$(VERSION).tar.gz
|
||||
|
||||
docpackage: packages/foundationdb-docs-$(VERSION)-SNAPSHOT.tar.gz
|
||||
docpackage: packages/foundationdb-docs-$(VERSION).tar.gz
|
||||
|
||||
FORCE:
|
||||
|
||||
|
|
|
|||
|
|
@ -340,9 +340,9 @@ class DirectoryTest(Test):
|
|||
# errors += directory_util.check_for_duplicate_prefixes(db, self.prefix_log)
|
||||
return errors
|
||||
|
||||
def get_result_specfications(self):
|
||||
def get_result_specifications(self):
|
||||
return [
|
||||
ResultSpecification(self.stack, key_start_index=1, ordering_index=1),
|
||||
ResultSpecification(self.stack_subspace, key_start_index=1, ordering_index=1),
|
||||
ResultSpecification(self.directory_log, ordering_index=0),
|
||||
ResultSpecification(self.subspace_log, ordering_index=0)
|
||||
]
|
||||
|
|
|
|||
|
|
@ -26,6 +26,8 @@ fdb_c_LIBS := lib/libfdbclient.a lib/libfdbrpc.a lib/libflow.a
|
|||
fdb_c_tests_LIBS := -Llib -lfdb_c
|
||||
fdb_c_tests_HEADERS := -Ibindings/c
|
||||
|
||||
CLEAN_TARGETS += fdb_c_tests_clean
|
||||
|
||||
ifeq ($(PLATFORM),linux)
|
||||
fdb_c_LIBS += lib/libstdc++.a -lm -lpthread -lrt -ldl
|
||||
fdb_c_LDFLAGS += -Wl,--version-script=bindings/c/fdb_c.map -static-libgcc -Wl,-z,nodelete
|
||||
|
|
@ -98,4 +100,7 @@ packages/fdb-c-tests-$(VERSION)-$(PLATFORM).tar.gz: bin/fdb_c_performance_test b
|
|||
|
||||
fdb_c_tests: packages/fdb-c-tests-$(VERSION)-$(PLATFORM).tar.gz
|
||||
|
||||
fdb_c_tests_clean:
|
||||
@rm -f packages/fdb-c-tests-$(VERSION)-$(PLATFORM).tar.gz
|
||||
|
||||
packages: fdb_c_tests
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ GOPATH := $(CURDIR)/bindings/go/build
|
|||
GO_IMPORT_PATH := github.com/apple/foundationdb/bindings/go/src
|
||||
GO_DEST := $(GOPATH)/src/$(GO_IMPORT_PATH)
|
||||
|
||||
.PHONY: fdb_go fdb_go_path fdb_go_tester fdb_go_tester_clean godoc godoc_clean
|
||||
.PHONY: fdb_go fdb_go_path fdb_go_fmt fdb_go_fmt_check fdb_go_tester fdb_go_tester_clean godoc godoc_clean
|
||||
|
||||
# We only override if the environment didn't set it (this is used by
|
||||
# the fdbwebsite documentation build process)
|
||||
|
|
@ -49,7 +49,7 @@ GO_PACKAGE_OBJECTS := $(addprefix $(GO_PACKAGE_OUTDIR)/,$(GO_PACKAGES:=.a))
|
|||
|
||||
GO_SRC := $(shell find $(CURDIR)/bindings/go/src -name '*.go')
|
||||
|
||||
fdb_go: $(GO_PACKAGE_OBJECTS) $(GO_SRC)
|
||||
fdb_go: $(GO_PACKAGE_OBJECTS) $(GO_SRC) fdb_go_fmt_check
|
||||
|
||||
fdb_go_fmt: $(GO_SRC)
|
||||
@echo "Formatting fdb_go"
|
||||
|
|
@ -59,10 +59,13 @@ fdb_go_fmt_check: $(GO_SRC)
|
|||
@echo "Checking fdb_go"
|
||||
@bash -c 'fmtoutstr=$$(gofmt -l $(GO_SRC)) ; if [[ -n "$${fmtoutstr}" ]] ; then echo "Detected go formatting violations for the following files:" ; echo "$${fmtoutstr}" ; echo "Try running: make fdb_go_fmt"; exit 1 ; fi'
|
||||
|
||||
fdb_go_path: $(GO_SRC)
|
||||
$(GO_DEST)/.stamp: $(GO_SRC)
|
||||
@echo "Creating fdb_go_path"
|
||||
@mkdir -p $(GO_DEST)
|
||||
@cp -r bindings/go/src/* $(GO_DEST)
|
||||
@touch $(GO_DEST)/.stamp
|
||||
|
||||
fdb_go_path: $(GO_DEST)/.stamp
|
||||
|
||||
fdb_go_clean:
|
||||
@echo "Cleaning fdb_go"
|
||||
|
|
@ -74,31 +77,31 @@ fdb_go_tester_clean:
|
|||
@echo "Cleaning fdb_go_tester"
|
||||
@rm -rf $(GOPATH)/bin
|
||||
|
||||
$(GOPATH)/bin/_stacktester: fdb_go_path fdb_go_fmt_check $(GO_SRC) $(GO_PACKAGE_OBJECTS) $(GO_DEST)/fdb/generated.go
|
||||
$(GOPATH)/bin/_stacktester: $(GO_DEST)/.stamp $(GO_SRC) $(GO_PACKAGE_OBJECTS) $(GO_DEST)/fdb/generated.go
|
||||
@echo "Compiling $(basename $(notdir $@))"
|
||||
@go install $(GO_IMPORT_PATH)/_stacktester
|
||||
|
||||
$(GO_PACKAGE_OUTDIR)/fdb/tuple.a: fdb_go_path fdb_go_fmt_check $(GO_SRC) $(GO_PACKAGE_OUTDIR)/fdb.a $(GO_DEST)/fdb/generated.go
|
||||
$(GO_PACKAGE_OUTDIR)/fdb/tuple.a: $(GO_DEST)/.stamp $(GO_SRC) $(GO_PACKAGE_OUTDIR)/fdb.a $(GO_DEST)/fdb/generated.go
|
||||
@echo "Compiling fdb/tuple"
|
||||
@go install $(GO_IMPORT_PATH)/fdb/tuple
|
||||
|
||||
$(GO_PACKAGE_OUTDIR)/fdb/subspace.a: fdb_go_path fdb_go_fmt_check $(GO_SRC) $(GO_PACKAGE_OUTDIR)/fdb.a $(GO_PACKAGE_OUTDIR)/fdb/tuple.a $(GO_DEST)/fdb/generated.go
|
||||
$(GO_PACKAGE_OUTDIR)/fdb/subspace.a: $(GO_DEST)/.stamp $(GO_SRC) $(GO_PACKAGE_OUTDIR)/fdb.a $(GO_PACKAGE_OUTDIR)/fdb/tuple.a $(GO_DEST)/fdb/generated.go
|
||||
@echo "Compiling fdb/subspace"
|
||||
@go install $(GO_IMPORT_PATH)/fdb/subspace
|
||||
|
||||
$(GO_PACKAGE_OUTDIR)/fdb/directory.a: fdb_go_path fdb_go_fmt_check $(GO_SRC) $(GO_PACKAGE_OUTDIR)/fdb.a $(GO_PACKAGE_OUTDIR)/fdb/tuple.a $(GO_PACKAGE_OUTDIR)/fdb/subspace.a $(GO_DEST)/fdb/generated.go
|
||||
$(GO_PACKAGE_OUTDIR)/fdb/directory.a: $(GO_DEST)/.stamp $(GO_SRC) $(GO_PACKAGE_OUTDIR)/fdb.a $(GO_PACKAGE_OUTDIR)/fdb/tuple.a $(GO_PACKAGE_OUTDIR)/fdb/subspace.a $(GO_DEST)/fdb/generated.go
|
||||
@echo "Compiling fdb/directory"
|
||||
@go install $(GO_IMPORT_PATH)/fdb/directory
|
||||
|
||||
$(GO_PACKAGE_OUTDIR)/fdb.a: fdb_go_path fdb_go_fmt_check $(GO_SRC) $(GO_DEST)/fdb/generated.go
|
||||
$(GO_PACKAGE_OUTDIR)/fdb.a: $(GO_DEST)/.stamp lib/libfdb_c.$(DLEXT) $(GO_SRC) $(GO_DEST)/fdb/generated.go
|
||||
@echo "Compiling fdb"
|
||||
@go install $(GO_IMPORT_PATH)/fdb
|
||||
|
||||
$(GO_DEST)/fdb/generated.go: fdb_go_path fdb_go_fmt_check lib/libfdb_c.$(DLEXT) bindings/go/src/_util/translate_fdb_options.go fdbclient/vexillographer/fdb.options
|
||||
$(GO_DEST)/fdb/generated.go: $(GO_DEST)/.stamp bindings/go/src/_util/translate_fdb_options.go fdbclient/vexillographer/fdb.options
|
||||
@echo "Building $@"
|
||||
@go run bindings/go/src/_util/translate_fdb_options.go < fdbclient/vexillographer/fdb.options > $@
|
||||
|
||||
godoc: fdb_go_path $(GO_SRC)
|
||||
godoc: fdb_go_path $(GO_SRC) $(GO_DEST)/fdb/generated.go
|
||||
@echo "Generating Go Documentation"
|
||||
@rm -rf $(GODOC_DIR)/godoc
|
||||
@mkdir -p $(GODOC_DIR)/godoc
|
||||
|
|
|
|||
|
|
@ -38,13 +38,14 @@ else
|
|||
endif
|
||||
|
||||
ifeq ($(PLATFORM),linux)
|
||||
fdb_java_CFLAGS += -I/usr/lib/jvm/java-8-openjdk-amd64/include -I/usr/lib/jvm/java-8-openjdk-amd64/include/linux
|
||||
JAVA_HOME ?= /usr/lib/jvm/java-8-openjdk-amd64
|
||||
fdb_java_CFLAGS += -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux
|
||||
fdb_java_LDFLAGS += -static-libgcc
|
||||
|
||||
java_ARCH := amd64
|
||||
else ifeq ($(PLATFORM),osx)
|
||||
# FIXME: Surely there is a better way to grab the JNI headers on any version of macOS.
|
||||
fdb_java_CFLAGS += -I/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers
|
||||
JAVA_HOME ?= $(shell /usr/libexec/java_home)
|
||||
fdb_java_CFLAGS += -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/darwin
|
||||
|
||||
java_ARCH := x86_64
|
||||
endif
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ public interface Database extends AutoCloseable, TransactionContext {
|
|||
* be unable to determine whether a transaction succeeded. In these cases, your
|
||||
* transaction may be executed twice. For more information about how to reason
|
||||
* about these situations see
|
||||
* <a href="/foundationdb/developer-guide.html#transactions-with-unknown-results"
|
||||
* <a href="/developer-guide.html#transactions-with-unknown-results"
|
||||
* target="_blank">the FounationDB Developer Guide</a>
|
||||
*
|
||||
* @param retryable the block of logic to execute in a {@link Transaction} against
|
||||
|
|
@ -202,7 +202,7 @@ public interface Database extends AutoCloseable, TransactionContext {
|
|||
* be unable to determine whether a transaction succeeded. In these cases, your
|
||||
* transaction may be executed twice. For more information about how to reason
|
||||
* about these situations see
|
||||
* <a href="/foundationdb/developer-guide.html#transactions-with-unknown-results"
|
||||
* <a href="/developer-guide.html#transactions-with-unknown-results"
|
||||
* target="_blank">the FounationDB Developer Guide</a><br>
|
||||
* <br>
|
||||
* Any errors encountered executing {@code retryable}, or received from the
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ import com.apple.foundationdb.tuple.ByteArrayUtil;
|
|||
* {@link Transaction#getRange(KeySelector, KeySelector) getRange()}.<br>
|
||||
* <br>
|
||||
* For more about how key selectors work in practice, see
|
||||
* <a href="/foundationdb/developer-guide.html#key-selectors" target="_blank">the KeySelector documentation</a>.
|
||||
* <a href="/developer-guide.html#key-selectors" target="_blank">the KeySelector documentation</a>.
|
||||
* Note that the way the key selectors are resolved is somewhat non-intuitive, so
|
||||
* users who wish to use a key selector other than the default ones described below should
|
||||
* probably consult that documentation before proceeding.
|
||||
|
|
@ -134,7 +134,7 @@ public class KeySelector {
|
|||
* poor choice for iterating through a large range. (Instead, use the keys
|
||||
* returned from a range query operation
|
||||
* themselves to create a new beginning {@code KeySelector}.) For more information see
|
||||
* <a href="/foundationdb/developer-guide.html#key-selectors" target="_blank">the KeySelector documentation</a>.
|
||||
* <a href="/developer-guide.html#key-selectors" target="_blank">the KeySelector documentation</a>.
|
||||
*
|
||||
* @param offset the number of keys to offset the {@code KeySelector}. This number can be
|
||||
* negative.
|
||||
|
|
|
|||
|
|
@ -34,12 +34,12 @@ import com.apple.foundationdb.tuple.Tuple;
|
|||
* the underlying database if and when the transaction is committed. Read operations do see the
|
||||
* effects of previous write operations on the same transaction. Committing a transaction usually
|
||||
* succeeds in the absence of
|
||||
* <a href="/foundationdb/developer-guide.html#transaction-conflicts" target="_blank">conflicts</a>.<br>
|
||||
* <a href="/developer-guide.html#developer-guide-transaction-conflicts" target="_blank">conflicts</a>.<br>
|
||||
* <br>
|
||||
* Transactions group operations into a unit with the properties of atomicity, isolation, and
|
||||
* durability. Transactions also provide the ability to maintain an application's invariants or
|
||||
* integrity constraints, supporting the property of consistency. Together these properties are
|
||||
* known as <a href="/foundationdb/developer-guide.html#acid" target="_blank">ACID</a>.<br>
|
||||
* known as <a href="/developer-guide.html#acid" target="_blank">ACID</a>.<br>
|
||||
* <br>
|
||||
* Transactions are also causally consistent: once a transaction has been successfully committed,
|
||||
* all subsequently created transactions will see the modifications made by it.
|
||||
|
|
@ -49,7 +49,7 @@ import com.apple.foundationdb.tuple.Tuple;
|
|||
* <br>
|
||||
* Keys and values in FoundationDB are byte arrays. To encode other data types, see the
|
||||
* {@link Tuple Tuple API} and
|
||||
* <a href="/foundationdb/data-modeling.html#tuples" target="_blank">tuple layer documentation</a>.<br>
|
||||
* <a href="/data-modeling.html#data-modeling-tuples" target="_blank">tuple layer documentation</a>.<br>
|
||||
* <br>
|
||||
* When used as a {@link TransactionContext}, the methods {@code run()} and
|
||||
* {@code runAsync()} on a {@code Transaction} will simply attempt the operations
|
||||
|
|
@ -79,11 +79,11 @@ public interface Transaction extends AutoCloseable, ReadTransaction, Transaction
|
|||
/**
|
||||
* Return special-purpose, read-only view of the database. Reads done through this interface are known as "snapshot reads".
|
||||
* Snapshot reads selectively relax FoundationDB's isolation property, reducing
|
||||
* <a href="/foundationdb/developer-guide.html#transaction-conflicts" target="_blank">Transaction conflicts</a>
|
||||
* <a href="/developer-guide.html#transaction-conflicts" target="_blank">Transaction conflicts</a>
|
||||
* but making reasoning about concurrency harder.<br>
|
||||
* <br>
|
||||
* For more information about how to use snapshot reads correctly, see
|
||||
* <a href="/foundationdb/developer-guide.html#using-snapshot-reads" target="_blank">Using snapshot reads</a>.
|
||||
* <a href="/developer-guide.html#using-snapshot-reads" target="_blank">Using snapshot reads</a>.
|
||||
*
|
||||
* @return a read-only view of this {@code Transaction} with relaxed isolation properties
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ import com.apple.foundationdb.tuple.Tuple;
|
|||
* to manage its subspaces.
|
||||
*
|
||||
* For general guidance on directory usage, see the discussion in the
|
||||
* <a href="/foundationdb/developer-guide.html#developer-guide-directories" target="_blank">Developer Guide</a>.
|
||||
* <a href="/developer-guide.html#developer-guide-directories" target="_blank">Developer Guide</a>.
|
||||
* </p>
|
||||
* <p>
|
||||
* Directories are identified by hierarchical paths analogous to the paths
|
||||
|
|
|
|||
|
|
@ -37,8 +37,8 @@ import com.apple.foundationdb.tuple.Tuple;
|
|||
* content.
|
||||
* </p>
|
||||
*
|
||||
* For general guidance on partition usage, see
|
||||
* <a href="/foundationdb/developer-guide.html#directory-partitions" target="_blank">The Developer Guide</a>.
|
||||
* For general guidance on partition usage, see the
|
||||
* <a href="/developer-guide.html#directory-partitions" target="_blank">Developer Guide</a>.
|
||||
*/
|
||||
class DirectoryPartition extends DirectorySubspace {
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@
|
|||
* used for the corresponding subspace. In effect, directories provide
|
||||
* a level of indirection for access to subspaces.<br>
|
||||
* <br>
|
||||
* See <a href="/foundationdb/developer-guide.html#developer-guide-directories">general
|
||||
* See <a href="/developer-guide.html#developer-guide-directories">general
|
||||
* directory documentation</a> for information about how directories work and
|
||||
* interact with other parts of the built-in keyspace management features.
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@
|
|||
* assure that {@link com.apple.foundationdb.Transaction#commit()} has returned successfully
|
||||
* before itself returning. If you are not able to use these functions for some reason
|
||||
* please closely read and understand the other
|
||||
* <a href="/foundationdb/data-modeling.html#tuples">developer
|
||||
* <a href="/data-modeling.html#data-modeling-tuples">developer
|
||||
* documentation on FoundationDB transactions</a>.
|
||||
*/
|
||||
package com.apple.foundationdb;
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ import com.apple.foundationdb.tuple.Versionstamp;
|
|||
*
|
||||
* <p>
|
||||
* For general guidance on subspace usage, see the discussion in
|
||||
* <a href="/foundationdb/developer-guide.html#subspaces-of-keys" target="_blank">Developer Guide</a>.
|
||||
* <a href="/developer-guide.html#developer-guide-sub-keyspaces" target="_blank">Developer Guide</a>.
|
||||
* </p>
|
||||
*
|
||||
* <p>
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@
|
|||
* from the result. As a best practice, API clients should use at least one
|
||||
* subspace for application data.<br>
|
||||
* <br>
|
||||
* See <a href="/foundationdb/developer-guide.html#developer-guide-sub-keyspaces">general
|
||||
* See <a href="/developer-guide.html#developer-guide-sub-keyspaces">general
|
||||
* subspace documentation</a> for information about how subspaces work and
|
||||
* interact with other parts of the built-in keyspace management features.
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@
|
|||
* Provides a set of utilities for serializing and deserializing typed data
|
||||
* for use in FoundationDB. When packed together into a {@link com.apple.foundationdb.tuple.Tuple}
|
||||
* this data is suitable for use as an index or organizational structure within FoundationDB
|
||||
* keyspace. See <a href="/foundationdb/data-modeling.html#tuples">general Tuple
|
||||
* keyspace. See <a href="/data-modeling.html#data-modeling-tuples">general Tuple
|
||||
* documentation</a> for information about how Tuples sort and can be used to efficiently
|
||||
* model data.
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ cross-language support for storing and retrieving typed data from the
|
|||
binary data that FoundationDB supports. And, just as importantly, data packed into
|
||||
{@code Tuple}s and used as keys sort in predictable and useful ways. See the
|
||||
{@link com.apple.foundationdb.tuple Tuple class documentation} for information about use in Java
|
||||
and <a href="/foundationdb/data-modeling.html#tuples">general Tuple documentation</a>
|
||||
and <a href="/data-modeling.html#data-modeling-tuples">general Tuple documentation</a>
|
||||
for information about how Tuples sort and can be used to efficiently model data.
|
||||
<br>
|
||||
<h3>FoundationDB {@link com.apple.foundationdb.directory Directory API}</h3>
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ class HighContentionAllocator (object):
|
|||
count = tr.snapshot[self.counters[start]]
|
||||
|
||||
if count != None:
|
||||
count = struct.unpack("<q", str(count))[0]
|
||||
count = struct.unpack("<q", bytes(count))[0]
|
||||
else:
|
||||
count = 0
|
||||
|
||||
|
|
|
|||
|
|
@ -147,10 +147,8 @@ info:
|
|||
@echo "Package: $(PACKAGE_NAME)"
|
||||
@echo "Version ID: $(VERSION_ID)"
|
||||
@echo "Package ID: $(PKGRELEASE)"
|
||||
@echo "Source Control: $(SOURCE_CONTROL)"
|
||||
@echo "SC Branch: $(SCBRANCH)"
|
||||
@echo "Git Dir: $(GITPRESENT)"
|
||||
@echo "Mercurial Dir: $(HGPRESENT)"
|
||||
@echo "Make Dir: $(MAKEDIR)"
|
||||
@echo "Foundation Dir: $(FDBDIR)"
|
||||
@echo "Fdb Dir Base: $(FDBDIRBASE)"
|
||||
|
|
|
|||
|
|
@ -2,20 +2,12 @@
|
|||
#
|
||||
# local vars:
|
||||
PROJECT_NAME := foundationdb-docs
|
||||
#VERSION := $(shell cat version)
|
||||
|
||||
ifeq ($(RELEASE_BUILD),true)
|
||||
RELEASE := $(VERSION)
|
||||
else
|
||||
RELEASE := $(VERSION)-SNAPSHOT
|
||||
endif
|
||||
|
||||
GIT_HEAD_REF := $(shell git rev-parse --short HEAD)
|
||||
GIT_BRANCH := $(shell git symbolic-ref --short HEAD)
|
||||
GIT_REPO_URL := $(shell git config --get remote.origin.url)
|
||||
|
||||
# You can set these variables from the command line.
|
||||
#VERSIONOPTS := -D version=$(VERSION) -D release=$(RELEASE)
|
||||
SPHINXOPTS := -c .
|
||||
PAPER =
|
||||
ROOTDIR := $(CURDIR)
|
||||
|
|
@ -110,4 +102,5 @@ livehtml: html
|
|||
# removed html prerequisite because it is previously explictly invoked
|
||||
package:
|
||||
mkdir -p $(DISTDIR)
|
||||
cd $(BUILDDIR)/html && tar czf $(DISTDIR)/$(PROJECT_NAME)-$(RELEASE).tar.gz .
|
||||
rm -f $(DISTDIR)/$(PROJECT_NAME)-$(VERSION).tar.gz
|
||||
cd $(BUILDDIR)/html && tar czf $(DISTDIR)/$(PROJECT_NAME)-$(VERSION).tar.gz .
|
||||
|
|
|
|||
|
|
@ -134,7 +134,6 @@ html_title = 'FoundationDB ' + version
|
|||
|
||||
# The name of an image file (relative to this directory) to place at the top
|
||||
# of the sidebar.
|
||||
html_logo = sys.prefix + '/_static/logo.svg'
|
||||
|
||||
# The name of an image file (within the static path) to use as favicon of the
|
||||
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
|
||||
|
|
|
|||
|
|
@ -223,44 +223,46 @@ Use the ``status`` command of ``fdbcli`` to determine if the cluster is up and r
|
|||
The database is available.
|
||||
|
||||
Welcome to the fdbcli. For help, type `help'.
|
||||
fdb> status
|
||||
fdb> status
|
||||
|
||||
The ``status`` command displays general information about the FoundationDB cluster::
|
||||
Configuration:
|
||||
Redundancy mode - triple
|
||||
Storage engine - ssd-2
|
||||
Coordinators - 5
|
||||
Desired Proxies - 5
|
||||
Desired Logs - 8
|
||||
|
||||
Configuration:
|
||||
Redundancy mode - triple
|
||||
Storage engine - ssd
|
||||
Coordinators - 3
|
||||
Cluster:
|
||||
FoundationDB processes - 272
|
||||
Machines - 16
|
||||
Memory availability - 14.5 GB per process on machine with least available
|
||||
Retransmissions rate - 20 Hz
|
||||
Fault Tolerance - 2 machines
|
||||
Server time - 03/19/18 08:51:52
|
||||
|
||||
Cluster:
|
||||
FoundationDB processes - 3
|
||||
Machines - 3
|
||||
Memory availability - 4.1 GB per process on machine with least available
|
||||
Fault Tolerance - 0 machines
|
||||
Server time - Thu Mar 15 14:41:34 2018
|
||||
Data:
|
||||
Replication health - Healthy
|
||||
Moving data - 0.000 GB
|
||||
Sum of key-value sizes - 3.298 TB
|
||||
Disk space used - 15.243 TB
|
||||
|
||||
Data:
|
||||
Replication health - Healthy
|
||||
Moving data - 0.000 GB
|
||||
Sum of key-value sizes - 8 MB
|
||||
Disk space used - 103 MB
|
||||
Operating space:
|
||||
Storage server - 1656.2 GB free on most full server
|
||||
Log server - 1794.7 GB free on most full server
|
||||
|
||||
Operating space:
|
||||
Storage server - 1.0 GB free on most full server
|
||||
Log server - 1.0 GB free on most full server
|
||||
Workload:
|
||||
Read rate - 55990 Hz
|
||||
Write rate - 14946 Hz
|
||||
Transactions started - 6321 Hz
|
||||
Transactions committed - 1132 Hz
|
||||
Conflict rate - 0 Hz
|
||||
|
||||
Workload:
|
||||
Read rate - 2 Hz
|
||||
Write rate - 0 Hz
|
||||
Transactions started - 2 Hz
|
||||
Transactions committed - 0 Hz
|
||||
Conflict rate - 0 Hz
|
||||
Backup and DR:
|
||||
Running backups - 1
|
||||
Running DRs - 1 as primary
|
||||
|
||||
Backup and DR:
|
||||
Running backups - 0
|
||||
Running DRs - 0
|
||||
|
||||
Client time: Thu Mar 15 14:41:34 2018
|
||||
Client time: 03/19/18 08:51:51
|
||||
|
||||
|
||||
The summary fields are interpreted as follows:
|
||||
|
||||
|
|
@ -268,15 +270,18 @@ The summary fields are interpreted as follows:
|
|||
Redundancy mode The currently configured redundancy mode (see the section :ref:`configuration-choosing-redundancy-mode`)
|
||||
Storage engine The currently configured storage engine (see the section :ref:`configuration-configuring-storage-subsystem`)
|
||||
Coordinators The number of FoundationDB coordination servers
|
||||
Desired Proxies Number of proxies desired. If replication mode is 3 then default number of proxies is 3
|
||||
Desired Logs Number of logs desired. If replication mode is 3 then default number of logs is 3
|
||||
FoundationDB processes Number of FoundationDB processes participating in the cluster
|
||||
Machines Number of physical machines running at least one FoundationDB process that is participating in the cluster
|
||||
Memory availability RAM per process on machine with least available (see details below)
|
||||
Retransmissions rate Ratio of retransmitted packets to the total number of packets.
|
||||
Fault tolerance Maximum number of machines that can fail without losing data or availability (number for losing data will be reported separately if lower)
|
||||
Server time Timestamp from the server
|
||||
Replication health A qualitative estimate of the health of data replication
|
||||
Moving data Amount of data currently in movement between machines
|
||||
Sum of key-value sizes Estimated total size of keys and values stored (not including any overhead or replication)
|
||||
Disk space used Sum of space used across all nodes in the cluster
|
||||
Disk space used Overall disk space used by the cluster
|
||||
Storage server Free space for storage on the server with least available. For ``ssd`` storage engine, includes only disk; for ``memory`` storage engine, includes both RAM and disk.
|
||||
Log server Free space for log server on the server with least available.
|
||||
Read rate The current number of reads per second
|
||||
|
|
@ -316,58 +321,139 @@ The ``status`` command can provide detailed statistics about the cluster and the
|
|||
Welcome to the fdbcli. For help, type `help'.
|
||||
fdb> status details
|
||||
|
||||
Configuration:
|
||||
Redundancy mode - triple
|
||||
Storage engine - ssd
|
||||
Coordinators - 3
|
||||
|
||||
Cluster:
|
||||
FoundationDB processes - 3
|
||||
Machines - 3
|
||||
Memory availability - 4.1 GB per process on machine with least available
|
||||
Fault Tolerance - 0 machines
|
||||
Server time - Thu Mar 15 14:41:34 2018
|
||||
Configuration:
|
||||
Redundancy mode - triple
|
||||
Storage engine - ssd-2
|
||||
Coordinators - 5
|
||||
|
||||
Data:
|
||||
Replication health - Healthy
|
||||
Moving data - 0.000 GB
|
||||
Sum of key-value sizes - 8 MB
|
||||
Disk space used - 103 MB
|
||||
Cluster:
|
||||
FoundationDB processes - 85
|
||||
Machines - 5
|
||||
Memory availability - 7.4 GB per process on machine with least available
|
||||
Retransmissions rate - 5 Hz
|
||||
Fault Tolerance - 2 machines
|
||||
Server time - 03/19/18 08:59:37
|
||||
|
||||
Operating space:
|
||||
Storage server - 1.0 GB free on most full server
|
||||
Log server - 1.0 GB free on most full server
|
||||
Data:
|
||||
Replication health - Healthy
|
||||
Moving data - 0.000 GB
|
||||
Sum of key-value sizes - 87.068 GB
|
||||
Disk space used - 327.819 GB
|
||||
|
||||
Workload:
|
||||
Read rate - 2 Hz
|
||||
Write rate - 0 Hz
|
||||
Transactions started - 2 Hz
|
||||
Transactions committed - 0 Hz
|
||||
Conflict rate - 0 Hz
|
||||
Operating space:
|
||||
Storage server - 888.2 GB free on most full server
|
||||
Log server - 897.3 GB free on most full server
|
||||
|
||||
Backup and DR:
|
||||
Running backups - 0
|
||||
Running DRs - 0
|
||||
Workload:
|
||||
Read rate - 117 Hz
|
||||
Write rate - 0 Hz
|
||||
Transactions started - 43 Hz
|
||||
Transactions committed - 1 Hz
|
||||
Conflict rate - 0 Hz
|
||||
|
||||
Process performance details:
|
||||
10.0.4.1:4500 ( 3% cpu; 2% machine; 0.004 Gbps; 0% disk; 2.5 GB / 4.1 GB RAM )
|
||||
10.0.4.2:4500 ( 1% cpu; 2% machine; 0.004 Gbps; 0% disk; 2.5 GB / 4.1 GB RAM )
|
||||
10.0.4.3:4500 ( 1% cpu; 2% machine; 0.004 Gbps; 0% disk; 2.5 GB / 4.1 GB RAM )
|
||||
Process performance details:
|
||||
10.0.4.1:4500 ( 2% cpu; 2% machine; 0.010 Gbps; 0% disk IO; 3.2 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4501 ( 1% cpu; 2% machine; 0.010 Gbps; 3% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4502 ( 2% cpu; 2% machine; 0.010 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4503 ( 0% cpu; 2% machine; 0.010 Gbps; 0% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4504 ( 0% cpu; 2% machine; 0.010 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4505 ( 2% cpu; 2% machine; 0.010 Gbps; 0% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4506 ( 2% cpu; 2% machine; 0.010 Gbps; 0% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4507 ( 2% cpu; 2% machine; 0.010 Gbps; 0% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4508 ( 2% cpu; 2% machine; 0.010 Gbps; 1% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4509 ( 2% cpu; 2% machine; 0.010 Gbps; 1% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4510 ( 1% cpu; 2% machine; 0.010 Gbps; 1% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4511 ( 0% cpu; 2% machine; 0.010 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4512 ( 0% cpu; 2% machine; 0.010 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4513 ( 0% cpu; 2% machine; 0.010 Gbps; 0% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4514 ( 0% cpu; 2% machine; 0.010 Gbps; 0% disk IO; 0.2 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4515 ( 12% cpu; 2% machine; 0.010 Gbps; 0% disk IO; 0.2 GB / 7.4 GB RAM )
|
||||
10.0.4.1:4516 ( 0% cpu; 2% machine; 0.010 Gbps; 0% disk IO; 0.3 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4500 ( 2% cpu; 3% machine; 0.124 Gbps; 0% disk IO; 3.2 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4501 ( 15% cpu; 3% machine; 0.124 Gbps; 19% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4502 ( 2% cpu; 3% machine; 0.124 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4503 ( 2% cpu; 3% machine; 0.124 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4504 ( 2% cpu; 3% machine; 0.124 Gbps; 1% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4505 ( 18% cpu; 3% machine; 0.124 Gbps; 18% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4506 ( 2% cpu; 3% machine; 0.124 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4507 ( 2% cpu; 3% machine; 0.124 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4508 ( 2% cpu; 3% machine; 0.124 Gbps; 19% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4509 ( 0% cpu; 3% machine; 0.124 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4510 ( 0% cpu; 3% machine; 0.124 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4511 ( 2% cpu; 3% machine; 0.124 Gbps; 1% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4512 ( 2% cpu; 3% machine; 0.124 Gbps; 19% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4513 ( 0% cpu; 3% machine; 0.124 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4514 ( 0% cpu; 3% machine; 0.124 Gbps; 0% disk IO; 0.2 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4515 ( 11% cpu; 3% machine; 0.124 Gbps; 0% disk IO; 0.2 GB / 7.4 GB RAM )
|
||||
10.0.4.2:4516 ( 0% cpu; 3% machine; 0.124 Gbps; 0% disk IO; 0.6 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4500 ( 14% cpu; 3% machine; 0.284 Gbps; 26% disk IO; 3.0 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4501 ( 2% cpu; 3% machine; 0.284 Gbps; 0% disk IO; 2.8 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4502 ( 2% cpu; 3% machine; 0.284 Gbps; 0% disk IO; 2.8 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4503 ( 2% cpu; 3% machine; 0.284 Gbps; 0% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4504 ( 7% cpu; 3% machine; 0.284 Gbps; 12% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4505 ( 2% cpu; 3% machine; 0.284 Gbps; 0% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4506 ( 2% cpu; 3% machine; 0.284 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4507 ( 2% cpu; 3% machine; 0.284 Gbps; 26% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4508 ( 2% cpu; 3% machine; 0.284 Gbps; 0% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4509 ( 2% cpu; 3% machine; 0.284 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4510 ( 2% cpu; 3% machine; 0.284 Gbps; 0% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4511 ( 2% cpu; 3% machine; 0.284 Gbps; 12% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4512 ( 2% cpu; 3% machine; 0.284 Gbps; 3% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4513 ( 2% cpu; 3% machine; 0.284 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4514 ( 0% cpu; 3% machine; 0.284 Gbps; 0% disk IO; 0.1 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4515 ( 0% cpu; 3% machine; 0.284 Gbps; 0% disk IO; 0.1 GB / 7.4 GB RAM )
|
||||
10.0.4.3:4516 ( 0% cpu; 3% machine; 0.284 Gbps; 0% disk IO; 0.1 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4500 ( 2% cpu; 4% machine; 0.065 Gbps; 0% disk IO; 3.2 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4501 ( 2% cpu; 4% machine; 0.065 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4502 ( 0% cpu; 4% machine; 0.065 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4503 ( 2% cpu; 4% machine; 0.065 Gbps; 16% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4504 ( 2% cpu; 4% machine; 0.065 Gbps; 0% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4505 ( 0% cpu; 4% machine; 0.065 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4506 ( 0% cpu; 4% machine; 0.065 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4507 ( 2% cpu; 4% machine; 0.065 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4508 ( 0% cpu; 4% machine; 0.065 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4509 ( 2% cpu; 4% machine; 0.065 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4510 ( 24% cpu; 4% machine; 0.065 Gbps; 15% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4511 ( 2% cpu; 4% machine; 0.065 Gbps; 0% disk IO; 2.8 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4512 ( 2% cpu; 4% machine; 0.065 Gbps; 0% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4513 ( 0% cpu; 4% machine; 0.065 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4514 ( 0% cpu; 4% machine; 0.065 Gbps; 1% disk IO; 0.2 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4515 ( 0% cpu; 4% machine; 0.065 Gbps; 1% disk IO; 0.2 GB / 7.4 GB RAM )
|
||||
10.0.4.4:4516 ( 0% cpu; 4% machine; 0.065 Gbps; 1% disk IO; 0.6 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4500 ( 6% cpu; 2% machine; 0.076 Gbps; 7% disk IO; 3.2 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4501 ( 2% cpu; 2% machine; 0.076 Gbps; 19% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4502 ( 1% cpu; 2% machine; 0.076 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4503 ( 0% cpu; 2% machine; 0.076 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4504 ( 2% cpu; 2% machine; 0.076 Gbps; 0% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4505 ( 2% cpu; 2% machine; 0.076 Gbps; 0% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4506 ( 0% cpu; 2% machine; 0.076 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4507 ( 2% cpu; 2% machine; 0.076 Gbps; 6% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4508 ( 31% cpu; 2% machine; 0.076 Gbps; 8% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4509 ( 0% cpu; 2% machine; 0.076 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4510 ( 2% cpu; 2% machine; 0.076 Gbps; 0% disk IO; 2.7 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4511 ( 2% cpu; 2% machine; 0.076 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4512 ( 2% cpu; 2% machine; 0.076 Gbps; 0% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4513 ( 0% cpu; 2% machine; 0.076 Gbps; 3% disk IO; 2.6 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4514 ( 0% cpu; 2% machine; 0.076 Gbps; 0% disk IO; 0.2 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4515 ( 0% cpu; 2% machine; 0.076 Gbps; 0% disk IO; 0.2 GB / 7.4 GB RAM )
|
||||
10.0.4.5:4516 ( 0% cpu; 2% machine; 0.076 Gbps; 0% disk IO; 0.6 GB / 7.4 GB RAM )
|
||||
|
||||
Coordination servers:
|
||||
10.0.4.1:4500
|
||||
10.0.4.2:4500
|
||||
10.0.4.3:4500
|
||||
|
||||
Client time: Thu Mar 15 14:41:34 2018
|
||||
Coordination servers:
|
||||
10.0.4.1:4500 (reachable)
|
||||
10.0.4.2:4500 (reachable)
|
||||
10.0.4.3:4500 (reachable)
|
||||
10.0.4.4:4500 (reachable)
|
||||
10.0.4.5:4500 (reachable)
|
||||
|
||||
Client time: 03/19/18 08:59:37
|
||||
Several details about individual FoundationDB processes are displayed in a list format in parenthesis after the IP address and port:
|
||||
|
||||
======= =========================================================================
|
||||
cpu CPU utilization of the individual process
|
||||
machine CPU utilization of the machine the process is running on (over all cores)
|
||||
Gbps Total input + output network traffic, in Gbps
|
||||
disk Percentage busy time of the disk subsystem on which the data resides
|
||||
disk IO Percentage busy time of the disk subsystem on which the data resides
|
||||
REXMIT! Displayed only if there have been more than 10 TCP segments retransmitted in last 5s
|
||||
RAM Total physical memory used by process / memory available per process
|
||||
======= =========================================================================
|
||||
|
|
@ -391,6 +477,8 @@ To make configuring, starting, stopping, and restarting ``fdbserver`` processes
|
|||
|
||||
During normal operation, ``fdbmonitor`` is transparent, and you interact with it only by modifying the configuration in :ref:`foundationdb.conf <foundationdb-conf>` and perhaps occasionally by :ref:`starting and stopping <administration-running-foundationdb>` it manually. If some problem prevents an ``fdbserver`` or ``backup-agent`` process from starting or causes it to stop unexpectedly, ``fdbmonitor`` will log errors to the system log.
|
||||
|
||||
If kill_on_configuration_change parameter is unset or set to `true` in foundationdb.conf then fdbmonitor will restart on changes automatically. If this parameter is set to `false` it will not restart on changes.
|
||||
|
||||
.. _administration-managing-trace-files:
|
||||
|
||||
Managing trace files
|
||||
|
|
@ -436,10 +524,12 @@ Using the ``memory`` storage engine, both memory and disk space need to be consi
|
|||
|
||||
* Disk space usage is about 8x the original data size. The memory storage engine interleaves a snapshot on disk with a transaction log, with the resulting snapshot 2x the data size. A snapshot can't be dropped from its log until the next snapshot is completely written, so 2 snapshots must be kept at 4x the data size. The two-file durable queue can't overwrite data in one file until all the data in the other file has been dropped, resulting in 8x the data size. Finally, it should be noted that disk space is not reclaimed when key-value pairs are cleared.
|
||||
|
||||
For either storage engine, there is possible additional overhead when running backup or DR. In usual operation, the overhead is negligible but if backup is unable to write or a secondary cluster is unavailable, mutation logs will build up until copying can resume, occupying space in your cluster.
|
||||
|
||||
Running out of storage space
|
||||
----------------------------
|
||||
|
||||
FoundationDB is aware of the free storage space on each node. It attempts to load all nodes equally so that no node runs out of space before the others. The database attempts to gracefully stop writes as storage space decreases to 100 MB, refusing to start new transactions with priorities other than ``SYSTEM_IMMEDIATE``. This lower bound on free space leaves space to allow you to use ``SYSTEM_IMMEDIATE`` transactions to remove data.
|
||||
FoundationDB is aware of the free storage space on each node. It attempts to distribute data equally on all the nodes so that no node runs out of space before the others. The database attempts to gracefully stop writes as storage space decreases to 100 MB, refusing to start new transactions with priorities other than ``SYSTEM_IMMEDIATE``. This lower bound on free space leaves space to allow you to use ``SYSTEM_IMMEDIATE`` transactions to remove data.
|
||||
|
||||
The measure of free space depends on the storage engine. For the memory storage engine, which is the default after installation, total space is limited to the lesser of the ``storage_memory`` configuration parameter (1 GB in the default configuration) or a fraction of the free disk space.
|
||||
|
||||
|
|
@ -448,14 +538,14 @@ If the disk is rapidly filled by other programs, trace files, etc., FoundationDB
|
|||
Virtual machines
|
||||
----------------
|
||||
|
||||
Processes running in different VMs on a single machine will appear to FoundationDB as being hardware isolated. FoundationDB takes pains to assure that data replication is protected from hardware-correlated failures. If FoundationDB is run in multiple VMs on a single machine this protection will be subverted. An administrator can inform FoundationDB of this hardware sharing, however, by specifying a machine ID using the ``machine_id`` parameter in :ref:`foundationdb.conf <foundationdb-conf>`. All processes on VMs that share hardware should specify the same ``machine_id``.
|
||||
Processes running in different VMs on a single machine will appear to FoundationDB as being hardware isolated. FoundationDB takes pains to assure that data replication is protected from hardware-correlated failures. If FoundationDB is run in multiple VMs on a single machine this protection will be subverted. An administrator can inform FoundationDB of this hardware sharing, however, by specifying a machine ID using the ``locality_machineid`` parameter in :ref:`foundationdb.conf <foundationdb-conf>`. All processes on VMs that share hardware should specify the same ``locality_machineid``.
|
||||
|
||||
Datacenters
|
||||
------------
|
||||
|
||||
FoundationDB is datacenter aware and supports operation across datacenters. In a multiple-datacenter configuration, it is recommended that you set the :ref:`redundancy mode <configuration-choosing-redundancy-mode>` to ``three_datacenter`` and that you set the ``datacenter_id`` parameter for all FoundationDB processes in :ref:`foundationdb.conf <foundationdb-conf>`.
|
||||
FoundationDB is datacenter aware and supports operation across datacenters. In a multiple-datacenter configuration, it is recommended that you set the :ref:`redundancy mode <configuration-choosing-redundancy-mode>` to ``three_datacenter`` and that you set the ``locality_dcid`` parameter for all FoundationDB processes in :ref:`foundationdb.conf <foundationdb-conf>`.
|
||||
|
||||
If you specify the ``-a`` option to any FoundationDB process in your cluster, you should specify it to all such processes. Processes which do not have a specified datacenter ID on the command line are considered part of a default "unset" datacenter. FoundationDB will incorrectly believe that these processes are failure-isolated from other datacenters, which can reduce performance and fault tolerance.
|
||||
If you specify the ``--datacenter_id`` option to any FoundationDB process in your cluster, you should specify it to all such processes. Processes which do not have a specified datacenter ID on the command line are considered part of a default "unset" datacenter. FoundationDB will incorrectly believe that these processes are failure-isolated from other datacenters, which can reduce performance and fault tolerance.
|
||||
|
||||
.. _administration-removing:
|
||||
|
||||
|
|
@ -494,13 +584,16 @@ To upgrade a FoundationDB cluster, you must install the updated version of Found
|
|||
|
||||
.. warning:: |development-use-only-warning|
|
||||
|
||||
Install updated client binaries
|
||||
-------------------------------
|
||||
|
||||
Apart from patch version upgrades, you should install the new client binary on all your clients and restart them to ensure they can reconnect after the upgrade. See :ref:`multi-version-client-api` for more information. Running ``status json`` will show you which versions clients are connecting with so you can verify before upgrading that clients are correctly configured.
|
||||
|
||||
Stage the packages
|
||||
------------------
|
||||
|
||||
Go to :doc:`downloads` and select Ubuntu or RHEL/CentOS, as appropriate for your system. Download both the client and server packages and copy them to each machine in your cluster.
|
||||
|
||||
.. warning:: |upgrade-client-server-warning|
|
||||
|
||||
Perform the upgrade
|
||||
-------------------
|
||||
|
||||
|
|
@ -525,10 +618,10 @@ Test the database
|
|||
|
||||
Test the database to verify that it is operating normally by running ``fdbcli`` and :ref:`reviewing the cluster status <administration-monitoring-cluster-status>`.
|
||||
|
||||
Restart your application clients
|
||||
--------------------------------
|
||||
Remove old client library versions
|
||||
----------------------------------
|
||||
|
||||
Stop and restart all application clients to reload the upgraded FoundationDB dynamic libraries.
|
||||
You can now remove old client library versions from your clients. This is only to stop creating unnecessary connections.
|
||||
|
||||
.. _version-specific-upgrading:
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ This document contains *reference* information for configuring a new FoundationD
|
|||
|
||||
.. note:: In FoundationDB, a "cluster" refers to one or more FoundationDB processes spread across one or more physical machines that together host a FoundationDB database.
|
||||
|
||||
To plan an externally accessible cluster, you need to understand some basic aspects of the system. You can start by reviewing the :ref:`system requirements <system-requirements>`, then how to :ref:`choose <configuration-choosing-coordination-servers>` and :ref:`change coordination servers <configuration-changing-coordination-servers>`. Next, you should look at the :ref:`configuration file <foundationdb-conf>`, which controls most other aspects of the system. Then, you should understand how to :ref:`choose a redundancy mode <configuration-choosing-redundancy-mode>` and :ref:`configure the storage subsystem <configuration-configuring-storage-subsystem>`. Finally, there are some configurations you can adjust to improve performance if your :ref:`cluster is large <configuration-large-cluster-performance>`.
|
||||
To plan an externally accessible cluster, you need to understand some basic aspects of the system. You can start by reviewing the :ref:`system requirements <system-requirements>`, then how to :ref:`choose <configuration-choosing-coordination-servers>` and :ref:`change coordination servers <configuration-changing-coordination-servers>`. Next, you should look at the :ref:`configuration file <foundationdb-conf>`, which controls most other aspects of the system. Then, you should understand how to :ref:`choose a redundancy mode <configuration-choosing-redundancy-mode>` and :ref:`configure the storage subsystem <configuration-configuring-storage-subsystem>`. Finally, there are some guidelines for setting :ref:`process class configurations <guidelines-process-class-config>`.
|
||||
|
||||
.. _system-requirements:
|
||||
|
||||
|
|
@ -234,15 +234,19 @@ Contains settings applicable to all processes (e.g. fdbserver, backup_agent). Th
|
|||
logdir = /var/log/foundationdb
|
||||
# logsize = 10MiB
|
||||
# maxlogssize = 100MiB
|
||||
# machine_id =
|
||||
# datacenter_id =
|
||||
# class =
|
||||
# memory = 8GiB
|
||||
# storage_memory = 1GiB
|
||||
# locality_machineid =
|
||||
# locality_zoneid =
|
||||
# locality_data_hall =
|
||||
# locality_dcid =
|
||||
# io_trust_seconds = 20
|
||||
|
||||
Contains default parameters for all fdbserver processes on this machine. These same options can be overridden for individual processes in their respective ``[fdbserver.<ID>]`` sections. In this section, the ID of the individual fdbserver can be substituted by using the ``$ID`` variable in the value. For example, ``public_address = auto:$ID`` makes each fdbserver listen on a port equal to its ID.
|
||||
|
||||
.. note:: |multiplicative-suffixes|
|
||||
.. note:: In general locality id's are used to specify the location of processes which in turn is used to determine fault and replication domains.
|
||||
|
||||
* ``command``: The location of the ``fdbserver`` binary.
|
||||
* ``public_address``: The publicly visible IP:Port of the process. If ``auto``, the address will be the one used to communicate with the coordination servers.
|
||||
|
|
@ -251,11 +255,14 @@ Contains default parameters for all fdbserver processes on this machine. These s
|
|||
* ``logdir``: A writable directory (by root or by the user set in the [fdbmonitor] section) where FoundationDB will store log files.
|
||||
* ``logsize``: Roll over to a new log file after the current log file reaches the specified size. The default value is 10MiB.
|
||||
* ``maxlogssize``: Delete the oldest log file when the total size of all log files exceeds the specified size. If set to 0B, old log files will not be deleted. The default value is 100MiB.
|
||||
* ``machine_id``: Machine identifier key. Processes that share a key are considered non-unique for the purposes of data replication. By default, processes on a machine determine a unique key to share. This does not generally need to be set. The ID can be up to 16 hexadecimal digits.
|
||||
* ``datacenter_id``: Data center identifier key. All processes physically located in a data center should share the id. If unset, defaults to a special "default" data center. If you are depending on data center based replication this must be set on all processes. The ID can be up to 16 hexadecimal digits.
|
||||
* ``class``: Machine class specifying the roles that will be taken in the cluster. Valid options are ``storage``, ``transaction``, ``resolution``. See :ref:`configuration-large-cluster-performance` for machine class recommendations in large clusters.
|
||||
* ``class``: Process class specifying the roles that will be taken in the cluster. Recommended options are ``storage``, ``transaction``, ``stateless``. See :ref:`guidelines-process-class-config` for process class config recommendations.
|
||||
* ``memory``: Maximum memory used by the process. The default value is 8GiB. When specified without a unit, MiB is assumed. This parameter does not change the memory allocation of the program. Rather, it sets a hard limit beyond which the process will kill itself and be restarted. The default value of 8GiB is double the intended memory usage in the default configuration (providing an emergency buffer to deal with memory leaks or similar problems). It is *not* recommended to decrease the value of this parameter below its default value. It may be *increased* if you wish to allocate a very large amount of storage engine memory or cache. In particular, when the ``storage_memory`` parameter is increased, the ``memory`` parameter should be increased by an equal amount.
|
||||
* ``storage_memory``: Maximum memory used for data storage. This paramenter is used *only* with memory storage engine, not the ssd storage engine. The default value is 1GiB. When specified without a unit, MB is assumed. Clusters will be restricted to using this amount of memory per process for purposes of data storage. Memory overhead associated with storing the data is counted against this total. If you increase the ``storage_memory``, you should also increase the ``memory`` parameter by the same amount.
|
||||
* ``locality_machineid``: Machine identifier key. All processes on a machine should share a unique id. By default, processes on a machine determine a unique id to share. This does not generally need to be set.
|
||||
* ``locality_zoneid``: Zone identifier key. Processes that share a zone id are considered non-unique for the purposes of data replication. If unset, defaults to machine id.
|
||||
* ``locality_dcid``: Data center identifier key. All processes physically located in a data center should share the id. No default value. If you are depending on data center based replication this must be set on all processes.
|
||||
* ``locality_data_hall``: Data hall identifier key. All processes physically located in a data hall should share the id. No default value. If you are depending on data hall based replication this must be set on all processes.
|
||||
* ``io_trust_seconds``: Time in seconds that a read or write operation is allowed to take before timing out with an error. If an operation times out, all future operations on that file will fail with an error as well. Only has an effect when using AsyncFileKAIO in Linux. If unset, defaults to 0 which means timeout is disabled.
|
||||
|
||||
``[fdbserver.<ID>]`` section(s)
|
||||
---------------------------------
|
||||
|
|
@ -507,27 +514,22 @@ When creating a partition for use with FoundationDB using the standard Linux fdi
|
|||
|
||||
For an SSD with a single partition, the partition should typically begin at sector 2048 (512 byte sectors yields 1024 KiB alignment).
|
||||
|
||||
.. _configuration-large-cluster-performance:
|
||||
.. _guidelines-process-class-config:
|
||||
|
||||
Large cluster performance
|
||||
=========================
|
||||
Guidelines for setting process class
|
||||
====================================
|
||||
|
||||
.. note:: For small-to-medium clusters (32 processes or fewer), FoundationDB's default behavior generally provides the best performance, and you should ignore this section. Further configuration is recommended only for large clusters (> 32 processes) or if you have special latency requirements.
|
||||
In a FoundationDB cluster, each of the ``fdbserver`` processes perform different tasks. Each process is recruited to do a particular task based on its process ``class``. For example, processes with ``class=storage`` are given preference to be recruited for doing storage server tasks, ``class=transaction`` are for log server processes and ``class=stateless`` are for stateless processes like proxies, resolvers, etc.,
|
||||
|
||||
In a FoundationDB cluster, each of the ``fdbserver`` processes perform different tasks. FoundationDB automatically assigns each machine in the cluster a ``class`` that specifies the tasks it will perform. For large clusters, FoundationDB also provides the ability to tune cluster performance by manually assigning the ``class`` of some machines.
|
||||
The recommended minimum number of ``class=transaction`` (log server) processes is 8 (active) + 2 (standby) and the recommended minimum number for ``class=stateless`` processes is 4 (proxy) + 1 (resolver) + 1 (cluster controller) + 1 (master) + 2 (standby). It is better to spread the transaction and stateless processes across as many machines as possible.
|
||||
|
||||
To assign machine classes manually, set the ``class=transaction`` parameter in :ref:`foundationdb.conf <foundationdb-conf>` on all processes on selected machines. The ratio of total processes to ``class``-specified processes should be about 8:1. For example, if you have 64 processes on 16 machines, you would set ``class=transaction`` for 8 processes on 2 machines.
|
||||
``fdbcli`` is used to set the desired number of processes of a particular process type. To do so, you would issue the ``fdbcli`` commands::
|
||||
|
||||
For large clusters with high write workloads (greater than 100,000 writes/second), you can increase performance by increasing the number of proxies, resolvers, and log servers. These are set using ``fdbcli`` in equal (1:1:1) proportions among the processes on machines set to ``class=transaction``.
|
||||
fdb> configure proxies=5
|
||||
fdb> configure logs=8
|
||||
|
||||
For example, if you have 384 processes on 96 machines, and a workload greater than 100,000 writes per second, you would set ``class=transaction`` for 48 processes on 12 machines. Of the latter, you would set 16 processes on 4 machines each as *proxies*, *resolvers*, and *log servers*. To do so, you would issue the ``fdbcli`` commands::
|
||||
.. note:: In the present release, the default value for proxies and log servers is 3 and for resolvers is 1. You should not set the value of a process type to less than its default.
|
||||
|
||||
fdb> configure proxies=16
|
||||
fdb> configure resolvers=16
|
||||
fdb> configure logs=16
|
||||
|
||||
.. note:: In the present release, the default value for proxies and log servers is 3 and for resolvers is 1. The ratios discussed above are guidelines; regardless of them, you should not set the value of a process type to less than its default. For example, on clusters ranging from 36 to 60 processes with high write workloads, you may choose to increase the number of resolvers to 2. In this case, you would nevertheless leave the number of proxies and log servers at their default values of 3.
|
||||
|
||||
.. warning:: The conflict-resolution algorithm used by FoundationDB is conservative: it guarantees that no conflicting transactions will be committed, but it may fail to commit some transactions that theoretically could have been. The effects of this conservatism may increase as you increase the number of proxies. It is therefore important to employ the recommended techniques for :ref:`minimizing conflicts <developer-guide-transaction-conflicts>` when increasing the number of proxies.
|
||||
.. warning:: The conflict-resolution algorithm used by FoundationDB is conservative: it guarantees that no conflicting transactions will be committed, but it may fail to commit some transactions that theoretically could have been. The effects of this conservatism may increase as you increase the number of resolvers. It is therefore important to employ the recommended techniques for :ref:`minimizing conflicts <developer-guide-transaction-conflicts>` when increasing the number of resolvers.
|
||||
|
||||
You can contact us on the `community forums <https://forums.foundationdb.org>`_ if you are interested in more details or if you are benchmarking or performance-tuning on large clusters. Also see our `performance benchmarks </performance>`_ for a baseline of how a well-configured cluster should perform.
|
||||
|
|
|
|||
|
|
@ -5,12 +5,43 @@ Downloads
|
|||
Client & Server Packages
|
||||
========================
|
||||
|
||||
FoundationDB packages are available on Artifactory for the following operating systems:
|
||||
macOS
|
||||
-----
|
||||
|
||||
* `macOS <https://www.foundationdb.org/downloads/5.1.0/release/osx/>`_. Supported on macOS >= 10.7. Installs client and (optionally) server.
|
||||
* `Ubuntu <https://www.foundationdb.org/downloads/5.1.0/release/ubuntu/>`_. The server depends on the client. Supported on 64-bit Ubuntu >= 12.04, but beware of the Linux kernel bug in Ubuntu 12.x.
|
||||
* `RHEL/CentOS EL6 <https://www.foundationdb.org/downloads/5.1.0/release/rhel6/>`_. The server depends on the client. Supported on 64-bit RHEL/CentOS (6.x).
|
||||
* `RHEL/CentOS EL7 <https://www.foundationdb.org/downloads/5.1.0/release/rhel7/>`_. The server depends on the client. Supported on 64-bit RHEL/CentOS (7.x).
|
||||
The macOS installation package is supported on macOS 10.7+. It includes the client and (optionally) the server.
|
||||
|
||||
* `FoundationDB-5.1.4.pkg <https://www.foundationdb.org/downloads/5.1.4/macOS/installers/FoundationDB-5.1.4.pkg>`_
|
||||
|
||||
Ubuntu
|
||||
------
|
||||
|
||||
The Ubuntu packages are supported on 64-bit Ubuntu 12.04+, but beware of the Linux kernel bug in Ubuntu 12.x.
|
||||
|
||||
* `foundationdb-clients-5.1.4-1_amd64.deb <https://www.foundationdb.org/downloads/5.1.4/ubuntu/installers/foundationdb-clients_5.1.4-1_amd64.deb>`_
|
||||
* `foundationdb-server-5.1.4-1_amd64.deb <https://www.foundationdb.org/downloads/5.1.4/ubuntu/installers/foundationdb-server_5.1.4-1_amd64.deb>`_ (depends on the clients package)
|
||||
|
||||
RHEL/CentOS EL6
|
||||
---------------
|
||||
|
||||
The RHEL/CentOS EL6 packages are supported on 64-bit RHEL/CentOS 6.x.
|
||||
|
||||
* `foundationdb-clients-5.1.4-1.el6.x86_64.rpm <https://www.foundationdb.org/downloads/5.1.4/rhel6/installers/foundationdb-clients-5.1.4-1.el6.x86_64.rpm>`_
|
||||
* `foundationdb-server-5.1.4-1.el6.x86_64.rpm <https://www.foundationdb.org/downloads/5.1.4/rhel6/installers/foundationdb-server-5.1.4-1.el6.x86_64.rpm>`_ (depends on the clients package)
|
||||
|
||||
RHEL/CentOS EL7
|
||||
---------------
|
||||
|
||||
The RHEL/CentOS EL7 packages are supported on 64-bit RHEL/CentOS 7.x.
|
||||
|
||||
* `foundationdb-clients-5.1.4-1.el7.x86_64.rpm <https://www.foundationdb.org/downloads/5.1.4/rhel7/installers/foundationdb-clients-5.1.4-1.el7.x86_64.rpm>`_
|
||||
* `foundationdb-server-5.1.4-1.el7.x86_64.rpm <https://www.foundationdb.org/downloads/5.1.4/rhel7/installers/foundationdb-server-5.1.4-1.el7.x86_64.rpm>`_ (depends on the clients package)
|
||||
|
||||
Windows
|
||||
-------
|
||||
|
||||
The Windows installer is supported on 64-bit Windows XP and later. It includes the client and (optionally) the server.
|
||||
|
||||
* `foundationdb-5.1.4-x64.msi <https://www.foundationdb.org/downloads/5.1.4/windows/installers/foundationdb-5.1.4-x64.msi>`_
|
||||
|
||||
API Language Bindings
|
||||
=====================
|
||||
|
|
@ -23,27 +54,24 @@ FoundationDB's C bindings are installed with the FoundationDB client binaries. Y
|
|||
Python 2.7 - 3.4
|
||||
----------------
|
||||
|
||||
The FoundationDB Python API is installed as part of your FoundationDB installation.
|
||||
On macOS and Windows, the FoundationDB Python API bindings are installed as part of your FoundationDB installation.
|
||||
|
||||
If you need to use the FoundationDB Python API from other Python installations or paths, download the `package <https://www.foundationdb.org/downloads/5.1.0/release/python/>`_.
|
||||
If you need to use the FoundationDB Python API from other Python installations or paths, download the Python package:
|
||||
|
||||
Ruby 1.9.3/3.0.2
|
||||
----------------
|
||||
* `foundationdb-5.1.4.tar.gz <https://www.foundationdb.org/downloads/5.1.4/bindings/python/foundationdb-5.1.4.tar.gz>`_
|
||||
|
||||
Download the `gem <https://www.foundationdb.org/downloads/5.1.0/release/ruby/>`_.
|
||||
|
||||
Java JRE 1.8+
|
||||
-------------
|
||||
|
||||
Download the `jar and javadoc.jar <https://www.foundationdb.org/downloads/5.1.0/release/java/>`_.
|
||||
|
||||
Node 0.8.x/0.10.x
|
||||
Ruby 1.9.3/2.0.0+
|
||||
-----------------
|
||||
|
||||
Download the `node package <https://www.foundationdb.org/downloads/5.1.0/release/nodejs/>`_.
|
||||
* `fdb-5.1.4.gem <https://www.foundationdb.org/downloads/5.1.4/bindings/ruby/fdb-5.1.4.gem>`_
|
||||
|
||||
Java 8+
|
||||
-------
|
||||
|
||||
* `fdb-java-5.1.4.jar <https://www.foundationdb.org/downloads/5.1.4/bindings/java/fdb-java-5.1.4.jar>`_
|
||||
* `fdb-java-5.1.4-javadoc.jar <https://www.foundationdb.org/downloads/5.1.4/bindings/java/fdb-java-5.1.4-javadoc.jar>`_
|
||||
|
||||
Go 1.1+
|
||||
-------
|
||||
|
||||
The FoundationDB Go package is available on `github <https://github.com/apple/foundationdb/tree/master/bindings/go>`_
|
||||
The FoundationDB Go package is available on `GitHub <https://github.com/apple/foundationdb/tree/master/bindings/go>`_.
|
||||
|
|
|
|||
|
|
@ -36,6 +36,8 @@ The latest changes are detailed in :doc:`release-notes`. The documentation has t
|
|||
|
||||
* :doc:`tutorials` provide simple examples of client design using FoundationDB.
|
||||
|
||||
* :doc:`administration` contains documentation on administering FoundationDB.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:titlesonly:
|
||||
|
|
|
|||
|
|
@ -105,4 +105,4 @@ A lot of things affect the simple first-order model of performance you see here.
|
|||
* To keep up with the performance modeled above, your disk subsystem will need to do a little over 1 IOPS per write, and about 1 IOPS per (uncached) read.
|
||||
* Network performance tuning at the operating system level can be very important for both latency and throughput, especially in larger clusters.
|
||||
* Running DR and/or backup requires applying each mutation multiple times and then reading those mutations from the database. Using either feature will reduce throughput.
|
||||
* See our :ref:`known-limitations <known limitations>` for other considerations which may affect performance.
|
||||
* See our :ref:`known limitations <known-limitations>` for other considerations which may affect performance.
|
||||
|
|
|
|||
|
|
@ -2,6 +2,59 @@
|
|||
Release Notes
|
||||
#############
|
||||
|
||||
5.1.4
|
||||
=====
|
||||
|
||||
Fixes
|
||||
-----
|
||||
|
||||
* The master would recover twice when a new cluster controller was elected. <rdar://problem/38305649>
|
||||
* The cluster controller could be elected on a storage process after restarting all processes in a cluster. <rdar://problem/37946424>
|
||||
* Allow backup expiration to succeed if the backup is too new to be restorable. <rdar://problem/38237313>
|
||||
* Process metric collection in status could sometimes fail. <rdar://problem/38311829>
|
||||
|
||||
5.1.3
|
||||
=====
|
||||
|
||||
Fixes
|
||||
-----
|
||||
|
||||
* The backup agents ran out of memory when heavily loaded. <rdar://problem/37509745>
|
||||
* Storage servers were not marked as failed until after their files were deleted. <rdar://problem/38266562>
|
||||
* The consistency check requested too many shards in the same request from the proxy. <rdar://problem/37326268>
|
||||
* Client knobs for blob send/receive were reversed in meaning. <rdar://problem/37945529>
|
||||
* fdbbackup status provides more information on reported errors. <rdar://problem/36200858> <rdar://problem/37461836>
|
||||
|
||||
5.1.2
|
||||
=====
|
||||
|
||||
Fixes
|
||||
-----
|
||||
|
||||
* Backup did not incrementally delete mutations from the mutation log. <rdar://problem/37609229>
|
||||
* fdbcli status misreported completed backup/DR as running. <rdar://problem/37608661>
|
||||
* Stopped producing the "fdbblob" alias for fdbbackup. <rdar://problem/37244632>
|
||||
|
||||
5.1.1
|
||||
=====
|
||||
|
||||
Fixes
|
||||
-----
|
||||
|
||||
* Bindings: Disposing a transaction during a commit resulted in a broken promise from ``get_versionstamp``. <rdar://problem/35835272>
|
||||
* Bindings: Calling ``create_cluster`` before initializing the network would result in a crash. <rdar://problem/35563243>
|
||||
* Latest restorable version of a running backup was not being updated in backup layer status. <rdar://problem/37288715>
|
||||
* Backup layer status would sometimes show an error or an incorrect value for the recent blob bandwidth metric. <rdar://problem/37288943>
|
||||
* Backup deletions were not deleting all of the files related to the backup. <rdar://problem/37756550>
|
||||
* The cluster controller was sharing a process with the master even when better locations existed. <rdar://problem/37318611>
|
||||
* Blob credentials files were being opened in read-write mode.
|
||||
* Sometimes fdbbackup did not write log files even when ``--log`` was passed on the command line. <rdar://problem/36259384>
|
||||
|
||||
Performance
|
||||
-----------
|
||||
|
||||
* Backup file uploads will respond to server-side throttling in the middle of a chunk upload rather than only between chunks. <rdar://problem/37245992>
|
||||
|
||||
5.1.0
|
||||
=====
|
||||
|
||||
|
|
|
|||
|
|
@ -297,7 +297,7 @@
|
|||
<Feature Id='FeatureClient' Title='FoundationDB Clients'
|
||||
Description='Installs the FoundationDB command line interface, client library (required by all bindings) and C header files.'
|
||||
Level='1' Absent='disallow' AllowAdvertise='no' TypicalDefault='install'>
|
||||
<!-- This is the equivalent of the 'clients' package on linux, except without Python -->
|
||||
<!-- This is the equivalent of the 'clients' package on linux -->
|
||||
<ComponentRef Id='CreateClusterFileDir'/> <!-- In a client only install, we don't make any files here, but want it to be easy to drop fdb.cluster here -->
|
||||
<ComponentRef Id='PathAddition'/>
|
||||
<ComponentRef Id='InstallPathEnvVar'/>
|
||||
|
|
|
|||
Loading…
Reference in New Issue