DataStax AMI по умолчанию cassandra.yaml не достигает согласованности 2?

Question

Я установил Datastax AMI, который использует EC2Snitch. Конфигурации
listen_address: частный IP
широковещательный адрес: такой же, как адрес прослушивания
rpc_address: 0.0.0.0
broadcast_rpc: приватный ip
семена: частный IP

У меня есть 2 таких случая, но я не могу достичь согласованности два. дает в живых: 1, хотя оба экземпляра работают. Я хочу добиться согласованности два от любого клиента
Я попробовал это:
broadcast_rpc: public_ip // та же ошибка
rpc_addess: public ip //cassandra не запустится. пожаловался бы 127.0.0.1:9042 не работает
Какая правильная конфигурация? Узлы находятся в одном регионе, в одной стойке. nodetool выдает как запущенный, так и работающий.

system.peers предоставляет приватный ip в столбцах peer и roc_address, а также null в предпочитаемом ip.

Cassandra.yaml

имя_кластера: 'logcluster'
num_tokens: 256
hinted_handoff_enabled: true
max_hint_window_in_ms: 10800000 # 3 часа
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 2
batchlog_replay_throttle_in_kb: 1024
аутентификатор: AllowAllAuthenticator
автор: AllowAllAuthorizer
permissions_validity_in_ms: 2000
разделитель: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directories:
- / mnt / cassandra / data
директория commitlog_direct: /mnt/cassandra/ commitlog
disk_failure_policy: остановка
commit_failure_policy: остановка
key_cache_save_period: 14400
row_cache_size_in_mb: 0
row_cache_save_period: 0
counter_cache_size_in_mb:
counter_cache_save_period: 7200
Сохраненный_каталог_каталогов: /mnt/cassandra/ сохраненный_катесов
commitlog_sync: периодический
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 32
seed_provider:
- имя_класса: org.apache.cassandra.locator.SimpleSeedProvider
параметры:
- семена: "10.xxx.xx.xx7"
concurrent_reads: 32
concurrent_writes: 32
concurrent_counter_writes: 32
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: false
trickle_fsync_interval_in_kb: 10240
Storage_port: 7000
ssl_storage_port: 7001
адрес для прослушивания: 10.xxx.xx.xx5
start_native_transport: true
native_transport_port: 9042
start_rpc: правда
rpc_address: 0.0.0.0
rpc_port: 9160
широковещательный_адрес: 10.xxx.xx.xx5
rpc_keepalive: правда
rpc_server_type: sync
thrift_framed_transport_size_in_mb: 15
incremental_backups: false
snapshot_before_compaction: false
auto_snapshot: true
tombstone_warn_threshold: 1000
tombstone_failure_threshold: 100000
column_index_size_in_kb: 64
batch_size_warn_threshold_in_kb: 5
compaction_throughput_mb_per_sec: 16
sstable_preemptive_open_interval_in_mb: 50
read_request_timeout_in_ms: 5000
range_request_timeout_in_ms: 10000
write_request_timeout_in_ms: 2000
counter_write_request_timeout_in_ms: 5000
cas_contention_timeout_in_ms: 1000
truncate_request_timeout_in_ms: 60000
request_timeout_in_ms: 10000
cross_node_timeout: false
phi_convict_threshold: 12
endpoint_snitch: Ec2Snitch
dynamic_snitch_update_interval_in_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
dynamic_snitch_badness_threshold: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption: нет
хранилище ключей: conf /.keystore
keystore_password: Кассандра
склад доверенных сертификатов: conf /.truststore
truststore_password: Кассандра
client_encryption_options:
включено: ложь
хранилище ключей: conf /.keystore
keystore_password: Кассандра
internode_compression: все
inter_dc_tcp_nodelay: false
auto_bootstrap: false

Датацентр: США-Восток
===================
Статус = Up / Down
| / Состояние = Нормальный / Выход / Присоединение / Переезд
- Владельцы токенов загрузки адресов (эффективные)

ООН 10.xxx.xx.xx7 98,21 МБ 256 53,9% d5xxxx-0a59-xxxx-xxx-ab59xxxxx 1d
ООН 10.xxx.xx.xx5 50,26 МБ 256 46,1% 1xxxxff-xxx-xxx-xxx-13edxxxxxcf 1d

Answer 1

Узлы Amazon будут показывать частный ip 10.xyz в ifconfig, общедоступные IP-адреса не известны самому узлу, вместо этого эти адреса помечаются NAT (преобразование сетевых адресов).

Таким образом, узлы должны сплетничать в сети 10.xyz, как вы можете видеть из вывода nodetool.

Наилучшим подходом является проверка ошибки, которую вы видите в cqlsh при попытке чтения / записи на желаемом уровне согласованности, это должно помочь вам лучше разобраться в проблеме. Также проверьте фактор репликации в вашем пространстве ключей, например:

CREATE KEYSPACE spam WITH replication = {
  'class': 'SimpleStrategy',
  'replication_factor': '2'
};

В приведенном выше примере коэффициент репликации равен 2. Если у вас есть два узла и вы читаете с уровнем согласованности 1, есть изменение, которое может привести к неправильным результатам. Как общее практическое правило, рекомендуется всегда писать с более высоким уровнем согласованности, чем вы читаете. Чтобы установить согласованность в cqlsh, используйте этот синтаксис:

cqlsh> CONSISTENCY ONE;
Consistency level set to ONE.

Надеюсь это поможет