I tried running cockroach --v and got an unknown flag error. What’s the command to find out which version of Cockroach I’m running?
cockroach version returns the version of CockroachDB available from the command line. However, it's important to note that you can upgrade the binary in your path, but the actual cockroach service running on the server can be older.
To upgrade the server, you'll need to restart cockroach (cockroach quit then cockroach start using the newer binary). If you’re doing this in production, you can take the nodes offline one by one without compromising your availability (assuming you’re running a load balanced cluster and aren’t treating a single node as the only target of your client).
"cockroach version" will give you the executable version (I would say). If you need something from the database itself, you could run the following query:
select version();
It looks like this:
$> /bin/cockroach sql <connection strings> --database=postgres --execute "select version();"
version
--------------------------------------------------------------------------------------------
CockroachDB CCL v21.1.6 (x86_64-unknown-linux-gnu, built 2021/07/20 15:30:39, go1.15.11)
(1 row)
Time: 2ms
$>
This works in both CockroachDB and PostgreSQL.
I hope this helps... ^_^
Related
I am using PostgreSQL 13 Beta 3 on (windows.8/*64bit). I want to add timescaledb extension. My "postgresql.conf" directory is correct but every time i try to install the extension, I get a message which is attached.
I had also changed Environment Address to "C:\Program Files\PostgreSQL\13\bin" [The address of pg_config.exe", but nothing changed. Is there a possibility that i have to use from postgreSQL V.12 as mentioned in the installation instruction? enter image description here
Thank you in advance for your help and guide
You cannot to do it. Timescale doesn't support Postgres 13 yet. Postgres 13 was not releases yet - there only test releases are available.
PostgreSQL extensions should be compiled for specific Postgres major version. So you cannot to use timescale for Postgres 12 or Postgres 11 for Postgres 13.
It's not ready yet. It's expected on the upcoming TimescaleDB v2.0.1. Read more at their release notes: https://docs.timescale.com/latest/release-notes.
I have got two versions installed in WebSphere Application Server ( version 6 and version 8 ). I need to find whether my Websphere servers are active on version 6 or version 8 currently from backend ( UNIX ) ?
Please don't suggest ps -ef | grep java, because it does not show the processes of servers in case the servers are not running. I want a solution that works irrespective of whether servers is running or not.
Both releases have bin/bersionInfo.sh (or .bat on Windows).
Is the issue here that you know where the separate v6 and v8 installations are on the file system, but you simply want to know which of them is active? If so, use the serverStatus.sh|bat script - call it against your WAS 6 server, then call it against your WAS 8 server, and you'll know which is active.
Alternately, you could use ps -ef|grep java and check the PID against the pid file in your server's logs directory.
Consult `/properties/version/profile.version. Since you seem to know the location of the profile on disk but not whether it will be running or not, this file will indicate what version of WAS it was created by. Profiles can only be owned by the version of WebSphere they were created by, so this should be the version the profile will run with when started.
I have an old version of greenplum and I would like to upgrade to version 5.0.0 since it has been released. https://github.com/greenplum-db/gpdb/releases/tag/5.0.0.
I have a huge machine, and I can not simply have an equivalent one. So I would like to know how can I run both version on the same machine. I have seen for example gpseginstall distribute binaries to the /usr/local/gpdb which is already there for the old version.
Regards
I have run multiple versions in parallel on a single node system.
You need to set your config file you use for the gpinitsystem for different segment/mirror directories, master port, starting port, etc..
You will also need two different OS profiles to source, so when you log as gpadmin you can source your 4.3 or 5.0 paths ($GPHOME, $MASTER_DATA_DIRECTORY) for gpstart, gpstop, psql, etc..
Hope this makes sense... I haven't tried it on a multi node system, but the setup should be the same
i.e.
GPDB 4.3
ARRAY_NAME="GPDB"
MACHINE_LIST_FILE=./hostsfile
SEG_PREFIX=seg
PORT_BASE=40000
declare -a DATA_DIRECTORY=(/gpsegment4 /gpsegment4 /gpsegment4 /gpsegment4)
MASTER_HOSTNAME=mdw
MASTER_DIRECTORY=/gpmaster4
MASTER_PORT=5432
TRUSTED_SHELL=ssh
CHECK_POINT_SEGMENTS=8
ENCODING=UNICODE
DATABASE_NAME=gpadmin
#MIRROR_PORT_BASE=50000
REPLICATION_PORT_BASE=41000
#MIRROR_REPLICATION_PORT_BASE=51000
#declare -a MIRROR_DATA_DIRECTORY=(/mirror4 /mirror4 /mirror4 /mirror4)
GPDB 5.0
ARRAY_NAME="GPDB"
MACHINE_LIST_FILE=./hostsfile
SEG_PREFIX=seg
PORT_BASE=60000
declare -a DATA_DIRECTORY=(/gpsegment5 /gpsegment5 /gpsegment5 /gpsegment5)
MASTER_HOSTNAME=mdw
MASTER_DIRECTORY=/gpmaster5
MASTER_PORT=7432
TRUSTED_SHELL=ssh
CHECK_POINT_SEGMENTS=8
ENCODING=UNICODE
DATABASE_NAME=gpadmin
#MIRROR_PORT_BASE=70000
REPLICATION_PORT_BASE=61000
#MIRROR_REPLICATION_PORT_BASE=71000
#declare -a MIRROR_DATA_DIRECTORY=(/mirror5 /mirror5 /mirror5 /mirror5)
I have seen where you can have different versions installed, then change the greenplum-db link to point to the one you want to run. That link is referenced when you enter gpstart. Not sure how you could have two different versions running at the same time on the same machine.
If your goal is to do upgrade dry runs and test on the new release, another alternative could be to deploy a Greenplum cluster using Microsoft Azure. This would deploy the latest version (5.0).
Sounds like you know how to build your own greenplum so you could delete that 5.0 install then install the version you are currently using, then practice the upgrade/migration as well as just kick the tires of 5.0.
You could also easily have side by side systems in Azure; one running your current release and the other running 5.0.
The smallest cluster you can deploy is 1 master and 1 segment which could be adequate depending on your requirements.
Hope this helps
ERROR [main] 2017-08-04 13:24:21,949 CassandraDaemon.java:638 - Detected unreadable sstables /opt/cassandra/data/some_key_space/ep_lc_events-adc44160dbe611e6953689bcd3ed73aa/mc-547-big-Summary.db, and many others...
That has happened after I upgraded Cassandra to 3 version and after a while downgraded it to 2nd version.
When I run this command: sudo service cassandra status
I have got such message:
could not access pidfile for Cassandra
In /var/log/cassandra/system.log I have logs which I wrote at the beginning.
PS: let me pay your attention that everything is happening on EC2 Amazon instance.
Well, I have just upgraded back to 3rd version, used cassandra-unloader to export all data, then downgraded back to 2nd version and used cassandra-loader to import all data. But if you were lucky and had backups and snapshots it would not be an obstacle for you.
PS. Afterwards, I had to run this command nodetool resetlocalschema to reset local schema and resynchronize.
PPS. This you can find how to do that.
https://github.com/brianmhess/cassandra-loader
I also got the same error, but it was due to switching between cassandra 4.0.0 and version 3.11 and back again while using docker.
Update the version to the right one for the ssltable, or delete the data volume:
docker-compose logs cassandra
docker volumes ls
docker ps
docker-compose down
docker volume rm testapp_cassandra
docker volume ls
docker-compose up
I have a test suite that runs on Travis-CI and requires MariaDB (but it breaks on MySQL). The pre-test scripts call the mysql command, but run commands against MariaDB, as the command is the same for both.
echo "CREATE DATABASE test1" | mysql -u travis
The tests on worker v2.5.0 were passing just fine (https://travis-ci.org/stems/join-monster/jobs/256751422). However, the tests started running on a later version of the worker v2.9.3 and failing without any changes to the code (https://travis-ci.org/stems/join-monster/jobs/260001701). According to the system build information, this new version seems to be installing MySQL in addition to MariaDB. Now when I run my mysql command, it's running against MySQL instead of MariaDB and breaking the build.
I need either:
to go back to a previous version of the worker (can't find any info on how to do this in the Travis docs.
to specify that I want to run commands and connect to MariaDB, NOT MySQL.
to tell Travis to not install MySQL to avoid the clashing
Any of these solutions would be appreciated.
Fixed it by switching the Ubuntu version back to 12 rather than 14, which had become the new default.
In the .travis.yml
dist: precise