Наш сервис может без проблем выполнять запросы SELECT и INSERT на наших локальных и развернутых экземплярах Cassandra.
Однако у нас возникли проблемы со следующим запросом DELETE:
DELETE FROM config_by_uuid WHERE uuid = record_uuid;
Наш сервис может успешно удалить запись в нашем локальном экземпляре, но не в нашем развернутом экземпляре. Обратите внимание, что это поведение является постоянным для обоих экземпляров, и что о наших развернутых экземплярах не сообщается об ошибках.
Примечательно, что когда вышеуказанный запрос выполняется на нашем развернутом экземпляре через cqlsh, он успешно удаляетзапись. Сбой только при запуске из нашего сервиса на нашем развернутом экземпляре. Наш сервис и cqlsh используют одного и того же пользователя для выполнения запросов.
Сначала мы подозревали, что это может быть проблема согласованности Cassandra, поэтому мы попытались запустить запрос на cqlsh с уровнями согласованности ONE и QUORUM, и для обоих уровней согласованности запрос выполнен успешно. Обратите внимание, что наш сервис в настоящее время использует QUORUM для всех операций.
Причина, по которой мы не учитываем возможность возникновения проблемы с кодом, заключается в том, что сервис работает так, как задумано для нашего локального экземпляра. Мы рассуждаем так: если бы это была проблема с кодом, она бы не работала в обоих случаях, и поэтому разница должна лежать где-то в наших установках Cassandra. Оба экземпляра используют Cassandra 3.11.X.
Наше пространство ключей и детали таблицы одинаковы для обоих экземпляров и заключаются в следующем (обратите внимание, что на данный момент мы работаем только с одним узлом, потому что мы все еще на ранних этапахразвития):
CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'} AND durable_writes = true;
CREATE TABLE config.config_by_uuid (
uuid uuid PRIMARY KEY,
config_name text,
config_value text,
service_uuid uuid,
tenant_uuid uuid,
user_uuid uuid
) WITH bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
Мы включили трассировку на нашей развернутой Cassandra, и ниже приведены подробности при выполнении запроса через cqlsh:
system_traces.sessions:
session_id: 25b48ce0-0491-11ea-ace9-5db0758d00f3
client: node_ip
command: QUERY
coordinator: node_ip
duration: 1875
parameters: {'consistency_level': 'ONE', 'page_size': '100', 'query': 'delete from config_by_uuid where uuid = 96ac4699-5199-4a80-9c59-b592d28ea2b7;', 'serial_consistency_level': 'SERIAL'}
request: Execute CQL3 query
started_at: 2019-11-11 14:40:03.758000+0000
system_traces.events:
session_id | event_id | activity | source | source_elapsed | thread
--------------------------------------+--------------------------------------+---------------------------------------------------------------------------------------+--------------+----------------+-----------------------------
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4b3f0-0491-11ea-ace9-5db0758d00f3 | Parsing delete from config_by_uuid where uuid = 96ac4699-5199-4a80-9c59-b592d28ea2b7; | node_ip | 203 | Native-Transport-Requests-1
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4b3f1-0491-11ea-ace9-5db0758d00f3 | Preparing statement | node_ip | 381 | Native-Transport-Requests-1
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4b3f2-0491-11ea-ace9-5db0758d00f3 | Executing single-partition query on roles | node_ip | 1044 | ReadStage-3
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4b3f3-0491-11ea-ace9-5db0758d00f3 | Acquiring sstable references | node_ip | 1080 | ReadStage-3
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4db00-0491-11ea-ace9-5db0758d00f3 | Skipped 0/1 non-slice-intersecting sstables, included 0 due to tombstones | node_ip | 1114 | ReadStage-3
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4db01-0491-11ea-ace9-5db0758d00f3 | Key cache hit for sstable 2 | node_ip | 1152 | ReadStage-3
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4db02-0491-11ea-ace9-5db0758d00f3 | Merged data from memtables and 1 sstables | node_ip | 1276 | ReadStage-3
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4db03-0491-11ea-ace9-5db0758d00f3 | Read 1 live rows and 0 tombstone cells | node_ip | 1307 | ReadStage-3
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4db04-0491-11ea-ace9-5db0758d00f3 | Executing single-partition query on roles | node_ip | 1466 | ReadStage-3
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4db05-0491-11ea-ace9-5db0758d00f3 | Acquiring sstable references | node_ip | 1484 | ReadStage-3
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4db06-0491-11ea-ace9-5db0758d00f3 | Skipped 0/1 non-slice-intersecting sstables, included 0 due to tombstones | node_ip | 1501 | ReadStage-3
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4db07-0491-11ea-ace9-5db0758d00f3 | Key cache hit for sstable 2 | node_ip | 1525 | ReadStage-3
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4db08-0491-11ea-ace9-5db0758d00f3 | Merged data from memtables and 1 sstables | node_ip | 1573 | ReadStage-3
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4db09-0491-11ea-ace9-5db0758d00f3 | Read 1 live rows and 0 tombstone cells | node_ip | 1593 | ReadStage-3
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4db0a-0491-11ea-ace9-5db0758d00f3 | Determining replicas for mutation | node_ip | 1743 | Native-Transport-Requests-1
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4db0b-0491-11ea-ace9-5db0758d00f3 | Appending to commitlog | node_ip | 1796 | MutationStage-3
25b48ce0-0491-11ea-ace9-5db0758d00f3 | 25b4db0c-0491-11ea-ace9-5db0758d00f3 | Adding to config_by_uuid memtable | node_ip | 1827 | MutationStage-3
Ниже приведены подробности при выполнении запроса изнаш сервис:
system_traces.sessions:
session_id: 9ed67270-048f-11ea-ace9-5db0758d00f3
client: service_ip
command: QUERY
coordinator: node_ip
duration: 3247
parameters: {'bound_var_0_uuid': '19e12033-5ad4-4376-8293-315a26370d93', 'consistency_level': 'QUORUM', 'page_size': '5000', 'query': 'DELETE FROM config.config_by_uuid WHERE uuid=? ', 'serial_consistency_level': 'SERIAL'}
request: Execute CQL3 prepared query
started_at: 2019-11-11 14:29:07.991000+0000
system_traces.events:
session_id | event_id | activity | source | source_elapsed | thread
--------------------------------------+--------------------------------------+---------------------------------------------------------------------------+--------------+----------------+-----------------------------
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed67271-048f-11ea-ace9-5db0758d00f3 | Executing single-partition query on roles | node_ip | 178 | ReadStage-2
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed67272-048f-11ea-ace9-5db0758d00f3 | Acquiring sstable references | node_ip | 204 | ReadStage-2
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed67273-048f-11ea-ace9-5db0758d00f3 | Skipped 0/1 non-slice-intersecting sstables, included 0 due to tombstones | node_ip | 368 | ReadStage-2
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed69980-048f-11ea-ace9-5db0758d00f3 | Key cache hit for sstable 2 | node_ip | 553 | ReadStage-2
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed69981-048f-11ea-ace9-5db0758d00f3 | Merged data from memtables and 1 sstables | node_ip | 922 | ReadStage-2
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed69982-048f-11ea-ace9-5db0758d00f3 | Read 1 live rows and 0 tombstone cells | node_ip | 1193 | ReadStage-2
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed6c090-048f-11ea-ace9-5db0758d00f3 | Executing single-partition query on roles | node_ip | 1587 | ReadStage-3
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed6c091-048f-11ea-ace9-5db0758d00f3 | Acquiring sstable references | node_ip | 1642 | ReadStage-3
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed6c092-048f-11ea-ace9-5db0758d00f3 | Skipped 0/1 non-slice-intersecting sstables, included 0 due to tombstones | node_ip | 1708 | ReadStage-3
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed6c093-048f-11ea-ace9-5db0758d00f3 | Key cache hit for sstable 2 | node_ip | 1750 | ReadStage-3
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed6c094-048f-11ea-ace9-5db0758d00f3 | Merged data from memtables and 1 sstables | node_ip | 1845 | ReadStage-3
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed6c095-048f-11ea-ace9-5db0758d00f3 | Read 1 live rows and 0 tombstone cells | node_ip | 1888 | ReadStage-3
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed6e7a0-048f-11ea-ace9-5db0758d00f3 | Determining replicas for mutation | node_ip | 2660 | Native-Transport-Requests-1
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed6e7a1-048f-11ea-ace9-5db0758d00f3 | Appending to commitlog | node_ip | 3028 | MutationStage-2
9ed67270-048f-11ea-ace9-5db0758d00f3 | 9ed6e7a2-048f-11ea-ace9-5db0758d00f3 | Adding to config_by_uuid memtable | node_ip | 3133 | MutationStage-2
Ниже приведены шаги, которые мы использовали для установки нашей локальной Cassandra в Windows 10. Обратите внимание, что никакие файлы конфигурации не были изменены после установки:
Установленная Java 8. java -version и javac -version работают.
Установленный Python 2. python --version isрабочий.
Загрузил последний файл Cassandra bin.tar.gz из:
http://cassandra.apache.org/download/
Извлек содержимое zip-файла, переименовал его вcassandra и поместил его в C:\.
Добавлено C:\cassandra\bin в нашу переменную среды PATH.
Ниже приведены шагиМы использовали для установки нашей развернутой Cassandra на CentOS 8:
Обновление ням:
yum -y update
Установка Java:
yum -y install java
java -version
Создать файл репо, который будет использоваться yum:
nano /etc/yum.repos.d/cassandra.repo
---
[cassandra]
name=Apache Cassandra
baseurl=https://www.apache.org/dist/cassandra/redhat/311x/
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://www.apache.org/dist/cassandra/KEYS
Установить Cassandra:
yum -y install cassandra
Создание файла службы для Cassandra:
nano /etc/systemd/system/cassandra.service
---
[Unit]
Description=Apache Cassandra
After=network.target
[Service]
PIDFile=/var/run/cassandra/cassandra.pid
User=cassandra
Group=cassandra
ExecStart=/usr/sbin/cassandra -f -p /var/run/cassandra/cassandra.pid
Restart=always
[Install]
WantedBy=multi-user.target
Перезагрузка системных демонов:
systemctl daemon-reload
Предоставление разрешений для каталога Cassandra:
sudo chown -R cassandra:cassandra /var/lib/cassandra
sudo chown -R cassandra:cassandra /var/log/cassandra
Настройка системы для запуска Cassandra при запуске:
systemctl enable cassandra
Настройка файла cassandra.yaml:
nano /etc/cassandra/conf/cassandra.yaml
---
(TIP: Use Ctrl+W to search for the settings you want to change.)
authenticator: org.apache.cassandra.auth.PasswordAuthenticator
authorizer: org.apache.cassandra.auth.CassandraAuthorizer
role_manager: CassandraRoleManager
roles_validity_in_ms: 0
permissions_validity_in_ms: 0
cluster_name: 'MyCompany Dev'
initial_token: (should be commented-out)
listen_address: node_ip
rpc_address: node_ip
endpoint_snitch: GossipingPropertyFileSnitch
auto_bootstrap: false (add this at the bottom of the file)
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: "node_ip"
Настройка файла cassandra-topology.properties:
nano /etc/cassandra/conf/cassandra-topology.properties
---
(NOTE: For "Cassandra Node IP=Data Center:Rack", delete all existing values.)
#Cassandra Node IP=Data Center:Rack
[Local IP]=SG:Dev
# default for unknown nodes
default=SG:Dev
Настройте файл cassandra-rackdc.properties:
nano /etc/cassandra/conf/cassandra-rackdc.properties
---
dc=SG
rack=Dev
Выполните следующие команды для очистки каталогов:
rm -rf /var/lib/cassandra/data
rm -rf /var/lib/cassandra/commitlog
rm -rf /var/lib/cassandra/saved_caches
rm -rf /var/lib/cassandra/hints
Запустить Cassandra:
service cassandra start
Установить Python 2:
yum -y install python2
python2 --version
Войдите в систему по умолчаниюпользователь:
cqlsh -u cassandra -p cassandra node_ip --request-timeout=6000
Создать нового пользователя:
CREATE ROLE adminuser WITH PASSWORD = 'password' AND SUPERUSER = true AND LOGIN = true;
exit;
Войти как новый пользователь:
cqlsh -u adminuser -p password node_ip --request-timeout=6000
Отключить пользователя по умолчанию:
ALTER ROLE cassandra WITH PASSWORD = 'cassandra' AND SUPERUSER = false AND LOGIN = false;
REVOKE ALL PERMISSIONS ON ALL KEYSPACES FROM cassandra;
GRANT ALL PERMISSIONS ON ALL KEYSPACES TO adminuser;
exit;
Наш сервис написан на Голанге и использует следующие сторонние библиотеки для общения с Кассандрой:
github.com/gocql/gocql
github.com/scylladb/gocqlx
github.com/scylladb/gocqlx/qb
ОБНОВЛЕНИЕ 1: Ниже приведены разрешения для пользователя, который использует наш сервис и cqlsh для выполнения запросов (через list all permissions on config.config_by_uuid;):
role | username | resource | permission
----------+-----------+-------------------------------+------------
adminuser | adminuser | <all keyspaces> | CREATE
adminuser | adminuser | <all keyspaces> | ALTER
adminuser | adminuser | <all keyspaces> | DROP
adminuser | adminuser | <all keyspaces> | SELECT
adminuser | adminuser | <all keyspaces> | MODIFY
adminuser | adminuser | <all keyspaces> | AUTHORIZE
adminuser | adminuser | <keyspace config> | CREATE
adminuser | adminuser | <keyspace config> | ALTER
adminuser | adminuser | <keyspace config> | DROP
adminuser | adminuser | <keyspace config> | SELECT
adminuser | adminuser | <keyspace config> | MODIFY
adminuser | adminuser | <keyspace config> | AUTHORIZE
adminuser | adminuser | <table config.config_by_uuid> | ALTER
adminuser | adminuser | <table config.config_by_uuid> | DROP
adminuser | adminuser | <table config.config_by_uuid> | SELECT
adminuser | adminuser | <table config.config_by_uuid> | MODIFY
adminuser | adminuser | <table config.config_by_uuid> | AUTHORIZE
Документация Cassandra гласит, что MODIFY предоставляет следующие разрешения: INSERT, DELETE, UPDATE, TRUNCATE. Поскольку adminuser может вставлять записи без каких-либо проблем, похоже, что наша проблема удаления не является проблемой разрешения.
ОБНОВЛЕНИЕ 2: Ниже указаны владелец и разрешениядля ключевых каталогов Cassandra (через ls -al):
/ etc / cassandra:
total 20
drwxr-xr-x 3 root root 4096 Nov 12 22:18 .
drwxr-xr-x. 103 root root 12288 Nov 12 22:18 ..
lrwxrwxrwx 1 root root 27 Nov 12 22:18 conf -> /etc/alternatives/cassandra
drwxr-xr-x 3 root root 4096 Nov 12 22:18 default.conf
/var / lib / cassandra:
total 24
drwxr-xr-x 6 cassandra cassandra 4096 Nov 12 22:38 .
drwxr-xr-x. 43 root root 4096 Nov 12 22:18 ..
drwxr-xr-x 2 cassandra cassandra 4096 Nov 12 22:38 commitlog
drwxr-xr-x 8 cassandra cassandra 4096 Nov 12 22:40 data
drwxr-xr-x 2 cassandra cassandra 4096 Nov 12 22:38 hints
drwxr-xr-x 2 cassandra cassandra 4096 Nov 12 22:38 saved_caches
/ var / log / cassandra:
total 3788
drwxr-xr-x 2 cassandra cassandra 4096 Nov 12 22:19 .
drwxr-xr-x. 11 root root 4096 Nov 12 22:18 ..
-rw-r--r-- 1 cassandra cassandra 2661056 Nov 12 22:41 debug.log
-rw-r--r-- 1 cassandra cassandra 52623 Nov 12 23:11 gc.log.0.current
-rw-r--r-- 1 cassandra cassandra 1141764 Nov 12 22:40 system.log
ОБНОВЛЕНИЕ 3: Мы также подозревали, что это проблема tombstone или compaction, поэтому мы попытались установить gc_grace_seconds в 0 и запустили запрос на удаление, но это не помогло. Также не помогает.
Запуск nodetool compact -s config config_by_uuid с gc_grace_seconds, установленным на 0, и значение по умолчанию 864000 также не помогло.
ОБНОВЛЕНИЕ4: Мы попытались удалить и переустановить Cassandra, но это не помогло. Ниже приведены шаги, которые мы использовали:
Удалите Cassandra через yum:
yum -y remove cassandra
Удалите следующие каталоги:
rm -rf /var/lib/cassandra
rm -rf /var/log/cassandra
rm -rf /etc/cassandra
Удалены все оставшиеся файлы:
(Примечание: выполните rm -rf для результатов следующих команд.)
find / -name 'cassandra'
find / -name '*cassandra*'
например,
rm -rf /run/lock/subsys/cassandra
rm -rf /tmp/hsperfdata_cassandra
rm -rf /etc/rc.d/rc3.d/S80cassandra
rm -rf /etc/rc.d/rc2.d/S80cassandra
rm -rf /etc/rc.d/rc0.d/K20cassandra
rm -rf /etc/rc.d/rc6.d/K20cassandra
rm -rf /etc/rc.d/rc5.d/S80cassandra
rm -rf /etc/rc.d/rc4.d/S80cassandra
rm -rf /etc/rc.d/rc1.d/K20cassandra
rm -rf /root/.cassandra
rm -rf /var/cache/dnf/cassandra-e96532ac33a46b7e
rm -rf /var/cache/dnf/cassandra.solv
rm -rf /var/cache/dnf/cassandra-filenames.solvx
rm -rf /run/systemd/generator.late/graphical.target.wants/cassandra.service
rm -rf /run/systemd/generator.late/multi-user.target.wants/cassandra.service
rm -rf /run/systemd/generator.late/cassandra.service
ОБНОВЛЕНИЕ 5: Эта проблема возникала при нашей Server установке CentOS, поэтому мы попытались Minimal Install затем. Удивительно, но проблема не возникла при минимальной установке. В настоящее время мы изучаем, в чем могут быть различия.
ОБНОВЛЕНИЕ 6: Мы попытались создать еще один сервер, на этот раз также выбрав установку Server установки CentOS. Удивительно, но проблема не возникла и на этом сервере, поэтому тип установки CentOS также не имел ничего общего с нашей проблемой.
Этим мы подтвердили, что виновата была наша установка Cassandra, хотя мы еще не уверены, что сделали так неправильно, что даже удаление и переустановка не смогли решить проблему на исходном сервере.
Возможно, наши действия по удалению, описанные выше, не были достаточно тщательными?
ОБНОВЛЕНИЕ 7: Оказывается, причина, по которой у новых серверов не было проблемы, заключается в том, что исходный сервер использовал настраиваемый ISO CentOS вместо ванильного. Один из членов нашей команды изучает, что отличает пользовательский ISO, и я буду обновлять этот вопрос, когда они обратятся к нам.
Большое спасибо всем, кто помог и нашел время, чтобы прочитать этот длинный вопрос, такдалеко!