Major compaction: flush commitlog by forcing new active segment and flushing all tables #15820

bhalevy · 2023-10-24T06:06:06Z

Major compaction already flushes each table to make
sure it considers any mutations that are present in the
memtable for the purpose of tombstone purging.
See 64ec1c6

However, tombstone purging may be inhibited by data
in commitlog segments based on gc_time_min in the
tombstone_gc_state (See f42eb4d).

Flushing all sstables in the database release
all references to commitlog segments and there
it maximizes the potential for tombstone purging,
which is typically the reason for running major compaction.

However, flushing all tables too frequently might
result in tiny sstables. Since when flushing all
keyspaces using nodetool flush the force_keyspace_compaction
api is invoked for keyspace successively, we need a mechanism
to prevent too frequent flushes by major compaction.

Hence a compaction_flush_all_tables_before_major_seconds interval
configuration option is added (defaults to 24 hours).

In the case that not all tables are flushed prior
to major compaction, we revert to the old behavior of
flushing each table in the keyspace before major-compacting it.

Fixes #15777

elcallio

If we are ok with the additional overhead, this is a neat way to more or less ensure behaviour akin to before.

scylladb-promoter · 2023-10-24T15:32:51Z

🔴 CI State: FAILURE

✅ - Build
❌ - Sanity Tests
✅ - Unit Tests

Failed Tests (1/21010):

test_lcs_table_promotion_major_compaction 🔍

Build Details:

Build URL: https://jenkins.scylladb.com/job/scylla-master/job/scylla-ci/4349/
Duration: 7 hr 33 min
Builder: i-026e35dd13dbbd224

compaction/task_manager_module.cc

scylladb-promoter · 2023-10-31T07:59:12Z

🟢 CI State: SUCCESS

✅ - Build
✅ - Sanity Tests
✅ - Unit Tests

Build Details:

Build URL: https://jenkins.scylladb.com/job/scylla-master/job/scylla-ci/4449/
Duration: 2 hr 19 min
Builder: spider2.cloudius-systems.com

bhalevy · 2023-10-31T08:59:11Z

@avikivity ok to merge?

raphaelsc · 2023-10-31T16:46:19Z

Without reading through the discussion, cannot one argue that minor is affected by the same problem? And that's something that should be dealt with by commitlog itself? IIRC, Calle's patch aims at that, by narrowing the purgeable timestamp range on a per table basis.

raphaelsc · 2023-10-31T16:47:32Z

Just a note: one of the side affects with early flush is increased write amp, and the impact of course depends on frequency of majors.

elcallio · 2023-10-31T16:53:33Z

I have no idea if a minor compaction is allowed to GC tombstones... :-/
The original patch (f42eb4d) will lock out any compaction where CL could cause resurrection.
The goal here is to restore/preserve GC behaviour, mainly for tests. Another approach (as previously discussed) is forcing tests to do manual nodetool flush (which nowadays will also try to purge CL).

avikivity · 2023-10-31T17:21:18Z

minor compaction will gc tombstones, just not those that potentially cover data in commitlog segments pinned by other tables

raphaelsc · 2023-11-01T17:55:23Z

Do we have a concept of TTL for active segments? I am really worried about the new logic backfiring with tables, that is either very low or very high in write activity co-existing. Then they could share CL segments, and tables with high write activity could suffer by not being able to GC tombstones until tables with very low writes finally release the segments. I also wonder if the simplest solution was indeed the best we had on table. A tombstone-like record could also work while not introducing this cross-table dependency for tombstone GC efficiency. But maybe the problem I mentioned above is already solved, then my concern is not valid.

elcallio · 2023-11-01T18:54:04Z

@raphaelsc : Segments don't have any concept of TTL as such, but the previous patch added keeping track of lowest mutation timestamp per segment, and retrieving it on compaction. Indeed, segments kept alive by tables not being memtable flushed could prevent GC thusly, which in a sense is an argument for the above change here, forcing global flushes etc on full comapction. Btw, perhaps you mean tablets, not tables, since I've previously suggesting keeping CL per tablet, not CF in that world...

Not sure if f42eb4d is the easiest solution, but it probably is the safest/lowest overall impact one. I.e. does not add all that much work, though again, in pathological cases it can prevent GC somewhat...

What do you mean by "tombstone-like record"?

Note that we could alleviate the problem by working on making keeping track of sstable RP:s better/actually working, but any compaction across shards prevents that. Do we ever compact sstables created during a nodes current run (uptime) across shards? If not, just tracking highest RP originating in the current node run into resulting sstable(s) would allow us to effectively
eliminate any segments from replay based on sstable set.

avikivity · 2023-11-01T19:50:47Z

Do we have a concept of TTL for active segments? I am really worried about the new logic backfiring with tables, that is either very low or very high in write activity co-existing.

If there are tables with high write activity then they will recycle commitlog quickly.

We have amount 8GB of commitlog per shard in average configurations. AT 2MB/s per shard commitlog write rate (relatively low) we recycle all of commitlog in 4000s = 1h. That's much lower than reasonable repair intervals or gc_grace_seconds.

Then they could share CL segments, and tables with high write activity could suffer by not being able to GC tombstones until tables with very low writes finally release the segments. I also wonder if the simplest solution was indeed the best we had on table. A tombstone-like record could also work while not introducing this cross-table dependency for tombstone GC efficiency. But maybe the problem I mentioned above is already solved, then my concern is not valid.

bhalevy · 2023-11-02T08:09:36Z

Do we have a concept of TTL for active segments? I am really worried about the new logic backfiring with tables, that is either very low or very high in write activity co-existing.

If there are tables with high write activity then they will recycle commitlog quickly.

But the slow tables will still hold up CL segments from recycling.

Maybe we need a TTL on the memtables instead so they are flushed after an idle timeout (e.g. 1 hour) even if the table has infrequent writes.

raphaelsc · 2023-11-02T08:27:30Z

Do we have a concept of TTL for active segments? I am really worried about the new logic backfiring with tables, that is either very low or very high in write activity co-existing.

If there are tables with high write activity then they will recycle commitlog quickly.

But the slow tables will still hold up CL segments from recycling.

Maybe we need a TTL on the memtables instead so they are flushed after an idle timeout (e.g. 1 hour) even if the table has infrequent writes.

Exactly. We can't assume write frequency. There are tables that are almost idle and could affect other co-existing tables that are tombstone heavy. One of the things I thought yesterday, later, was indeed flushing stale memtables. We have to handle it or otherwise users, with this scenario, might potentially face a regression.

bhalevy · 2023-11-02T09:49:14Z

With #15920 covering the regular-compaction path, I think we can merge this PR as is.

bhalevy · 2023-11-08T05:03:39Z

@avikivity, @denesb ok to merge this PR?

denesb · 2023-11-08T06:34:53Z

@avikivity, @denesb ok to merge this PR?

Fine by me.

mykaul · 2023-11-09T12:24:23Z

@avikivity - please review.

compaction/task_manager_module.cc

Deexie · 2023-11-20T12:26:28Z

compaction/task_manager_module.hh

+            std::optional<flush_mode> fm = std::nullopt,
+            seastar::condition_variable* cv = nullptr,
+            tasks::task_manager::task_ptr* current_task = nullptr) noexcept
+        : major_compaction_task_impl(module, tasks::task_id::create_random_id(), module->new_sequence_number(), "keyspace", std::move(keyspace), "", "", parent_id,


Consider using parent_id ? 0 : module->new_sequence_number() not to waste a new sequence number for a child task (which is going to override it anyway)

fixed in v7

nyh · 2023-11-20T21:11:13Z

api/api-doc/column_family.json

@@ -84,6 +84,14 @@
                     "type":"string",
                     "paramType":"path"
                  },
+                  {
+                     "name":"flush_memtables",
+                     "description":"Controls flushing of memtables before compaction (true by default). Set to \"false\" to skip automatic flushing of memtables before compaction, e.g. when the table is flushed explicitly invoking the compaction api.",


I don't understand this explanation. What do you mean "e.g., when the table is flushed explicitly invoking the compaction api"? Did you forget the word before? I.e., "when the table was flushed explicitly before invoking the compacation api"?

In general, I don't like the phenomenon that recently we're adding too many obscure options to the REST API which solve in a manual way some very specific problems that nobody will remember in a year (or tomorrow) that even need to be solved. If these are important as manual options, they should be clearly documented in a document - not just one line. If they are not important as manual options, they should have been automatic.

I see below that you have another copy of this JSON, and it has exactly the word "before" I was missing.
Please choose the best text for both.

sure, will add "before".
The option is not needed if scylla nodetool compact is used, then everything is done automatically and efficiently.

fixed in v7

nyh · 2023-11-20T21:17:15Z

test/nodetool/test_compact.py

+
+
+@pytest.mark.parametrize("flush", ("true", "false"))
+def test_keyspace_flush(nodetool, scylla_only, flush):


It's not clear what a "keyspace flush" actually test? It doesn't test "nodetool flush"... Please add a comment explaining that it actually tests a specific parameter of "nodetool compact". Maybe also use "compact" in the test's name.
And please also explain why it's a Scylla-only test, because it tests a nodetool option "--flush-memtables" that didn't exist in Cassandra's nodetool.

It's not clear what a "keyspace flush" actually test? It doesn't test "nodetool flush"... Please add a comment explaining that it actually tests a specific parameter of "nodetool compact".

I'll rename the function to mention flush_memtables_option.

Maybe also use "compact" in the test's name.

test_compaction.py is all about scylla nodetool compact and it's not mentioned in any other test case.
I think that given the mention of the specific option in the function name, this isn't requried.

And please also explain why it's a Scylla-only test, because it tests a nodetool option "--flush-memtables" that didn't exist in Cassandra's nodetool.

No problem.

nyh · 2023-11-20T21:38:14Z

db/config.cc

+    , compaction_flush_all_tables_before_major_seconds(this, "compaction_flush_all_tables_before_major_seconds", value_status::Used, 86400,
+        "Set the minimum interval in seconds between flushing all tables before each major compaction (default is 86400). "
+        "This option is useful for maximizing tombstone garbage collection by releasing all active commitlog segments. "
+        "Set to 0 to disable automatic flushing all tables before major compaction")


I didn't understand this description. The default is 86400 seconds, i.e., a day. What does it mean? If I do a "nodetool compact" it will or won't flush the tables? What does "a day" do here - does it mean that if the previous nodetool compact happened more than a day or less than a day, the behavior is different?

Yes, flush of all tables happens at most once a day by default since it is expensive and may create small sstables due to excessive memtable flushing.
The reason is to deal with the user / management tool invoking the keyspace_compaction api repeatedly, for each keyspace. It's sufficient to flush all tables only once, on the first invocation.
If more than a day passed since last flush then all tables would be flush again.

BTW, this is related to #15971 that will help flush idle memtable in a timely manner, and with it this mechanism here should skip tables that were already flushed in the last 24 hours, but we're not yet committed to it.

nyh · 2023-11-20T21:40:23Z

test/rest_api/test_column_family.py

-            # 4 Flush it into sstable
-            resp = rest_api.send("POST", f"storage_service/keyspace_flush/{test_keyspace}")
+            # 4 Trigger major compaction on that sstable (flushes memtable by default)
+            resp = rest_api.send("POST", f"column_family/major_compaction/{test_keyspace}:{test_table}")


I don't understand something here.... It seems you are assuming that major compaction will flush the memtable. But I see two patches later that there is some 1-day threshold that may avoid this flush. So is this flush guaranteed? Was it always guaranteed, also before this patch, and the flush step was always unnecessary?

The addition in this series is the flush of all tables in the database before major compaction.
Flushing the particular tables that are major compacted was already done before (in all supported versions), and is still done in the case that flushing all db tables is skipped due to the 1-day threshold (but not if the flush_memtables=false option is given).

nyh · 2023-11-20T21:44:28Z

api/api-doc/storage_service.json

+         "operations":[
+            {
+               "method":"POST",
+               "summary":"Flush all memtables in all keyspaces.",


It is sad that the real explanation why this API exists is hidden in a commit message and not visible to the users. We need to start investing more efforts into documentation (for users) and comments (for developers), than in commit messages :-(

The functionality exists forever at the nodetool level, the new api is there to allow nodetool/jmx to implement it in a more efficient way. The api level is not exposed to the end user, but rather to field-engineering and to power-admins. The summary text here can provide some additional information about the call usage, but I'm not sure the motivation for it is necessarily required here.

nyh · 2023-11-20T21:46:21Z

test/nodetool/conftest.py

+@pytest.fixture(scope="function")
+def cassandra_only(request):
+    if request.config.getoption("nodetool") != "cassandra":
+        pytest.skip('Cassandra-only test skipped')


Ideally, such a fixture should not exist:

If this is a cassandra feature that should be in Scylla, it's a Scylla bug, and it should be marked "@xfail", not "cassandra_only".

If this is a cassandra feature that should never be a Scylla, we shouldn't have a test for it - we're not writing a test suite for Cassandra.

Ok, I understand better now why you added cassandra_only - because you wanted the Java ("cassandra") nodetool to behave differently than the C++ one. More on this below.

yes, it's not a cassandra-only feature, but rather cassandra-specific implementation detail that is tested (in a grey-box way)

nyh · 2023-11-20T21:51:50Z

test/nodetool/test_flush.py

+def test_flush_all_tables(nodetool, scylla_only):
+    nodetool("flush", expected_requests=[
+        expected_request("POST", "/storage_service/flush")
+    ])


Something very strange is happening here, and I'd like @denesb 's opinion.
You decided to change the behavior of "nodetool flush" (to call some new Scylla-only API), but decided to do this only in the new nodetool command that nobody uses yet - and not in the Java nodetool. And these tests verify that this is the case. But why? Why should the C++ nodetool behave differently from the Java one? The whole point of this test file is to verify that it doesn't. At least not yet (I'm sure that in the future we'll stop adding features to the old nodetool, but have we reached that state?)

@nyh it doesn't change the "black-box" behavior from the user's perspective.
It achieves the same goal for bare nodetool flush in either nodetool implementations.
It is a mistake to have scylla_nodetool just mimic the exact api calls that happen to happen in the json nodetool implementation over scylla-jmx, as it inhibits progress.
If the semantics of the operation are indistinguishable I see no reason not to evolve the underlying implementation.

I agree, as long as there are no semantical differences, the two implementations can diverge.
For the most part, there is no reason to diverge, but when there are more optimal set of API endpoints available, there is no reason to not use it.
I suspect we will see more and more changes like this, and slowly, even semantic differences will creep in. The reason is that updating the Java nodetool is such a chore, that everybody avoids it as much as they can.

nyh · 2023-11-20T21:55:52Z

api/api-doc/storage_service.json

+         "operations":[
+            {
+               "method":"POST",
+               "summary":"Forces major compaction in all keyspaces",


To be honest, I don't understand when this API is ever useful. Maybe just when you have exactly one big table?
I remember in the past we tried to claim that users should never explicitly call major compaction at all - that it just ruins performance. So now we're giving them a way to do a major compaction of all tables at once?

In dtest (that represents users mindset) bare nodetool compact, that causes major compaction of all keyspaces, is used elaborately, and naive users may also invoke it sparringly.
Unfortunately in many use cases major compaction is still required once in a while to prevent accumulation of deleted data and tombstones, though in this case I admit the usage may typically be needed for a specific table or keyspace.
In any case, the API is there also to help field-engineering in extreme corner cases. Having an API for something doesn't mean we're encouraging anyone to use it on a regular basis. It's a power-tool that should be used with care, understanding what one is doing.

bhalevy · 2023-11-22T09:39:28Z

In v7 (b5e2603):

rebased
fixed task sequence number generation of keyspace_major_compaction_task_impl (see Major compaction: flush commitlog by forcing new active segment and flushing all tables #15820 (comment))
Improved flush_memtables option description phrasing in api (to include missing "before", see Major compaction: flush commitlog by forcing new active segment and flushing all tables #15820 (comment))
Used _flush_memtables_option in test function names in test/nodetool/test_compact.py (see Major compaction: flush commitlog by forcing new active segment and flushing all tables #15820 (comment))

scylladb-promoter · 2023-11-22T12:04:48Z

🟢 CI State: SUCCESS

✅ - Build
✅ - Sanity Tests
✅ - Unit Tests

Build Details:

Build URL: https://jenkins.scylladb.com/job/scylla-master/job/scylla-ci/4829/
Duration: 2 hr 28 min
Builder: spider7.cloudius-systems.com

bhalevy · 2023-11-27T08:41:02Z

rebased

scylladb-promoter · 2023-11-27T15:08:40Z

🟢 CI State: SUCCESS

✅ - Build
✅ - Sanity Tests
✅ - Unit Tests

Build Details:

Build URL: https://jenkins.scylladb.com/job/scylla-master/job/scylla-ci/4912/
Duration: 6 hr 27 min
Builder: monster

denesb · 2023-11-28T07:39:40Z

There are conflicts with next, a new rebase will be needed after promotion.

Document the behavior if no keyspace is specified or no table(s) are specified for a given keyspace. Fixes scylladb#16032 Signed-off-by: Benny Halevy <bhalevy@scylladb.com>

The current implementation makes no sense. Like `nodetool_path`, base the default `jmx_path` on the assumption that the test is run using, e.g. ``` (cd test/nodetool; pytest --nodetool=cassandra test_compact.py) ``` Signed-off-by: Benny Halevy <bhalevy@scylladb.com>

When flushing is done externally, e.g. by running `nodetool flush` prior to `nodetool compact`, flush_memtables=false can be passed to skip flushing of tables right before they are major-compacted. This is useful to prevent creation of small sstables due to excessive memtable flushing. Signed-off-by: Benny Halevy <bhalevy@scylladb.com>

Flushes all tables after forcing force_new_active_segment of the commitlog to make sure all commitlog segments can get recycled. Otherwise, due to "false sharing", rarely-written tables might inhibit recycling of the commitlog segments they reference. After f42eb4d, that won't allow compaction to purge some tombstones based on the min_gc_time. To be used in the next patch by major compaction. Signed-off-by: Benny Halevy <bhalevy@scylladb.com>

Major compaction already flushes each table to make sure it considers any mutations that are present in the memtable for the purpose of tombstone purging. See 64ec1c6 However, tombstone purging may be inhibited by data in commitlog segments based on `gc_time_min` in the `tombstone_gc_state` (See f42eb4d). Flushing all sstables in the database release all references to commitlog segments and there it maximizes the potential for tombstone purging, which is typically the reason for running major compaction. However, flushing all tables too frequently might result in tiny sstables. Since when flushing all keyspaces using `nodetool flush` the `force_keyspace_compaction` api is invoked for keyspace successively, we need a mechanism to prevent too frequent flushes by major compaction. Hence a `compaction_flush_all_tables_before_major_seconds` interval configuration option is added (defaults to 24 hours). In the case that not all tables are flushed prior to major compaction, we revert to the old behavior of flushing each table in the keyspace before major-compacting it. Fixes scylladb#15777 Signed-off-by: Benny Halevy <bhalevy@scylladb.com>

For flushing all tables in the database. The advantage of this api is that `commitlog->force_new_active_segment` happens only once in `database::flush_all_tables` rather than once per keyspace (when `nodetool flush` translates to a sequence of `/storage_service/keyspace_flush` calls). Signed-off-by: Benny Halevy <bhalevy@scylladb.com>

For major compacting all tables in the database. The advantage of this api is that `commitlog->force_new_active_segment` happens only once in `database::flush_all_tables` rather than once per keyspace (when `nodetool compact` translates to a sequence of `/storage_service/keyspace_compaction` calls). Signed-off-by: Benny Halevy <bhalevy@scylladb.com>

It looks like `nodetool compact standard1` is meant to show how to compact a specified table, not a keyspace. Note that the previous example like is for a keyspace. So fix the table compaction example to: `nodetool compact keyspace1 standard1` Signed-off-by: Benny Halevy <bhalevy@scylladb.com>

Provide 3 examples, like in the nodetool/compact page: global, per-keyspace, per-table. Signed-off-by: Benny Halevy <bhalevy@scylladb.com>

bhalevy · 2023-11-28T14:52:12Z

In v8 (310ff20):

rebased + retested
docs: nodetool: compact: fix example
docs: nodetool: flush: enrich examples

@annastuchlik can you please review last 2 patches.
Sorry for the last minute changes.

annastuchlik

The doc updates look good.

scylladb-promoter · 2023-11-28T17:14:27Z

🟢 CI State: SUCCESS

✅ - Build
✅ - Sanity Tests
✅ - Unit Tests

Build Details:

Build URL: https://jenkins.scylladb.com/job/scylla-master/job/scylla-ci/4944/
Duration: 2 hr 23 min
Builder: spider1.cloudius-systems.com

bhalevy · 2023-11-29T06:06:59Z

@denesb / @scylladb/scylla-maint please queue

… active segment and flushing all tables' from Kefu Chai Major compaction already flushes each table to make sure it considers any mutations that are present in the memtable for the purpose of tombstone purging. See 64ec1c6 However, tombstone purging may be inhibited by data in commitlog segments based on `gc_time_min` in the `tombstone_gc_state` (See f42eb4d). Flushing all sstables in the database release all references to commitlog segments and there it maximizes the potential for tombstone purging, which is typically the reason for running major compaction. However, flushing all tables too frequently might result in tiny sstables. Since when flushing all keyspaces using `nodetool flush` the `force_keyspace_compaction` api is invoked for keyspace successively, we need a mechanism to prevent too frequent flushes by major compaction. Hence a `compaction_flush_all_tables_before_major_seconds` interval configuration option is added (defaults to 24 hours). In the case that not all tables are flushed prior to major compaction, we revert to the old behavior of flushing each table in the keyspace before major-compacting it. Fixes #15777 Closes #15820 to address the confliction, following change is also included in this changeset: tools/scylla-nodetool: implement the cleanup command The --jobs command-line argument is accepted but ignored, just like the current nodetool does. Refs: #15588 Closes #16756 * github.com:scylladb/scylladb: docs: nodetool: flush: enrich examples docs: nodetool: compact: fix example api: add /storage_service/compact api: add /storage_service/flush tools/scylla-nodetool: implement the flush command compaction_manager: flush_all_tables before major compaction database: add flush_all_tables api: compaction: add flush_memtables option test/nodetool: jmx: fix path to scripts/scylla-jmx scylla-nodetool, docs: improve optional params documentation tools/scylla-nodetool: extract keyspace/table parsing tools/scylla-nodetool: implement the cleanup command test/nodetool: rest_api_mock: add more options for multiple requests

bhalevy requested a review from nyh as a code owner October 24, 2023 06:06

bhalevy requested review from raphaelsc and elcallio and removed request for nyh October 24, 2023 06:06

bhalevy force-pushed the major-compaction-flush-commitlog branch from 0b602d7 to 7691e07 Compare October 24, 2023 06:08

elcallio approved these changes Oct 24, 2023

View reviewed changes

denesb approved these changes Oct 24, 2023

View reviewed changes

avikivity reviewed Oct 24, 2023

View reviewed changes

compaction/task_manager_module.cc Outdated Show resolved Hide resolved

bhalevy mentioned this pull request Nov 2, 2023

Scylla should flush stale memtables periodically. #15920

Open

bhalevy requested review from avikivity and denesb November 5, 2023 15:59

elcallio mentioned this pull request Nov 6, 2023

commitlog: Add optional max lifetime parameter to cl instance #15971

Open

raphaelsc reviewed Nov 9, 2023

View reviewed changes

compaction/task_manager_module.cc Outdated Show resolved Hide resolved

bhalevy force-pushed the major-compaction-flush-commitlog branch from 7691e07 to c0a67c6 Compare November 9, 2023 13:33

Deexie reviewed Nov 20, 2023

View reviewed changes

avikivity approved these changes Nov 20, 2023

View reviewed changes

nyh reviewed Nov 20, 2023

View reviewed changes

bhalevy force-pushed the major-compaction-flush-commitlog branch from 1bf4ab4 to b5e2603 Compare November 22, 2023 09:36

bhalevy mentioned this pull request Nov 26, 2023

test_cluster_restore_no_resurrection dtest fails with commitlog min_gc fix when tombstone_gc is correctly deferred without node.flush #15777

Closed

bhalevy force-pushed the major-compaction-flush-commitlog branch from b5e2603 to 19f529e Compare November 27, 2023 08:40

bhalevy added 9 commits November 28, 2023 16:37

scylla-nodetool, docs: improve optional params documentation

9324363

Document the behavior if no keyspace is specified or no table(s) are specified for a given keyspace. Fixes scylladb#16032 Signed-off-by: Benny Halevy <bhalevy@scylladb.com>

docs: nodetool: flush: enrich examples

310ff20

Provide 3 examples, like in the nodetool/compact page: global, per-keyspace, per-table. Signed-off-by: Benny Halevy <bhalevy@scylladb.com>

bhalevy force-pushed the major-compaction-flush-commitlog branch from 19f529e to 310ff20 Compare November 28, 2023 14:50

annastuchlik approved these changes Nov 28, 2023

View reviewed changes

scylladb-promoter closed this in 3ed6925 Nov 29, 2023

scylladb-promoter merged commit 3ed6925 into scylladb:master Nov 29, 2023
4 checks passed

tchaikov mentioned this pull request Jan 12, 2024

[Branch 5.4]: Major compaction: flush commitlog by forcing new active segment and flushing all tables #16756

Merged

bhalevy mentioned this pull request Jan 15, 2024

compaction_manager: flush tables before cleanup #16757

Merged



		@pytest.mark.parametrize("flush", ("true", "false"))
		def test_keyspace_flush(nodetool, scylla_only, flush):

Major compaction: flush commitlog by forcing new active segment and flushing all tables #15820

Major compaction: flush commitlog by forcing new active segment and flushing all tables #15820

Conversation

bhalevy commented Oct 24, 2023 • edited

elcallio left a comment

Choose a reason for hiding this comment

scylladb-promoter commented Oct 24, 2023

🔴 CI State: FAILURE

Failed Tests (1/21010):

Build Details:

scylladb-promoter commented Oct 31, 2023

🟢 CI State: SUCCESS

Build Details:

bhalevy commented Oct 31, 2023

raphaelsc commented Oct 31, 2023

raphaelsc commented Oct 31, 2023

elcallio commented Oct 31, 2023

avikivity commented Oct 31, 2023

raphaelsc commented Nov 1, 2023

elcallio commented Nov 1, 2023

avikivity commented Nov 1, 2023

bhalevy commented Nov 2, 2023

raphaelsc commented Nov 2, 2023

bhalevy commented Nov 2, 2023

bhalevy commented Nov 8, 2023

denesb commented Nov 8, 2023

mykaul commented Nov 9, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bhalevy commented Nov 22, 2023

scylladb-promoter commented Nov 22, 2023

🟢 CI State: SUCCESS

Build Details:

bhalevy commented Nov 27, 2023

scylladb-promoter commented Nov 27, 2023

🟢 CI State: SUCCESS

Build Details:

denesb commented Nov 28, 2023

bhalevy commented Nov 28, 2023

annastuchlik left a comment

Choose a reason for hiding this comment

scylladb-promoter commented Nov 28, 2023

🟢 CI State: SUCCESS

Build Details:

bhalevy commented Nov 29, 2023

bhalevy commented Oct 24, 2023 •

edited