“Found 2764 old transactions. Acting to abort them.” That’s normal.
This is Alpha logs? can you share the yaml or commands used to create the cluster?
“Error: No connection exists” - I wonder connection with what? zero is dead on your cluster? you said you have a “single server” - this means a single Dgraph Alpha running?
It runs fine for several minutes, then this happens every time, so I don’t think the zero is dead. Yes, a single Alpha server. I also tried adding 3 connections to the same alpha on the client side, and it just sped up the process of this issue.
Installation process:
curl https://get.dgraph.io -sSf | bash
dgraph zero --my=<internal_ip>:5080 (in one tab)
dgraph alpha --lru_mb=10240 --my=<internal_ip>:7080 --zero=localhost:5080 (another tab)
dgraph-ratel -port 8008 (another tab)
Version:
$ dgraph version
Dgraph version : v1.0.14
Commit SHA-1 : 26cb2f94
Commit timestamp : 2019-04-12 13:21:56 -0700
Branch : HEAD
Go version : go1.11.5
Once I recreated the AWS instance, I stopped getting this error. I recreated on the same instance size, rd5.large and rd5.xlarge (4 cores, 32GB Ram, 500GB gp2 SSD, 1500 IOPS).
Perhaps if you run this too many times, it does something to the database?
It’s also possible that from my tests before, running my code when I hadn’t made sure it was completely safe, it did something to the system. I think it may have been memory related, and caused issues with the Zero server?
Why not “localhost”? On zero you’re using <internal_ip>:5080 but in the Alpha you’re using --zero=localhost:5080 This difference can create issues. Set all as localhost.
I don’t think so. Never saw it before (neither me or other users), but if it keeps happening, you should fill up an issue on github to the team investigate it.
You have enough memory for normal usage. How big is your dataset?
I’ve only mentioned Zero because I saw a “No connection exists” and you said you had only one Dgraph instance. So I assume it could be Zero. Zero don’t have any issues with memory, it doesn’t has a lot of tasks to do. You’d never see Zero above 1GB of memory. He is just a cluster balancer.
If you are doing a test-only server, I would recommend instead of using Drop_All that you do “rm -rf ./p ./w ./wz” delete the folders and start from scratch like this.
Why not “localhost”? On zero you’re using <internal_ip>:5080 but in the Alpha you’re using --zero=localhost:5080 This difference can create issues. Set all as localhost.
Ah I see. The documentation reads --my=IPADDR:5080, which reads as “my IPADDR” which tells me “set this as your IP”. It makes me think you need to use the internal ip and not loopback for whatever reason. Under what circumstances would this need to be anything else?
You have enough memory for normal usage. How big is your dataset?
Tiny, in tests it’s always under a 1GB. But it’s writing that 1GB in a matter of minutes, with one transaction per node (will iterate on this and see if it can be batched, but it’s hard with the nature of the data).
If you are doing a test-only server, I would recommend instead of using Drop_All that you do “rm -rf ./p ./w ./wz” delete the folders and start from scratch like this.
Could be worth putting this in the docs near where it says to start from scratch, use Drop_All
Dgraph is generally used in containers (you’re creating a bare metal). IPADDR is usually the address of the container or what an internal DNS (docker) will locate. If you use different but homonymous configurations, problems can happen. But not always. However it is important to keep the configuration across your cluster equally.
Well, this dataset is very small. Nothing abnormal should be happening here.
