Tag Info

New answers tagged

1

Reproducing the situation : mc1 collection already created on shard0000 before sharding mc2 collection already created on shard0001 before sharding Create a test-shard: $ mongo --nodb mongo> config={d0:{smallfiles:"",noprealloc:"",nopreallocj : ""}, d1 : {smallfiles : "", noprealloc : "", nopreallocj : "" }}; mongo> cluster = new ...


2

You cannot set IPAll to "no" on a failover cluster instance (as mentioned before), see: How to configure SQL server to listen on different ports on different IP addresses? More than likely, though, you are wondering how to secure your failover cluster instance of SQL Server to a certain IP address, or to verify that it isn't indeed listening on all IP ...


1

This is by design: Case 4: SQL Server is installed in a clustered environment. On cluster, you cannot configure SQL Server to listen on a specific IP addresses. You must chose IPALL. Source: How to configure SQL server to listen on different ports on different IP addresses?


0

In this scenario I'd suggest sharding the clusters by functionality. If you have some tables with heavy load, maybe these tables diserve to have its own cluster. You could have a 3/5 nodes Galera cluster for this table, another 3 nodes Galera cluster for the rest of tables and the 1/3 rest of nodes to scale reads if needed. Of course, you could also shard ...


0

Yes you should use some kind of load-balancing solution, at least for these main reasons: To equally balance the load between the nodes. To check availability of the nodes and make it transparent as possible to your app. If you use an HAproxy server you should have it replicated, so it's not a single point of failure, e.g. you can have two HAproxies in ...


1

Instead of giving the name of the other node, I gave the IP address of the other node. Then everything went well. BUT what the reason was that it did not accept the name, I still do not know.


0

Seems like it was due to the cross-site cluster configuration The SQL Instance had 2 IP's with an OR dependency. It seems like the offline IP is causing an issue with the patch. This has been removed from the SQL Role and patching of the first node has completed successfully Unfortunately I don't know enough about the configuration to know if this is ...



Top 50 recent answers are included