I started out with a single mongo instance as my database, configured in spring xml:
<mongo:mongo host="localhost" port="27017" />
Recently, I changed my configuration to use a 3 node replica set, configured as:
<mongo:mongo replica-set="${my.replica.set}" />
Everything works great.
My current problem is that for my dev environment I'd like to use the single localhost mongo config and for int and prod envrionments I'd like to use the replica set config. The differing values I will handle via properties files. The question is about the mongo config itself.
Something along the lines of the example below would be ideal...
<mongo:mongo uri="localhost:27017" />
<mongo:mongo uri="localhost:27017,localhost:27018" />
I ran into this example: spring-boot uriCanBeCustomized unitTest
Is there a way to do this in spring config?
I am using spring-data-mongodb-1.7.0.RELEASE.
Looks like the replica set configuration works even if you point it to a standalone mongod. I assumed that wouldn't work since it specifically sets 'replica-set' but testing shows that it does.
So in my case, the configuration would just look like
<mongo:mongo replica-set="${mongodbs}" />
where in the dev properties file I'd have
mongodbs=localhost:27017
and for int/prod properties
mongodbs=host1:port1,host2:port2,host3:port3
Related
Consider the following things are already satisfied.
1. The maria-db is running in separate pod and is pre-installed.
2. When we deploy a new service it is able to connect to maria-db and create SCHEMA in it.
But the final requirement is when the service is deleted then it should cleanup the SCHEMA.
I have tried writing a job with post-delete tag.
So just a thought, you could possible do this by using a Admission Control i.e your logic could possible be along the lines of:
Delete Pod Requested --> Hits Addmission Control --> Addmission Controller Removes Schema --> Pod Deleted
However this would be a lot of custom code and you would need a way to identify the Schema that that particular service has created in the DB.
I have a stateless ASP.NET Core (RC1) service running in my Azure Service Fabric cluster. It has the following manifest:
<ServiceManifest Name="MyServicePkg" Version="1.0.2" ...>
<ServiceTypes>
<StatelessServiceType ServiceTypeName="MyServiceType" />
</ServiceTypes>
...
</ServiceManifest>
My cluster is configured with placement properties. I have 5 servers with "nodeType=Backend" and 3 servers with "nodeType=Frontend".
I would like to upgrade my Service and specify that it may only be placed on "Backend" nodes. This is my updated manifest:
<ServiceManifest Name="MyServicePkg" Version="1.0.3" ...>
<ServiceTypes>
<StatelessServiceType ServiceTypeName="MyServiceType">
<PlacementConstraints>(nodeType==Backend)</PlacementConstraints>
</StatelessServiceType>
</ServiceTypes>
...
</ServiceManifest>
However, if I now execute the upgrade, I get the following error:
Start-ServiceFabricApplicationUpgrade : Default service descriptions
must not be modified as part of upgrade. Modified default service:
fabric:/MyApp/MyService
Why isn't it possible to change the constraints with an upgrade?
Would I have to delete and re-create the service? This would seem extremely problematic to me because it would result in downtime and data loss for stateful services.
So the issue here is actually with the DefaultService part of the ApplicationManifest. When services are created as part of the DefaultService, there are things you can't change about it afterwards. You might be able to change it through the ServiceFabric explorer, but I'm not sure.
One recommendation would be to keep the DefaultServices empty in the ApplicationManifest, and instead create your services manually. With manual I mean either through powershell, code or the ServiceFabric Explorer.
That gives you more flexibility about changing parts of the service afterwards. When it's done that way, you I know you have the possibility to change things like placement constraints after the service is running.
To create Services with PowerShell you can use the New-ServiceFabricService command.
To create it from code, you can use FabricClient to do it. A sample of that can be found here: Azure Service Fabric Multi-Tenancy
There's actually a fairly easy way to do this without having to write a bunch of code to manually define the application on the fabric cluster.
While you can declare the placement constraints in the service manifest, you can also declare them in the application manifest. Anything declared in the application manifest will override what's in the service manifest. And with the setting in the application manifest, you can then use parameters to alter the values based on the parameter file you want to a specific deployment.
I've just written up a blog post that discusses this approach in greater detail. I hope you find it useful. :)
When we deployed our java app using spring data + mongodb we noticed that the cpu spiked to 100%. After removing the mongo configuration it went back to normal. The application is literally doing nothing with mongo, we merely have it added to the context file
<mongo:mongo id="mongo" host="127.0.0.1" port="27017" />
Any ideas what could be causing this? The cpu slowly gets eaten up until it reaches 150%.
I need to create a standalone replica set in mongo. I followed the steps here: http://docs.mongodb.org/manual/tutorial/convert-standalone-to-replica-set/
Everything worked as expected, but I was wondering how I could configure this in the mongodb.conf file so I didn't have to manually do these steps every time. Is something like this possible via the conf file? I know there is a replSet param that you can have in the conf file, but I wasn't sure how to specify which ports to use for the different replica sets. Thanks!
Most of the command line parameters you specify are settable in the configuration file - you can see how here: http://docs.mongodb.org/manual/reference/configuration-options/
Specifically, notice that you can set, port, replSet, and dbPath from the configuration file.
There is also a good article on Replica set configuration here: http://docs.mongodb.org/manual/reference/replica-configuration/
I'm writing an app that uses Hazelcast. My app is really slow to start because Hazelcast tries to talk to other nodes on the network on startup. This is fine for production, but when I'm doing single-node debugging it really slows down my edit-compile-run-debug cycle.
Is there a Hazelcast setting that tells it that there's only one node so please start quickly and don't bother pinging the rest of the network?
You can disable join methods:
<join>
<multicast enabled="false">
</multicast>
<tcp-ip enabled="false">
</tcp-ip>
<aws enabled="false">
</aws>
</join>
this will save you at least 3 sec while debugging
System.setProperty("hazelcast.local.localAddress", "127.0.0.1");