[
https://issues.apache.org/jira/browse/CASSANDRA-17367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499462#comment-17499462
]
Dmitry Potepalov commented on CASSANDRA-17367:
----------------------------------------------
> we could just go back to legacy here
I tried this first. This test actually did not do any streaming, because the
schema was not created in the target cluster
{noformat}
[junit-timeout] Opening sstables and calculating sections to stream
[junit-timeout] Skipping file na-1-big-Data.db: table
legacy_tables.legacy_na_clust doesn't exist
[junit-timeout] INFO [main] <main> 2022-03-01 11:55:23,639
StreamResultFuture.java:92 - [Stream
#1850f3a0-994e-11ec-b67d-cd751ea3eb05|#1850f3a0-994e-11ec-b67d-cd751ea3eb05]
Executing streaming plan for Bulk Load
[junit-timeout]
[junit-timeout] Summary statistics:
[junit-timeout] Connections per host : 1
[junit-timeout] Total files transferred : 0
{noformat}
So I created necessary keyspaces/tables, started streaming and then got this
error
{noformat}
[junit-timeout] Opening sstables and calculating sections to stream
[junit-timeout] INFO [main] <main> 2022-03-01 12:02:59,470 BufferPools.java:49
- Global buffer pool limit is 247.000MiB for chunk-cache and 61.000MiB for
networking
[junit-timeout] ERROR 11:02:59 Cannot open
/home/dmitry.potepalov/apache_cassandra/test/data/legacy-sstables/na/legacy_tables/legacy_na_clust/na-1-big;
partitioner org.apache.cassandra.dht.ByteOrderedPartitioner does not match
system partitioner org.apache.cassandra.dht.Murmur3Partitioner. Note that the
default partitioner starting with Cassandra 1.2 is Murmur3Partitioner, so you
will need to edit that to match your old partitioner if upgrading.
{noformat}
I verified that the legacy sstables were indeed created with
ByteOrderedPartitioner and decided that using legacy sstables is not
particulary important in the context of the test, so ended up using the
generated ones.
If I was wrong and using legacy sstables is important in this test, could you
please provide some guidance as to how resolve the partitioner error? I don't
know Cassandra very well, I simply assumed that streaming
ByteOrderedPartitioner sstables to a cluster using the Murmur3Partitioner is
not possible - maybe I'm wrong and there's some necessary configuration that
I'm missing? I remember trying to force ByteOrderedPartitioner on the test
cluster, but that failed somehow, don't have the exact error message - should I
try it again?
> sstableloader ignores streaming encryption settings
> ---------------------------------------------------
>
> Key: CASSANDRA-17367
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17367
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
> Reporter: Dmitry Potepalov
> Assignee: Dmitry Potepalov
> Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 17367-4.0.txt, 17367-trunk.txt
>
>
> Reproducible in Cassandra 4.x. If one configures encryption for streaming in
> config yaml fed to sstableloader like this
> {{server_encryption_options:}}
> {{ internode_encryption: all}}
> {{ keystore: sstableloader.keystore.p12}}
> {{ keystore_password: changeit}}
> {{ truststore: sstableloader.truststore.jks}}
> {{ truststore_password: changeit}}
> then sstableloader should perform an SSL handshake on the streaming
> connections and encrypt the payload. But this does not happen. Judging by the
> TCPdump of the outgoing traffic on the internode port, sstableloader sends
> plaintext traffic. This is the TCP payload of the first packet that
> sstableloader sends after establishing TCP connection:
> {{ca 55 2d fa 0c 0c 0c 08 06 0a f0 01 f9 1b 58 a8 32 f2 d0}}
> The first 4 bytes look like Cassandra protocol magic, not like a client hello.
> I've discovered the issue while trying to migrate some data to a Cassandra 4
> listening on the legacy ssl storage port (therefore, accepting only encrypted
> connections on that port). Streaming phase of the migration failed with a
> "connection closed" error, which hints that the connection was closed
> server-side.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
