Phil_K
Enthusiast
Enthusiast

Running cqlsh shell script from vROPS appliance

Jump to solution

Scripts:

#!/bin/bash

$VCOPS_BASE/cassandra/apache-cassandra-2.1.8/bin/cqlsh --ssl --cqlshrc  $VCOPS_BASE/user/conf/cassandra/cqlshrc

-e "cql_statement;"

This script is simple but it won't execute when I run it. It just enters the cqlsh shell. I've tried --execute, -f, ... There doesn't seem to be a lot of documentation around cqlsh commands. If anyone can offer up some advice that would be much appreciated.

Thanks

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Phil_K
Enthusiast
Enthusiast

This does the trick. Just had to add it to the end of the line. Problem is Cassandra won't delete on a non-primary key. So it will work just fine if you're not trying a delete statement that relies on a non-standard key.

#!/bin/bash

$VCOPS_BASE/cassandra/apache-cassandra-2.1.8/bin/cqlsh --ssl --cqlshrc  $VCOPS_BASE/user/conf/cassandra/cqlshrc -e "cql_statement;"

View solution in original post

0 Kudos
6 Replies
mark_j
Virtuoso
Virtuoso

What is the use case here?

We don't support interacting with Cassandra (or any of the other DBs) is any way, shape, or form other than using our APIs. We also don't support running non-VMware scripts, processes or executables on these appliances.

If you find this or any other answer useful please mark the answer as correct or helpful.
0 Kudos
Phil_K
Enthusiast
Enthusiast

VMware KB: VMware vRealize Operations Manager 6.1.x upgrade hangs if expired projects are present

It seems if VMware supports truncating a database to prevent a 'waiting on analytics' hangup on a node restart then you should also support inserting those projects back into the database. Your tier 1 support actually advised me to have our DBA do that on his/her own...so I don't know what you're going on about.

Aside from that, I need to delete expired projects on a weekly basis and I plan on doing so through a cron job. I'm doing this because expired projects can cause an upgrade or node restart to hang (per the KB title).

0 Kudos
Phil_K
Enthusiast
Enthusiast

Furthermore,

I am extremely tired of hearing how we should upgrade to 6.2 from 6.1 to avoid issues like this...Do you have any idea how nonsensical that sounds?

"go to the newest, least stable version of our product, that should fix your issues"

....

0 Kudos
mark_j
Virtuoso
Virtuoso

If GSS advised you to run a specific script, that is within the realm of support since it's coming from us and can be supported. That is completely different than doing something on your own, and I wouldn't recommend assuming you can add projects back in to the database because our KB gives guidance on deleting them to complete an upgrade. If you took a step back and looked at the situation, there just wouldn't be any way we could reasonable support/QE the product with regular customer-driven db changes (this is why our appliance is an appliance and not 'open').

We've historically never supported letting DBAs modify the databases of the appliances, and that is still our official default stance. Reason being, see that KB's Impact/Risk statement:  "Irreparable damage can occur if mistakes are made while making changes directly to the vRealize Operations Manager database. VMware strongly recommends taking a backup or a snapshot prior to using the steps noted in the workaround." If GSS tells your DBA to modify the vR Ops DBs on their own, I suggest you make your use case/intentions extremely clear to them and you get acknowledgement from them, then print+frame that e-mail when you get the 'go ahead'.

Another thing to consider. Throughout these upgrades, some of the DBs are changing (from v6.0.x, to 6.1.x, to 6.2.x, all involve db changes in the background). Migrations are happening and data is moving around to get to our planned 'end state' of how we want to architecture to look to allow future feature+capability. This is transparent to the customer, and if you hit the DBs manually to do things, you'll be trying to hit a moving target as you upgrade to 6.2.x. This has risk written all over the place, as these upgrades are considered internal and having customer-written scripts hitting the DBs could lead to unforeseen problems (for the product's stability AND the customer trying to do things).

If you find this or any other answer useful please mark the answer as correct or helpful.
0 Kudos
Phil_K
Enthusiast
Enthusiast

Right, and I totally understand that point of view. But I don't understand how you can recommend one of your customers truncate a table in a database and not inform them of how to put that data back into the table through a similar programmatic method. What if I had hundreds of projects for capacity planning? I don't think the proper answer is, "use the GUI". This is a production database, there is no room to sit and spend hours and hours putting this data back in. It's just a poor answer.

But that's one of my main issues with VMware. The current maturity level of support is very lackluster. On the one hand you have people like me who are troubleshooting these projects and basically relying on numerous support tickets to get simple things done because the documentation and user-experience either doesn't exist or isn't very well supported by VMware. On the other hand you have people who probably don't upgrade because it's not worth the trouble.

But anyhow, I figured it out, problem is Cassandra won't allow me to delete on a non-primary key. Not the end of the world though, I'll just have to name all of the columns.

0 Kudos
Phil_K
Enthusiast
Enthusiast

This does the trick. Just had to add it to the end of the line. Problem is Cassandra won't delete on a non-primary key. So it will work just fine if you're not trying a delete statement that relies on a non-standard key.

#!/bin/bash

$VCOPS_BASE/cassandra/apache-cassandra-2.1.8/bin/cqlsh --ssl --cqlshrc  $VCOPS_BASE/user/conf/cassandra/cqlshrc -e "cql_statement;"

0 Kudos