mirror of
https://github.com/featurebasedb/featurebase.git
synced 2026-08-28 10:54:59 +00:00
No description
fb8f612afe
This PR forces the non-coordinator nodes to reset their translation sync (and therefore their own cosideration of read-only partitions) any time they receive a `ClusterStatus` message. So basically, as the cluster grows during the startup process, each node will reset their translation sync. This is NOT a good solution log term, but it should address the immediate problem. Things to note: - the coordinator sync isn't getting reset, but that's ok, because the immediate problem is a partition marked as read-only when it shouldn't be; i.e. it's ok to have the inverse (a partition not marked as read-only when it should be) because that partition won't receive requests anyway. - the last node to start is already correct and doesn't really need to reset its sync. - there are many other scenarios not covered by this fix. Based on this theory: ``` i have another theory that i’m going to try to test. this one would only apply in the case where a multi-node cluster is restarted with an existing, keyed index. - start node0: it thinks it’s responsible for all partitions (nothing is read-only) - start node1: it thinks it’s responsible for ~1/2 of the partitions and marks the other 1/2 as read-only - start node2: it thinks it’s responsible for ~1/3 of the partitions and marks the other 2/3 as read-only now if node0 is the coordinator receiving all translation requests, that still might not explain what’s happening, because in that case it would just do all the translating. i think. but either way, i should make sure that scenario is not happening, but i think it may be. actually, that might explain it, because what would happen when the coordinator received a translation request, is that it would handle the 1/3 that it owned (now that the cluster is 3 nodes), and it would send the other 2/3 out to the other 2 nodes. but where it sent the requests wouldn’t line up with what the nodes thought they were responsible for based on the restart order in this example, node 1 would receive requests for the wrong partitions ``` |
||
|---|---|---|
| .circleci | ||
| .github | ||
| api/client | ||
| boltdb | ||
| cmd | ||
| ctl | ||
| docs | ||
| encoding/proto | ||
| enterprise | ||
| extensions | ||
| gcnotify | ||
| gopsutil | ||
| gossip | ||
| http | ||
| internal | ||
| logger | ||
| lru | ||
| mock | ||
| pql | ||
| prometheus | ||
| proto | ||
| roaring | ||
| server | ||
| shardwidth | ||
| stats | ||
| statsd | ||
| syswrap | ||
| test | ||
| testdata/sample_view | ||
| toml | ||
| tracing | ||
| .gitignore | ||
| .golangci.yml | ||
| api.go | ||
| api_test.go | ||
| apimethod_string.go | ||
| attr.go | ||
| attr_test.go | ||
| broadcast.go | ||
| cache.go | ||
| cache_test.go | ||
| CHANGELOG.md | ||
| client.go | ||
| cluster.go | ||
| cluster_internal_test.go | ||
| cmd.go | ||
| CONTRIBUTING.md | ||
| diagnostics.go | ||
| diagnostics_internal_test.go | ||
| doc.go | ||
| Dockerfile | ||
| Dockerfile-clustertests | ||
| event.go | ||
| executor.go | ||
| executor_internal_test.go | ||
| executor_test.go | ||
| extension.go | ||
| field.go | ||
| field_internal_test.go | ||
| field_test.go | ||
| fragment.go | ||
| fragment_internal_test.go | ||
| gc.go | ||
| gendebug_test.go | ||
| generation.go | ||
| generation_debug.go | ||
| generation_nodebug.go | ||
| generation_test.go | ||
| go.mod | ||
| go.sum | ||
| handler.go | ||
| holder.go | ||
| holder_internal_test.go | ||
| holder_test.go | ||
| index.go | ||
| index_internal_test.go | ||
| index_test.go | ||
| iterator.go | ||
| iterator_internal_test.go | ||
| LICENSE | ||
| license.exceptions | ||
| Makefile | ||
| mmap_test.go | ||
| NOTES | ||
| NOTICE | ||
| pilosa.go | ||
| pilosa_internal_test.go | ||
| pilosa_test.go | ||
| README.md | ||
| row.go | ||
| row_test.go | ||
| server.go | ||
| server_internal_test.go | ||
| snapshotqueue.go | ||
| time.go | ||
| time_internal_test.go | ||
| translate.go | ||
| translator_test.go | ||
| uri.go | ||
| uri_internal_test.go | ||
| utils_internal_test.go | ||
| version.go | ||
| view.go | ||
| view_internal_test.go | ||
An open source, distributed bitmap index.
Want to contribute? One of the easiest ways is to tell us how you're using (or want to use) Pilosa. We learn from every discussion!
Docs
See our Documentation for information about installing and working with Pilosa.
Getting Started
-
Start Pilosa with the default configuration:
pilosa serverand verify that it's running:
curl localhost:10101/nodes -
Follow along with the Sample Project to get a better understanding of Pilosa's capabilities.
Data Model
Check out how the Pilosa Data Model works.
Query Language
You can interact with Pilosa directly in the console using the Pilosa Query Language (PQL).
Client Libraries
There are supported libraries for the following languages:
Licenses
The core Pilosa code base and all default builds (referred to as Pilosa Community Edition) are licensed completely under the Apache License, Version 2.0.
If you build Pilosa with the enterprise build tag (Pilosa Enterprise Edition), then that build will include features licensed under the GNU Affero General
Public License (AGPL). Enterprise code is located entirely in the github.com/pilosa/pilosa/enterprise
directory. See github.com/pilosa/pilosa/NOTICE and
github.com/pilosa/pilosa/LICENSE for more information about Pilosa licenses.
Get Support
There are several channels available for you to reach out to us for support.
Contributing
Pilosa is an open source project. Please see our Contributing Guide for information about how to get involved.