After deploying to AWS via CloudFormation, I connected to one of the servers via SSH and ran ysqlsh and got the following:
ysqlsh: FATAL: Not found: Error loading table with oid 1260 in database with oid 1: The object does not exist: table_id: "000000010000300080000000000004ec"
After some research, I saw that others had to run the initdb command again...so I went ahead and tried that but with no success.
@christopa , What was the version of yugabyte db that you used?
Good question...I just assumed it was the latest version, but looks like its not.
I deployed to AWS Cloudformation according to the following documentation at https://docs.yugabyte.com/latest/deploy/public-clouds/aws/
Looking at the yaml file, it looks like its using v1.2.8. Is there a way to get v1.3 via a cloudformation file?
@ramkumarvs
a) Can you help answer this question on how to update the release used by the template?
b) Additionally, in the cloud formation template, is the option to enable YSQL using the fast path initialization for initdb. We no longer need the explicit init db step. In the 1.3.x versions, the yb-master and yb-tserver need to simply be started with the right gflags to enable YSQL. The gflags are: --enable_ysql (for yb-master) and --start_pgsql_proxy --pgsql_proxy_bind_address <ip> (for yb-tserver)?
@christopa hi, we need to update few things in our cloudformation scripts in order for you to install 1.3, let me work on that tomorrow and will give you the updated yaml which you can use. Will also incorporate @kmuthukk suggestions around fast path initialization for initdb.
cc @vp15591
any progress on the cloudformation deployment file ?
@christopa - @ramkumarvs is taking a look at this, he will update - we should be able to get this done soon.
@christopa sorry for the delay, we wanted to get you the latest software which didn't need initdb all together. we have updated the cloudformation templates to reflect that change. Once my last bit of change goes in, you can give it a shot, it should bring up the DB with YSQL enabled by default.
Again thanks for your patience!
Thanks for the hard work. Appreciate the attentiveness to the issue.
Let me know when its ready and I will give it a try.
@christopa i merged the changes, give it a shot now and let us know if it works. Feel free to close this issue, if it works as intended
I am not sure if this is related or not, but I went ahead and deployed using the new yaml. I then SSH'd in to one of the node servers. Ran 'ysqlsh' and got the following:
ysqlsh: could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5433?
That appears to be an error for a local install. Is there some sort of config I need to update to make that work?
@christopa yeah can you try giving the private ip of one of the nodes instead of localhost?. We don't listen on 127.0.0.1. In order for the database to be accessible outside the node.
Also one thing i forgot to mentioned, if you want to connect to the DB outside, you can always update the security group, and whitelist any ip for the ports you want to access. Like for example if you want to access YSQL, you can whitelist 5433 against the IP you access it. By default the security on these nodes are very restrictive given.
@christopa --
for this setup, can you try:
./bin/ysqlsh -h
Got it. Thanks. Everything looks great, so I will go ahead and close the issue.