I am trying to build and install membase from source tarball. The steps I followed are:
Un-archive the tar membase-server_src-1.7.1.1.tar.gz
Issue make (from within the untarred folder)
Once done, I enter into directory install/bin and invoke the script membase-server.
This starts up the server with a message:
The maximum number of open files for the membase user is set too low.
It must be at least 10240. Normally this can be increased by adding
the following lines to /etc/security/limits.conf:
Tried updating limits.conf as suggested, but no luck it continues to pop up the same message and continues booting
Given that the server is started I tried accessing memcached over port 11211, but I get a connection refused message. Then figured out (netstat) that memcached is listening to 11210 and tried telneting to port 11210, unfortunately the connection is closed as soon as I issue the following commands
stats
set myvar 0 0 5
Note: I am not getting any output from the commands above {Yes: stats did not show anything but still I issued set.}
Could somebody help me build and install membase from source? Also why is memcached listening to 11210 instead of 11211?
It would be great if somebody could also give me a step-by-step guide which I can follow to build from source from Git repository (I have not used autoconf earlier).
P.S: I have tried installing from binaries (debian package) on the same machines and I am able to successfully install and telnet. Hence not sure why is build from source not working.
You can increase the number of file descriptors on your machine by using the ulimit command. Try doing (you might need to use sudo as well):
ulimit -n 10240
I personally have this set in my .bash_rc so that whenever I start my terminal it is always set for me.
Also, memcached listens on port 11210 by default for Membase. This is done because Moxi, the memcached proxy server, listens on port 11211. I'm also pretty sure that the memcached version used for Membase only listens for the binary protocol so you won't be able to successfully telnet to 11210 and have commands work correctly. Telneting to 11211 (moxi) should work though.
Related
I'm trying to simply setup an Open Source Greenplum instance and have been hitting the same issue regarding GPFDIST for days! Simply put, I do a full installation from scratch on CentOS 7.6 (can provide further details regarding setup if needed) installing OS GPDB software version 5.18 with GPORCA disabled. Full command for the compile is:
./configure --prefix=/usr/local/gpdb --with-perl --with-python --with-libxml --with-gssapi --with-includes=/usr/local/gpdb/include --with-libs=/usr/local/gpdb/lib --disable-orca
This compiles successfully, and the following make/make install commands too complete without issue. The initialisation of the Greenplum database itself also succeeds, and I can then go into a database and create tables, insert data and run queries like normal.
But if I try to select from an external table, such as the following:
create external table test_external_table
(testing smallint
)
location ('gpfdist://mdw:8080/test_data.csv')
format 'csv' (header delimiter '|')
;
with GPFDIST run as follows:
gpfdist -d /home/gpadmin/test/ -p 8080 -l /home/gpadmin/greenplum/logs/gpfdist_log 2>&1 &
then I get two errors; one from the external table, and one from GPFDIST. These are as follows:
External Table Returns:
ERROR: connection with gpfdist failed for gpfdist://mdw:8080/test_data.csv. effective url: http://127.0.0.1:8080/test_data.csv. error code = 104 (Connection reset by peer) (seg0 slice1 127.0.0.1:6000 pid=27962)
GPFDIST Returns:
[1]+ Segmentation fault gpfdist -d /home/gpadmin/test -p 8080 -l /home/gpadmin/greenplum/logs/gpfdist_log 2>&1
I have removed everything that isn't on the OS GPDB GitHub installation guide (for a 'bare-bones' setup), so I don't think that is causing the issue. I have tried everything to do with the hostname and network firewall, and it's all perfect as far as I can see.
I have also downloaded the same version of GPDB (5.18) from Pivotal and installed that version on the same instance simultaneously, and GPFDIST works perfectly fine.
I have also tried OS GPDB 5.17, 6 beta and 7 beta, and I get the same issue for all of them.
Any ideas at all on what might be causing this is VERY much appreciated, as I'm slowly going insane trying to figure this out now.
Thank you very much in advance for any help.
-- Edit --
Okay.. Having nearly chewed my own arm off in sheer frustration at trying to install debuginfo stuff on CentOS 7, I've finally generated a core dump with gdb. I then run:
gdb -c core_dump.<pid>
and get the following output:
Core was generated by `gpfdist -d /home/gpadmin/test -p 8080 -l /home/gpadmin/greenplum/logs/gpfdist_log'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f4f2c07bdff in ?? ()
But I have absolutely no idea what that means... Totally honest, I'm a little over my head with this now and really am stuck on how to proceed.
The connection reset by peer only indicates that the other end of the socket had dropped (...in this case, gpfdist because it crashed out).
Setup your gpfdist and try a wget to a hosted file adding:
--header='X-GP-PROTO:0'
You will need to add the header to avoid having the request rejected.
Are you able to retrieve a file there? Or does that also crash out?
If that crashes out, it's nothing to do with the database - and you will likely need a core dump to determine what the segfault is about (r/w permissions, memory, ...).
I've finally managed to solve this issue. Should anyone come looking with a similar problem, make sure you are installing Libevent version 1.4[.15], and nothing above that.
I had 2.2.0 installed, and whilst Greenplum sees this as fine, it actually doesn't work for it. Unfortunately, I did have to do an entire system installation from scratch to seemingly get it to work, as just installing Libevent 1.4 on the old system with Greenplum already compiled did not work for me.
Attempting to kill port and locate possible process paths
I'm trying to use the Postgres.app to utilize the database, but keep running into the "Port in use" issue. I had originally brew installed postgres, but opted to use the app instead. So I brew removed postgres and installed Postgres.app. But now when I try to connect, it says that the port is in use. From everything that I've read, postgresql is the only process that listens at that port (I'm not using any other databases like MySQL). So, I was going to try to use the sudo launchctl unload -w /path_to/process command, but as you can see above...when I use which postgres or which postgresql, there's no path found. I also tried killing the connection to the port, but the ghost postgresql automatically connects right afterwards. Any tips on how to find out what the heck is listening on the port and prevent it from auto-connecting?
Edit: I tried using the Activity Monitor to see if I had accidentally installed a second version of the postgres.app. I checked to see what was the PID of the process listening in on the port. But it's not listed in the activity monitor. So I still have no idea how to find whatever is listening on the port
PID not listed in Activity monitor screen
I have the following commands on MacOS
$ sl
slapacl slapadd slapauth slapcat slapconfig slapdn
slapindex slappasswd slapschema slaptest sleep slogin
I am following this tutorial on running an ldap server on MacOS:
http://krypted.com/mac-security/starting-openldap-on-mac-os-x-client/
seems strange that I don't have a slapd command - anyone know why?
Since slapd is almost never run "by hand", it's not in one of the binaries directories that're in the default PATH. Instead, it's in /usr/libexec, which is the usual place for things that're run automatically rather than manually. So run it with sudo /usr/libexec/slapd instead of just as slapd. (BTW, the sudo is needed so it can allocate low-numbererd TCP ports, and get full access to its database).
I'm having trouble connecting to a replica set.
[MongoDB\Driver\Exception\ConnectionTimeoutException]
No suitable servers found (`serverSelectionTryOnce` set):
[Server closed connection. calling ismaster on 'a.mongodb.net:27017']
[Server closed connection. calling ismaster on 'b.mongodb.net:27017']
[Server closed connection. calling ismaster on 'c.mongodb.net:27017']
I however, can connect using MongoChef
Switching any localhost references to 127.0.0.1 helped me. There is a difference between localhost and 127.0.0.1
See: localhost vs. 127.0.0.1
MongoDB can be set to run on a UNIX socket or TCP/IP
If all else fails, what I've found that works most consistently across all situations is the following:
In your hosts file, make sure you have a name assigned to the IP address you want to use (other than 127.0.0.1).
192.168.0.101 coolname
or
192.168.0.101 coolname.somedomain.com
In mongodb.conf:
bind_ip = 192.168.0.101
Restart Mongo
NOTE1: When accessing mongo from the command line, you now have to specify the host.
mongo --host=coolname
NOTE2: You'll also have to change any references to either localhost or 127.0.0.1 to your new name.
$client = new MongoDB\Client("mongodb://coolname:27017");
I had the same error in a docker based setup:
container1: nginx listening on port 80
container2: php-fpm listening on port 9000
container3: mongodb listening on port 27017
nginx forwarding php to php-fpm
Trying to access mongodb from php gave this error.
In the mongodb Dockerfile, the culprit was:
CMD ["mongod", "--bind_ip", "127.0.0.1"]
Needed to change it to:
CMD ["mongod", "--bind_ip", "0.0.0.0"]
And the error went away. Hope this helps somebody.
The IP address of your home network may have changed, which would lead to MongoDB locking you out.
I solved this problem for myself by going to MongoDB Atlas and changing which IP address is allowed to connect to my data. Originally, I'd set it up to only allow connections from my home network. But my home network IP address changed, and I started getting the same error message as you.
To check if this is the same issue with you, go to MongoDB Atlas, go into your project, and click "Network Access" on the left hand side of the screen. That's where you're able to update your IP address. It shows you what IP address(es) it's allowing in. To find out what your current IP address is, go to whatismyipaddress.com and update MongoDB if it's different.
In my case, I am temporarily coding PHP from Windows7 against MongoDB on my VPS running Linux Debian 9. The PHP will be eventually running in the same Linux box to provide an API to the MongoDB data.
BTW, it does not appear this local composer install is doing me any good, it's pure ugliness. My PHP after the fix below works without the require line require_once 'C:\Users\<Windows User Name>\vendor\autoload.php'.
My fix is different than the accepted answer which to me did not make sense.
I did not have to touch any hosts file
So edit your /etc/mongod.conf with your target machine's IP and restart with sudo systemctl restart mongod that's it
I don't know what to blame
PHP and MongoDB sites for the terrible documentation skimpy and incomplete PHP examples, or...
MongoDB installation on Linux failing to mention this bindIP.
My startup experience with MongoDB is so far very negative given all the changes that have occurred nothing matches what I expected from the videos I watched. I can't seem to find any that reflect what I am going thru like
$DB_CONNECTION_STRING="mongodb://user:password#164.152.09.84:27017"
$m = new MongoDB\Driver\Manager( $DB_CONNECTION_STRING )
instead of
$m = new MongoClient()
Hope this helps someone
PS. Always say NO to semicolons, camelCAsE and anything case-sensitive... absurdity at its best.
I have been following this tutorial to try and setup a single node mesosphere cluster from their
official tutorial:
http://mesosphere.com/docs/getting-started/developer/single-node-install/
I followed all the commands without any issues, and I also added the ports 5050 and 8080 to my security group. When I try to access the console for mesos/marathon, I get a "Internet Explorer cannot display the webpage" message.
They also recommend checking it the following way:
MASTER=$(mesos-resolve `cat /etc/mesos/zk`)
mesos-execute --master=$MASTER --name="cluster-test" --command="sleep 5"
But that comes up with an error:
WARNING: Logging before InitGoogleLogging() is written to STDERR
F0106 17:03:08.126703 20993 process.cpp:1561] Failed to initialize, gethostbyname2: Unknown host
*** Check failure stack trace: ***
I am not really sure how to troubleshoot this either, and there are not many tutorials I could find on how to install mesos on ubuntu.
I checked the contents of the zk file, seems to be the default value.
$ cat /etc/mesos/zk
zk://localhost:2181/mesos
I would really appreciate any clues on how to go about this one.
Edit: The process is definitely running too - just an fyi:
root 31545 8.5 5.9 187464 35604 ? Ssl 17:28 0:00 /usr/local/sbin/mesos-slave --master=zk://localhost:2181/mesos --log_dir=/var/log/mesos
root 31563 28.5 2.1 116304 12856 ? Rs 17:28 0:00 /usr/local/sbin/mesos-master --zk=zk://localhost:2181/mesos --port=5050 --log_dir=/var/log/mesos --quorum=1 --wo
Mesos uses gethostbyname2 to resolve hostnames to IPs. The first thing I would recommend, is to try "ping localhost" and "ping hostname", and verify that there are no strange settings in /etc/hosts. If you're doing a multi-node cluster, I'd recommend that hostname map to the public IP address (not 127.0.x.1).
If that doesn't help, you can try setting the --ip and --hostname flags when starting mesos-master and mesos-slave, to bypass the gethostbyname2 resolution. These can also be set by writing to the file-based parameters, e.g. /etc/mesos/mesos-master/ip
For additional troubleshooting, try running wget http://localhost:5050 (or curl -L) from the mesos master, to verify that it is locally visible. Also try wget http://<public_ip>:5050 to verify that the web server is up and serving to the public IP. Depending on how your (EC2?) node is setup, you may need to expose/forward the port, or connect to a VPN.
Thanks Adam. I ran the wget and curl commands, and nothing was actually listening on port 8080 or 5050. I did open those ports in the ec2. A simple reboot did the trick however, once I ssh'ed into the ec2 instance after the reboot, both mesos and marathon were running and both ports are now showing after I ran
netstat -ntln.