I need to import my local dump.rdb to the cloudfoundry redis service that I created.
I opened the tunnel and tried, slaveof localhost 6379 and it returned an error, (error) ERR unknown command 'slaveof'
I tried config get command and it returned same unknown error. This is understandable, probably they have disabled config command.
How do I import ? Are there any other ways ?
I searched, but could not find details.
Cloudfoundry uses a client model to communicate with and manipulate the service. In this case, something like, "redis_cli" would be the client. Here are some links I found which describe import/export, and how it might be implemented.
http://groups.google.com/group/redis-db/browse_thread/thread/3f9cad49a647901a
https://github.com/antirez/redis/issues/288
https://github.com/delano/redis-dump
https://github.com/pconstr/rdb-parser
Related
The problem is exactly what the title says, I am not able to connect to mongo db server. I don't know where the problem is. Whether its with starting the server of something else. According to the code that I have written I should get the output 'Connected Successfully'. but I am not getting any output
const mongodb=require('mongodb')
const MongoClient=mongodb.MongoClient
const connectionURL='mongodb://127.0.0.1:27017'
const databaseName='task-manager'
MongoClient.connect(connectionURL,{useNewUrlParser:true},(error,client)=>{
if(error){
return console.log('Unable to connect to database')
}
console.log('Connected Successfully')
})
I have attached the related screenshots.
enter image description here
enter image description here
Please help and thank you in advance
I tried searching for things in the documentation but could not find anything. I am expecting console.log statement to work in the nodejs code that I have written.
I can see from the logs that the server is listening at 127.0.0.1:27017. However, are you sure that it is reachable?
Some other software might be blocking the access, as described in a similar question here.
You can confirm by running curl http://127.0.0.1:27017 from a console terminal, if you are on Linux or Mac, or from a PowerShell window on Windows. Some other software might be blocking the access, as described in a similar question here.
If you get a message like below, your server is fine...
user#server ~]$ curl http://127.0.0.1:27017
It looks like you are trying to access MongoDB over HTTP on the native driver port.
user#server ~]$
The second step would be to ensure that you have the right/updated driver. I see from your screenshot that your server runs MongoDB 6.0.2, which is pretty recent.
You need at least driver v4.8 as per the MongoDB/node driver compatibility list.
Then, I would suggest to try running first a piece of code that it is confirmed working well, alongside the supported driver version.
e.g. You can try theses examples, directly from the MongoDB code-samples: https://mongodb.github.io/node-mongodb-native/api-generated/mongoclient.html
When I start my local ipfs node with ipfs daemon, in the cmd I get this:
Gateway (readonly) sever listening on /ip4/127.0.0.1/tcp/8080
With this, I can say 127.0.0.1:8080/ipfs/CID and read files from IPFS.
In my Node.js app, when I run ipfs.create(), in the console I get logs about swarms, but not about a readonly gateway server. I have found out that the ipfs.create() function has an option Gateway that on default is set to /ip4/127.0.0.1/tcp/9090. But when I run my node and keep my app running, when I try to retrieve something with 127.0.0.1:9090/ipfs/CID, I get an ERR_CONNECTION_REFUSED. Why is that? While the app is running, I scanned my ports and nothing was attached to 9090.
I have found the answer. Yes, js-ipfs has a readonly gateway server, but it's not starting implicitly togheter with the node, you have to use ipfs-http-gateway package. The package doesn't really have good instructions, but here is how you do it. You import HttpGateway class from the package and give your ipfs instance to it as a constructor, then you call .start() from the HttpGateway instance. The .start() will take the config options from your ipfs instance, and will search for Adresses -> Gateway options that defaults to /ip4/127.0.0.1/tcp/9090 and start the gateway to that port. You can read the code from the package where the HttpGateway class is written, and you'll figure it all out.
I deployed a gRPC service to Cloud Run and was given a service url of the form:
https://customer-service-random-string-ue.a.run.app
I now attempted to connect to that service from localhost using the following code:
let client = new customer_proto.Customer("dns:customer-service-random-string-ue.a.run.app:50051", grpc.credentials.createInsecure());
but all I keep getting back is the following error:
Error: 14 UNAVAILABLE: No connection established
What can I do differently to make this work?
Thank you
We don't know the implementation of customer_proto.Customer so it's not possible to provide a definitive answer.
It's unlikely that the method expects the endpoint to be prefixed dns:. I would expect it to want the Cloud Run service endpoint and, because gRPC doesn't have default ports, (and as I mentioned previously, Cloud Run maps services to) :443 too, i.e.
customer-service-random-string-ue.a.run.app:443
A good tool that I use to test gRPC services is gRPCurl. Postman is quite common for REST and now supports gRPC
If your service support reflection, you can:
grpcurl customer-service-random-string-ue.a.run.app:443 list
Otherwise, you'll need to reference the service's proto file(s), the service and a method (possibly with data) to test:
grpcurl \
-proto {your-proto} \
customer-service-random-string-ue.a.run.app:443 \
{package}.{Service}/{MethodName}
You can confirm that the host is defined and responds with:
nslookup customer-service-random-string-ue.a.run.app
telnet customer-service-random-string-ue.a.run.app 443
We have a redis cache hosted on Azure and we use the following as a service in our .net core application:
services.AddSingleton<IConnectionMultiplexer>(provider =>
ConnectionMultiplexer.Connect(Configuration.GetConnectionString("RedisConnection"))
);
Our connection string is similar to the following:
ourserver.redis.cache.windows.net:6380,password=******=,ssl=True,abortConnect=False,syncTimeout=4000
in getting from cache we don't face problems but if we add to cache we sometimes get the following error:
"StackExchange.Redis.RedisConnectionException: It was not possible to
connect to the redis server(s); to create a disconnected multiplexer,
disable AbortOnConnectFail. ConnectTimeout"
I have read solutions like setting abortconnect to false and increasing the timeout but I have implemented it like the connection string above.
If you have suggestions or you think that we have a problem with the connection string kindly advise.
Update: we have implemented a solution to solve connectivity issue but now we get this:
StackExchange.Redis.RedisConnectionException: No connection is available to service this operation
What is your connectTimeout set to? Can you try increasing that to see if it helps?
I'm trying my best to learn Google's Cloud Platform. They have a CloudSQL offering, which I'm learning via this NodeJS tutorial. Everything worked great until I deployed to their appspot server, at which point I got the following error:
connect ECONNREFUSED 127.0.0.1:3306
I've looked all through the NodeJS project and don't see anything in it or the Cloud Console that is referencing localhost or 127.0.0.1. Googling the error hasn't helped thus far. Any ideas?
I couldn't get this thing fixed when running on server but using this files I was able to read/write from local and production, now im using this connection strings in my own app
https://cloud.google.com/appengine/docs/flexible/nodejs/using-cloud-sql
https://github.com/GoogleCloudPlatform/nodejs-docs-samples/tree/master/appengine/cloudsql
I had a similar issue when deploying the nodejs sample app 2-structured-data
The reason why the error occurred is that the NODE_ENV environment variable was not passed to the config file that is used to check if node should use a socket for connecting to mysql
You can fix it by adding 'NODE_ENV' in the file config.js :
.env([
...
'NODE_ENV'])