Technical troubleshooting and more

Hi, when trying to install Graphite component using docker I faced this error: docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?. I was bit struggling to understand what does it mean, apparently it's not a permission issue or any kind of other OS issues  it's just because I've reinstalled  docker on unclean old installation of it the solution here is so simple: restart docker service and re-run the component installation  [root@VerticaNode01 ~]# service docker stop Redirecting to /bin/systemctl stop docker.service You have new mail in /var/spool/mail/root [root@VerticaNode01 ~]# service docker start Redirecting to /bin/systemctl start docker.service [root@VerticaNode01 ~]# [root@VerticaNode01 ~]# [root@VerticaNode01 ~]# docker run -d --name graphite --restart=always -p 80:80 -p 2003-2004:2003-2004 -p 2023-2024:2023-2024 -p 8125:8125/udp -p 8126:8126 graphiteapp/graphite-...

Hi All, Sometimes, especially working on virtual environments, file system can become "read only" to protect from corruptions and other failures if Vertica nodes data/catalog file systems become read only, you probably face this error after trying to restart the cluster and even the spread The solution for was to fix "read only" issues (even with just restarting the VM for most of the cases)  then start Vertica with the latest good epoch this error: vertica 4803 error: no such file or directory will appear in the spread log (dbLog)

when trying to create a resource pool using some % of the total CPUs you may encounter this error: Vertica Request for 10% percent of 4 CPUs rounds to zero CPUs \n (6006) (SQLExecDirectW) why? since 10% of 4, rounded by vertica to 0. and you can allocate 0 CPUs to a resource pool how to fix: fix % to be at least 25% or use static allocation of CPU set to a resource pool

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is Please contact your system administrator. Add correct host key in /home/user/.ssh/known_hosts to get rid of this message. Offending RSA key in /home/user/.ssh/known_hosts:[] RSA host key for 192.168.0.10 has changed and you have requested strict checking. Host key verification failed. this can happen when you try to recreate the same machine again with the same IP but with different key, in this case you need to remove the record of the destination server from your local  known_hosts server and then you can re log...

After trying to run a failed upgrade to Vertica DB (network issues) we run into a situation that  /opt/vertica/config folder permissions turns to root:root we couldn't run even admintools to see what's going on then we realized it's a permission issues on the config folder in order to fix it - simply change this folder permissions chown -R dbadmin:verticadba /opt/vertica/config good luck!

in our case I was trying to add 5 nodes to Vertica 10 nodes cluster. while adding the new nodes we were facing some problems with the file system and we were forced to terminate the new machines. we fixed the VM image and recreated the nodes in order to scale out Vertica cluster again. during this process we were keep getting an errors message like: "node x already exists" while running the add nodes command (although we removed them from admintools.conf and from the cluster using: /opt/vertica/sbin/install_vertica --remove-hosts) finally, we found out a solution that was very helpful in our case and is not documented well in Vertica documentation, (we were not able to find it there) drop node command. DROP NODE <node_name>;   probably leftovers of the first scale out run were stayed in the database metadata itself, I guess that when we terminated the new nodes after the first try we didn't notice that one of the nodes were still part of the cluster...

when running Vertica vnetperf utility you may face these errors below although you have no FW between servers and the communication is OK and no network errors are observed Vertica DB is up and running on these Vertica hosts as well [Connector Thread 172.16.8.11 ] Couldn't connect to 172.16.8.11 (family 2, attempt 0): Connection refused; errno=111 (Connection refused) [Connector Thread 172.16.8.10 ] Couldn't connect to 172.16.8.10 (family 2, attempt 0): Connection refused; errno=111 (Connection refused) [Connector Thread 172.16.8.12 ] Couldn't connect to 172.16.8.12 (family 2, attempt 0): Connection refused; errno=111 (Connection refused) [Connector Thread 172.16.8.11 ] Could not find anything to connect to for 172.16.8.11; errno=111 (Connection refused) [Connector Thread 172.16.8.10 ] Could not find anything to connect to for 172.16.8.10; errno=111 (Connection refused) [Connector Thread 172.16.8.12 ] Could not find anything to connect to for 172.16.8.12; err...