Using DataStax OpsCenter v5.2.4 (currently the latest) installed using AMI ami-8f3e2bbf provided by DataStax and following DataStax's instructions on how to create a cluster on EC2, all DSE nodes fail during creation with this error:
Install Errored: Could not find a matching version for package dse-libpig
Is there a work around for this?
Note that during the process I selected Package: DataStax Enterprise 4.8.1, which is the latest available in the list at this time.
I faced the same issue and taking a clue from BrianC's comment resolved by removing a trailing '#' in my datastax account password
Related
I needs to upgrade Cassandra dse version 4.8.16 to 6.0.6 for my Cassandra cluster. Please provide me steps to do it.
I did exactly same thing.
But it is not possible directly:
You must upgrade DSE from 4.8.16 to 5.0.15 & run sstableupgrade in the end.
1 Problem in doing above: you must move all you client applications to CQL from thrift(if any). However documentation says: it is ok to have Thrift in 5.0.15 but that is not correct(specially for my case).
Once you are on DSE 5.0.15 you can jump directly to DSE 6.0.6 or DSE 6.7.2 as per this link. Here also you need to run sstableupgrade.
In whole upgrade process, you need to take care of Driver's compatibility.
The DataStax Opscenter LifeCycle Manager only seems to have an option to run an 'install' job. Looking at the language, it seems to be only to provision new nodes.
Can LifeCycle Manager be used to upgrade existing (managed) clusters to newer version of Datastax enterprise?
Edit 2018-05 OpsCenter 6.5.0 has been released and provides assistance in the process of upgrading DSE between patch releases... aka going from DSE 5.0.3 to 5.0.6. Docs and https://docs.datastax.com/en/opscenter/6.5/opsc/LCM/opscLCMjobsOverview.html and https://docs.datastax.com/en/opscenter/6.5/opsc/LCM/upgradeDSEjob.html.
DataStax engineer here, I work on Lifecycle Manager. Currently LCM cannot help you upgrade nodes, and while I'm not able to share information about future roadmap and unreleased features, I can say we know that customers want to use LCM for upgrades and we agree that it would be a valuable feature.
As of OpsCenter 6.1.x, you must manually upgrade your nodes, and then update your LCM configs to match the new versions. From that point onward you can use LCM for install/config jobs in the upgraded cluster. This isn't a detailed howto, but broadly:
Review the upgrade guide so you know what needs to be done: https://docs.datastax.com/en/upgrade/doc/upgrade/datastax_enterprise/upgrdDSE.html
Perform the upgrade manually, outside of LCM. Note that if you use apt to manage packages, and are not upgrading the very most recent version available, you'll have to use a pretty giant apt-command in order to work around a dependency resolution in apt when upgrading to an "old" version. The resulting command will look something like: apt-get install -y -qq -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold dse-pig=5.0.11-1 dse-libhadoop2-client=5.0.11-1 dse-libspark=5.0.11-1 dse-libhadoop-native=5.0.11-1 dse-libmahout=5.0.11-1 dse-hive=5.0.11-1 dse-libpig=5.0.11-1 dse-libsolr=5.0.11-1 dse-libgraph=5.0.11-1 dse-libtomcat=5.0.11-1 dse-libhadoop=5.0.11-1 dse-libhive=5.0.11-1 dse-full=5.0.11-1 dse-libcassandra=5.0.11-1 dse=5.0.11-1 dse-libsqoop=5.0.11-1 dse-libhadoop2-client-native=5.0.11-1 dse-liblog4j=5.0.11-1
Once the manual upgrade is complete, you'll temporarily be in a position where LCM jobs cannot run successfully, since the version of DSE installed does not match the version of DSE that LCM is configured to deploy. At this point LCM jobs will fail with a DSE version mismatch error. To fix this, proceed...
Clone your configuration profile (which is associated with your old dse version) to a new CP using the new DSE version. If you're doing a patch upgrade, this will be pretty simple. If you're doing a major upgrad via the API, you need to be very careful to remove config parameters that DSE no longer supports.
Edit your cluster model so that the cluster, plus any datacenters or nodes with CP's defined use your newly cloned CP for your current datastax version instead of your old cp for your old datastax version. At this point, you can brought LCM back into sync with your cluster. You can proceed to run install/configure jobs again.
Not a simple procedure, but it is possible to upgrade your cluster outside of LCM and then sync lcm up with the new config so you can continue managing it from there. As previously noted, we understand this is not a simple process and understand that there's significant value in providing LCM upgrades natively.
I am trying to upgrade the cassandra version from the 3.0.8 to 3.0.14. I am adding a new node with 3.0.14 version to 3.0.8. cluster and I see the schema disagreement between the nodes and the new node doesn't stream any data.
I am looking at : https://issues.apache.org/jira/browse/CASSANDRA-13559, does this mean, I will not be able to add nodes with the higher version than 3.0.13?
here is what I see in the nodetool describecluster output
$ nodetool describecluster
Cluster Information:
Name: production
Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Schema versions:
45ad6427-30a8-3381-9e2c-266b446c6ea7: [192.168.1.2, 192.168.1.3, 192.168.1.4]
c2a2bb4f-7d31-3fb8-a216-00b41a643650: [10.10.1.10]
Any work around to mitigate this?
Did you run nodetool upgradesstables?
As far as I know, you can't add nodes of different versions to an existing cluster. You have to upgrade the existing nodes in place using a rolling upgrade. Check out this SO question or this doc which detail the steps to do a rolling upgrade.
This is a tad late but I ran into this previously too.
see https://github.com/apache/cassandra/blob/cassandra-3.0/NEWS.txt#L166 for release notes specific to 3.0.14.
you need a temporary flag: -Dcassandra.force_3_0_protocol_version=true on the 3.0.14 nodes to enable communication between these two versions. There is an gossip incompatibility that causes the schema not to be pulled during bootstrap. You should remove this flag after upgrading the entire cluster and do another rolling restart
I would guess that in the debug logs you would find a line like "shouldPullSchema returned false" due to this incompatibility.
First I had DataStax 3.7 installed and everything was fine but later I have downgraded to 2.2 and now I have reinstalled datastax 3.7 but i can't see it in services. I can open my datastax and connect to external clusters but I can't start my cassandra server and so Can't connect to local host.
How to solve this issue?
Thanks!
I've having some issues with my Cassandra cluster and I would like to install OpsCenter Community in order to debug what's going on.
I've found this and this pages talking about the compatibility between DataStax OpsCenter and Cassandra, but this don't list Cassandra 2.2.5 (actually I'm using DataStax Cassandra - dsc 22).
My question is: can I use DataStax OpsCenter (free / community version) within Cassandra 2.2.5? If not, there's an alternative?
No, the docs you cited indicate that OpsCenter doesn't support any cassandra greater than 2.1.x and the next version of opscenter (6.x) will only support Datastax Enterprise. I don't know of another visual front-end to cassandra at this time.