I have successfully setup couchbase and elasticsearch on my machine, and configured the XDCR (cross datacenter replication) without a problem. Now, however I am trying to achieve the same setup on a vagrant box. I have elasticsearch and couchbase running without a problem, and port forwarding setup so I can access the couchbase admin console from my browser.
When I try and setup the replication though I get the following error
Error {econnrefused,[{lhttpc_client,send_request,1}, {lhttpc_client,execute,9},
lhttpc_client,request,9}]} happened during REST call get to http://127.0.0.1:9091/pools.
I am setting up the replication with IP/hostname 127.0.0.1:9091, which is what worked when I was doing it locally, i.e. without vagrant. Could this be the problem? Since localhost isn't referring to the vagrant machine?
At a guess you are trying to use the wrong port for replication - Couchbase uses port 8091 not 9091.
Ok, despite using versions of couchbase and elasticsearch that were supposed to be compatible, I decided to try the same approach with different versions, namely
couchbase-server-enterprise_2.5.1_x86_64.deb
elasticsearch-1.0.1.deb
elasticsearch-transport-couchbase-1.3.0
Instead of port forwarding in my Vagrant file I also made sure I was using a private network
config.vm.network "private_network", ip: "192.168.33.10"
and then when I attempted to setup replication using 192.168.33.10:9091 as the hostname it worked.
Related
Despite ElasticSearch and Kibana both running on my production server, I'm unable to visit the GUI over the public IP: http://52.4.153.19:5601/
Localhost curls return 200 but console errors on the browser report timeouts after a few images are retrieved.
I've successfully installed, run, and accessed Kibana on my local (Windows 10) and on my staging AWS EC2 Ubuntu 14.04 environment. I'm able to access both over port 5601 on localhost and the staging environment is accessible over the public IP address and all domains addressed accordingly. The reverse proxy also works and all status indicators are green on the dashboard.
I'm running Kibana 4.5, ElasticSearch 2.3.1, Apache 2.4.12
I've used the same exact volume from the working environment to attach to the production instance, so everything is identical on the two volumes, except that the staging environment's apache vhost uses a subdomain while the production environment's servername is the base domain. Both are configured for SSL wildcards. Both are in separate availability zones at Amazon. I've tried altering the server block to use a subdomain on the production server, just to see if the domain was impactful but the error remains.
I also tried running one instance individually, in case EC2 had some kind of networking error with 0.0.0.0 but I'm unable to come to a resolution. All logs and configurations are identical between the two servers for ElasticSearch and Kibana.
I've tried deleting and re-creating the kibana index, tried alternate settings inclusive of the host, elasticsearch url, extending the max ping and timeout, max retries, extended the apache limits, http.cors to allow different origins. I've tried other ports but both servers are indicating that 5601 is listening in the same way.
I also had the same problem on a completely different volume that was previously attached to this instance.
The only difference I can see is that the working version pings fine while the non-working version has a 100% packet loss when pinging the IP, although I can't imagine why that would be, as I'm able to reach the website on 80, just fine. I can also access various other tools running on other ports. I assume there might be some kind of networking conflict. Any ideas?
May be port 5601 is blocked by firewall
Allow incoming connections to port 5601 by:
sudo iptables -I INPUT -p tcp --dport 5601 -j ACCESS
For security:
Modify above mentioned command and accept connection only from specific address. (See man iptables)
or use Shield plugin for elasticseach
Sorry, forgot to update this question. The answer turned out being that I simply needed to deploy a new instance. Simply by creating a clone of the instance, I was able to resolve the issue. I've had networking problems at AWS, before, with their internal dns/ip conflicts, so I've had to do so, in the past and this turned out to be the quickest and cleanest solution, albeit not providing any definitive insight into the cause.
On my server I have installed elasticsearch-2.2.1 and couchbase server version 4.1.0. The aim is to transfer data from bucket x on couchbase to elastic search.
Ive installed the transport-couchbase plugin on elastic-search which will basically allow for xdcr from the server to elastic search.
As I understand it, transport-couchbase listens by default on port 9091 so in essence I'm supposed to create a cluster reference that points to that port (both couchbase and elastic search are installed on the same machine).
When I try create the reference I get an internal server error. The logs don't give me much information regarding the issue and I can ping the port. However when I try to telnet the machine on the port it refuses connection.
the server is sitting behind a proxy and i am starting to think that the issue lies within either couchbase server or elasticsearch ( transport-couchbase plugin)
Im going out on a limb here but I think maybe im supposed to configure the plugin so that it accepts requests going through tthe proxy. If this is the issue, is there a way to embed proxy settings into the plugin so that it can accept connections for xdcr?
PS: When I did this whole process on a separate machine that isnt sitting behind a proxy, everything worked fine. So I have a strong suspicion that it is proxy issues
If you can't telnet or browse to port 9091, this most likely indicates a network config issue. The plugin binds to the interface that elasticsearch binds to. The first thing to check is that the bind_host and publish_host in elasticsearch.yml is configured to bind to an interface that allows connections from wherever the proxy is located and that the proxy is really connecting on that interface.
There is a thread in github for the bug in transport plugin where it might not bind to all interfaces :
https://github.com/couchbaselabs/elasticsearch-transport-couchbase/issues/134
The above solutions didn't work for me, however I added this line:
-Djava.net.preferIPv4Stack=true
to /etc/elasticsearch/jvm.options and it seemed fixed the issue in my case
I have installed elasticsearch on Azure virtual machine.
I have installed the elasticsearch service which which automatically starts on system start up.
Everything works fine on VM. I can access the 9200 port of elasticsearch instance.
The problem is I can not access it with the help of dns name of the virtual machine i.e. xyz.cloudapp.net:9200
I have created endpoints for 9200 and 9300 port.
I want the Elasticsearch on just one VM for now.
Am I missing any steps?
The answer to my question is here.
I needed to add the following to my Elasticsearch config file
network.host: [_local_, _site_]
This works like a charm.
This has been added in ElasticSearch since 2.x.x version.
Thanks
I'm a vagrant newbie trying to configure his first instance. But wherever I look on Vagrantfiles configuring PostgreSQL they're always using port forwarding to the host.
config.vm.network :forwarded_port, host: 5432, guest: 5432
What is the point of forwarding database's port to the host?
Shouldn't the database be operating inside the box?
Or is it just a practice to have better data persistance?
And even if this is desired workflow and everything's forwarded then what is the point of installing the database inside the box after all?
This is mainly so that you can use Graphical Database SQL tools to query your Postgres database from your host machine. Since vagrant is used mainly by programmers and they need to frequently check the database for testing/debugging, this is in place. IDEs like IntelliJ and Eclipse have tools that you use to query databases and they would run on the host machine and thus would need to have access to the database port.
If you don't need to query your database from your host machine and it is only accessed by the guest VM, then you don't need this set.
Shouldn't the database be operating inside the box?
Yes.
Or is it just a practice to have better data persistence?
There is no relation between port forwarding and data persistence.
And even if this is desired workflow and everything's forwarded then what is the point of installing the database inside the box after all?
What is the point of forwarding database's port to the host?
There is no need to always forward port. Port forwarding is only needed when you want to access that port from host machine, e.g. using graphical tools as pointed by blownie55's answer. If you don't need to access the port from host then there is no need to forward it.
And this is true for all kind of port forwarding, not only for database port.
As a side note, there are other ways to access resource inside guest from host, e.g. configuring a private network.
I've had an elastic server cluster running for a few months now. 2 node cluster. Pretty simple, things were working pretty nice.
So, I upgraded from 1.7.2 to 2.0.0 today and now I can't get to my servers.... If I curl on the server using local host, everything works fine, if I curl on the machine using it's machine name, I get connection refused.
Upgrading is the only thing that's changed. Any ideas why elastic isn't seeing anything when I use the machine name?
Thanks,
Nick
FWIW you can set the network.host: 0.0.0.0 in elasticsearch.yml or launch as
follows : bin/elasticsearch --network.host 0.0.0.0
This way you should be able to access the cluster in loopback as well as non_loopback
This is, probably, the change in 2.0 that made the cluster accessible only via localhost.
Update each elasticsearch.yml file and provide a network.host for the node.