I’ve just updated a Couchbase 3.1 installation (Windows) to the v4 RC. It seems to do the upgrade OK and recognised the pre-existing installation. However, I then go into cbq and any attempt at running a N1QL query gets the following…
ERROR 5000 : Post http://localhost:8093/query: dial tcp 127.0.0.1:8093: ConnectEx tcp: No connection could be made because the target machine actively refused it.
Is there some setup step that I am missing?
Hi mjordan73
When you install in this way you pick up the 3.x config which, of course, doesn’t know anything about the N1QL and 2i services, which are needed to run queries.
If you don’t care about your data, uninstall, and wipe out the previous installation directories and re-install fresh setting up a new cluster. The N1QL and 2i services will be enabled by default on the fresh installation and you can execute queries through cbq.
If you do care about your data, save off your previous data directory and “cbtransfer” it back to the newly set up cluster. The cbtransfer command looks as follows, (admittedly written in a unix-y envioronment):
./install/bin/cbtransfer couchstore-files:///absolute/path/to/data.bak/n_0/data http://127.0.0.1:9000 -b "bucket-name" -B "bucket-name" -u Administrator -p password
Cheers & good luck!
Just tried this and got the following
error: could not read couchstore file due to unsupported file format version; exception: unpack requires a string argument of length 19
This is using a data folder from a v3 installation. Any ideas?
It does seem faintly ludicrous though that the v4 installer is clearly aware of existing v3 installations (even specifically prompts to say it is backing up your data and then uninstalling 3.x prior to install of v4) but can’t take the step of enabling N1QL features in the product install. In fact it seems equally daft that you apparently still can’t enable N1QL services post-install (this was an issue raised by others in the beta/preview phase).
Hi mjordan,
I worked through your problem and was able to reproduce it on my machine. I’m looking into the cause.
In the meantime, could you try “cbbackup” against the 4.0 installation instead? E.g., with Couchbase running, try:
cbbackup.exe couchbase://localhost:8091 /Users/IEUser/backup
Then shut down Couchbase, move the data/config directory (Program Files\Couchbase\Server\var\lib\couchbase) elsewhere, restart, and configure it to include indexing and query. (I agree that adding indexing and query should be easier.) And cbrestore from your backup.
That worked for me, even though cbtransfer showed the same error you saw.
Let me know if it works for you.
Yes, that seems to work with deleting the data/config and restoring the data after setting up again. Nice trick.
I should add I had some success yesterday using cbtransfer between a running v3 instance and a v4 installation (so cbtransfer http://serverv3 http://serverv4), although I should also add that the cbtransfer executable never returned to the command line and its process had to be killed (this is on Windows by the way) despite it seeming to have transferred all the documents for the bucket off the source server OK.
Great! I have filed a bug related to the first cbtransfer problem (and the underlying cause has already been identified), and I’ll look into the issue between v3 and v4.
Regards,
-Eben
P.s. One question about the problem using cbtransfer between v3 and v4: on which machine were you running cbtransfer? The one with v3, or the one with v4?
Thank you,
-Eben
It was the V4 box (Windows) I was running it from, pulling data from a V3 box (Linux)
Thanks, I was able to reproduce an error when doing that transfer, will investigate.
Hi,
@eben I’m getting the error with cbbackup too.
error: could not read couchstore file due to unsupported file format version; exception: unpack requires a string argument of length 19
This exception message says you’re trying to connect to the same host ( 127.0.0.1 ), while you’re stating that your server is running on a different host. This 127.0.0.1 represents a ‘loopback’ . It allows the computer to communicate with itself via network protocol .
Dns.GetHostEntry(IPAddress.Loopback).HostName returns the host name of your machine. When you pass a host name to TcpClient , it will resolve it to one or more IP addresses using Dns.GetHostAddresses(hostName) . This includes the public and local IP addresses of your machine (e.g. 192.168.12.10), but not 127.0.0.1 (loopback address). So your client is trying to connect to any of the non-loopback addresses of your machine, while your server is listening only on the loopback address . So, no connection can be established. The solution to this problem is that connect to the same end point your server is listening on.