Кассандра висит на system_traces CFMetadata - PullRequest
0 голосов
/ 04 мая 2020

Мы используем Cassandra 3.9 на 4 узлах. Сегодня мы пытались добавить пятый узел в качестве отдельного центра обработки данных для репликации всего через NetworkTopologyStrategy. У меня были некоторые проблемы с этапом перестроения, и в настоящее время я удалил этот «новый» узел. Чтение переполнения стека, возможное решение моей проблемы перестроения состояло в том, чтобы отключить сжатие на реплицируемых узлах. Я ждал, пока все уплотнения закончатся sh на узлах, и один из узлов потерпит крах. При перезапуске я заметил, что запуск зависает на строке:

DEBUG [main] 2020-05-04 11:49:59,452 Schema.java:465 - Adding org.apache.cassandra.config.CFMetaData@4f1f9109[cfId=c5e99f16-8677-3914-b17e-960613512345,ksName=system_traces,cfName=sessions,flags=[COMPOUND],params=TableParams{comment=tracing sessions, read_repair_chance=0.0, dclocal_read_repair_chance=0.0, bloom_filter_fp_chance=0.01, crc_check_chance=1.0, gc_grace_seconds=0, default_time_to_live=0, memtable_flush_period_in_ms=3600000, min_index_interval=128, max_index_interval=2048, speculative_retry=99PERCENTILE, caching={'keys' : 'ALL', 'rows_per_partition' : 'NONE'}, compaction=CompactionParams{class=org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy, options={max_threshold=32, min_threshold=4}}, compression=org.apache.cassandra.schema.CompressionParams@e56427ac, extensions={}, cdc=false},comparator=comparator(),partitionColumns=[[] | [client command coordinator duration request started_at parameters]],partitionKeyColumns=[session_id],clusteringColumns=[],keyValidator=org.apache.cassandra.db.marshal.UUIDType,columnMetadata=[client, command, session_id, coordinator, request, started_at, duration, parameters],droppedColumns={},triggers=[],indexes=[]] to cfIdMap

Соответствующие последние строки из system.log:

INFO  [main] 2020-05-04 11:49:58,767 ColumnFamilyStore.java:412 - Initializing system_schema.keyspaces
INFO  [main] 2020-05-04 11:49:58,825 ColumnFamilyStore.java:412 - Initializing system_schema.tables
INFO  [main] 2020-05-04 11:49:58,904 ColumnFamilyStore.java:412 - Initializing system_schema.columns
INFO  [main] 2020-05-04 11:49:59,050 ColumnFamilyStore.java:412 - Initializing system_schema.triggers
INFO  [main] 2020-05-04 11:49:59,079 ColumnFamilyStore.java:412 - Initializing system_schema.dropped_columns
INFO  [main] 2020-05-04 11:49:59,101 ColumnFamilyStore.java:412 - Initializing system_schema.views
INFO  [main] 2020-05-04 11:49:59,124 ColumnFamilyStore.java:412 - Initializing system_schema.types
INFO  [main] 2020-05-04 11:49:59,151 ColumnFamilyStore.java:412 - Initializing system_schema.functions
INFO  [main] 2020-05-04 11:49:59,202 ColumnFamilyStore.java:412 - Initializing system_schema.aggregates
INFO  [main] 2020-05-04 11:49:59,224 ColumnFamilyStore.java:412 - Initializing system_schema.indexes
INFO  [main] 2020-05-04 11:49:59,236 ViewManager.java:137 - Not submitting build tasks for views in keyspace system_schema as storage service is not initialized

Это проблема, с которой я сталкивался ранее при перестройке «новый» узел (который заставлял меня каждый раз перестраивать узел с нуля), но, похоже, теперь он каким-то образом распространился на все узлы в кластере. Я боюсь, что когда мне потребуется перезагрузить любой из них (что произойдет рано или поздно), все они будут зависать, и кластер станет неработоспособным.

Что вызывает эту проблему? Мои system_auth, system_distributed и system_traces установлены на replication_factor 3 в локальном центре данных (в соответствии с руководством по добавлению новых контроллеров домена, за которым я следовал).

Кроме того, трассировка фактически отключена - я вижу, что есть нет данных в пространстве ключей system_traces.

...