Start Free Trial   Support

Cassandra Advanced Settings

Connecting to the Server

Set the Server and Database connection properties to connect to Cassandra.

To connect to a distributed system, you can set Server to a comma-separated list of servers and ports, separated by colons. You will also need to set ConsistencyLevel.

The following sections detail connection properties for authentication, security, and data access. 

Connecting to CosmosDB with the Cassandra API

To obtain the connection string needed to connect to a Cosmos DB account using the Cassandra API, log in to the Azure Portal, select Azure Cosmos DB, and select your account. In the Settings section, click Connection String and set the following values.

  • Server: Set this to the Host value, the FQDN of the server provisioned for your account. You can also specify the port here or in Port.
  • Port: Set this to the port.
  • Database: Set this to the database you want to read from and write to.
  • User: The Cosmos DB account name.
  • Password: The account key associated with the Cosmos DB account.

Securing Cassandra Connections

You can set UseSSL to negotiate SSL/TLS encryption when you connect. By default, the provider attempts to negotiate SSL/TLS by checking the server's certificate against the system's trusted certificate store. To specify another certificate, see the SSLServerCert property for the available formats to do so.

Authenticating to Cassandra

The provider supports Basic authentication with login credentials and the additional authentication features of DataStax Enterprise (DSE) Cassandra. The following sections detail connection properties your authentication method may require.

You need to set AuthScheme to the value corresponding to the authenticator configured for your system. You specify the authenticator in the authenticator property in the cassandra.yaml file. This file is typically found in /etc/dse/cassandra. or through the DSE Unified Authenticator on DSE Cassandra.

Basic Authentication

Basic authentication is supported through Cassandra's built-in default PasswordAuthenticator.

  • Set the AuthScheme property to 'BASIC' and set the User and Password properties.
  • In the cassandra.yaml file, set the authenticator property to 'PasswordAuthenticator'.

Kerberos Authentication

Kerberos authentication is supported through DataStax Enterprise Unified Authentication.

  • Set the AuthScheme property to 'KERBEROS' and set the User and Password properties.
  • Set the KerberosKDC, KerberosRealm, and KerberosSPN properties.
  • In the cassandra.yaml file, set the authenticator property to "com.datastax.bdp.cassandra.auth.DseAuthenticator".
  • Modify the authentication_options section in the dse.yaml file, specifying the default_schema and other_schemas properties as 'kerberos'.
  • Modify the kerberos_options section in the dse.yaml file, specifying the keytab, service_principle, http_principle and qop properties

LDAP Authentication

LDAP authentication is supported through DataStax Enterprise Unified Authentication.

  • Set the AuthScheme property to 'LDAP' and set the User and Password properties.
  • In the cassandra.yaml file, set the authenticator property to "com.datastax.bdp.cassandra.auth.DseAuthenticator".
  • Modify the authentication_options section in the dse.yaml file, specifying the default_schema and other_schemas properties as 'ldap'.
  • Modify the ldap_options section in the dse.yaml file, specifying the server_host, server_port, search_dn, search_password, user_search_base, and user_search_filter properties

Using PKI

You can specify a client certificate to authenticate the provider with SSLClientCert, SSLClientCertType, SSLClientCertSubject, and SSLClientCertPassword.

Using Kerberos

This section shows how to use the provider to authenticate to Cassandra using Kerberos.

Authenticating with Kerberos

To authenticate to Cassandra using Kerberos, set the following properties:

  • AuthScheme: Set this to NEGOTIATE
  • KerberosKDC: Set this to the host name or IP Address of your Kerberos KDC machine.
  • KerberosSPN: Set this to the service and host of the Cassandra Kerberos Principal. This will be the value prior to the '@' symbol (for instance, hbase/MyHost) of the principal value (for instance, hbase/MyHost@EXAMPLE.COM).

Retrieve the Kerberos Ticket

You can use one of the following options to retrieve the required Kerberos ticket.

MIT Kerberos Credential Cache File

This option enables you to use the MIT Kerberos Ticket Manager or kinit command to get tickets. Note that you won't need to set the User or Password connection properties with this option.

  1. Ensure that you have an environment variable created called KRB5CCNAME.
  2. Set the KRB5CCNAME environment variable to a path pointing to your credential cache file (for instance, C:\krb_cache\krb5cc_0 or /tmp/krb5cc_0). This file will be created when generating your ticket with MIT Kerberos Ticket Manager.
  3. To obtain a ticket, open the MIT Kerberos Ticket Manager application, click Get Ticket, enter your principal name and password, then click OK. If successful, ticket information will appear in Kerberos Ticket Manager and will now be stored in the credential cache file.
  4. Now that the credential cache file has been created, the provider will use the cache file to obtain the kerberos ticket to connect to Cassandra.

As an alternative to setting the KRB5CCNAME environment variable, you can directly set the file path using the KerberosTicketCache property. When set, the provider will use the specified cache file to obtain the kerberos ticket to connect to Cassandra.

Keytab File

If the KRB5CCNAME environment variable has not been set, you can retrieve a Kerberos ticket using a Keytab File. To do this, set the User property to the desired username and set the KerberosKeytabFile property to a file path pointing to the keytab file associated with the user.

User and Password

If both the KRB5CCNAME environment variable and the KerberosKeytabFile property have not been set, you can retrieve a ticket using a User and Password combination. To do this, set the User and Password properties to the user/password combo that you use to authenticate with Cassandra.

Cross-Realm Authentication

More complex Kerberos environments may require cross-realm authentication where multiple realms and KDC servers are used (e.g. where one realm/KDC is used for user authentication and another realm/KDC used for obtaining the service ticket).

In such an environment, the KerberosRealm and KerberosKDC properties can be set to the values required for user authentication. The KerberosServiceRealm and KerberosServiceKDC properties can be set to the values required to obtain the service ticket.

Accessing NoSQL Tables

The provider implements Automatic Schema Discovery that is highly configurable. The following sections outline the provider's defaults and link to ways to further customize.

Flattening Nested JSON

By default, the provider projects columns over the properties of objects, including objects nested in objects. Arrays are returned as JSON strings, by default. You can use the following properties to access array elements, including objects nested in arrays.

  • FlattenArrays: Set this property to the number of array elements that you want to return as column values. You can also use this property with FlattenObjects to extract the properties of objects nested in arrays.
  • FlattenObjects: By default, this is true; that is, the properties of objects and nested objects are returned as columns. When you set FlattenArrays, objects nested in the specified array elements are also flattened and returned as columns.

Fine Tuning Data Access

You can use the following properties to gain greater control over Cassandra API features and the strategies the provider uses to surface them:

  • AllowFiltering: Set this property to allow the server to process slow-performing searches.
  • UseJsonFormat: Set this property to use CQL literals instead of JSON.
  • QueryPassthrough: This property enables you to use native CQL statements instead of SQL.
  • RowScanDepth: This property determines the number of rows that will be scanned to detect column data types when generating table metadata. This property applies if you are working with the dynamic schemas generated from Automatic Schema Discovery or if you are using QueryPassthrough.

Connecting Through a Firewall or Proxy

To connect set FirewallType, FirewallServer, and FirewallPort. To tunnel the connection, set FirewallType to TUNNEL. To authenticate set FirewallUser and FirewallPassword. To authenticate to a SOCKS proxy, additionally set FirewallType to SOCKS5.

Troubleshooting the Connection

To show provider activity from query execution to network traffic, use Logfile and Verbosity. The examples of common connection errors below show how to use these properties to get more context. Contact the support team for help tracing the source of an error or circumventing a performance issue.

  • Authentication errors: Typically, recording a Logfile at Verbosity 4 is necessary to get full details on an authentication error.
  • Queries time out: A server that takes too long to respond will exceed the provider's client-side timeout. Often, setting the Timeout property to a higher value will avoid a connection error. Another option is to disable the timeout by setting the property to 0. Setting Verbosity to 2 will show where the time is being spent.