As said in another answer here:
The number of Redis databases is fixed, and set in the configuration
file. By default, you have 16 databases. Each database is identified
by a number (not a name).
But I am curious if there is a way I could and should title and describe my databases? Especially in the scenario when one server could be used by few users (developers for example).
No, currently there isn't such a way. Please also note that numbered (shared) databases are not future-compatible (unsupported by Redis v3 with clustering support) and are not recommended for use - see here for more details: https://redislabs.com/blog/benchmark-shared-vs-dedicated-redis-instances
Related
I am on Rails 3 with a local Postgres database. What we want to do is replicate the entire database onto a second server in real time. We are thinking of using Octopus.
I'm confused about what model I'm looking for and how the master-slave model applies.
Postgres 9.1 and later comes with streaming replication built in (for master-slave configurations). Check out http://www.postgresql.org/docs/9.2/static/warm-standby.html#STREAMING-REPLICATION for more information on configuration and setup.
There are other third-party solutions for configuration, but I'd start there and see if that meets your needs.
This is not a traditional scale-up or scale-out question.
Please bear with me, here first allow me give an example:
I created a Sql Azure server and create a 1GB database inside, cost $9.99 a month.
(It has a master database as well, 1G, but Microsoft not charge us for that)
Ok, here is my question comes, when I need another 1G database for my application. Why I need another 1GB database? You may ask me this because the azure can support database up to 50GB. My answer is distribution, I know the data will reach 50G eventually, so I create the data model distribute and spread the data in different database.
For all the sake of performance, which option I should use:
Create another database in same server
Create another server and create a new database inside
Both option cost same.
I guess option 2 will be better, isn't it?
I'm not sure there are strong (or any) performance implications, my understanding is that the consideration is mostly a management one as some entities, mostly around security, are defined at server level and some at database level.
Behind the scenes the model is quite different anyway, and a multi-tenant one, so having separate SQL Azure server does not actually mean you get a dedicated server per-se. theoretically separate servers or separate databases may end up looking exactly the same.
I have a C# application that works against MS SQL Server or Oracle using ADO.NET.
Let's say a customer wants to use some kind of database clustering or synchronous replication for purposes of resilience and/or performance.
Am I correct in assuming that my application code does not have to take any account of this? i.e. that database integrity rules and locking are honoured exactly the same as they are for a standard single database? are there any holes I might fall into?
Thanks
Andy
Am I correct in assuming that my
application code does not have to take
any account of this?
Yes.
Typically the only thing you have to worry about is the connection string. Specifically you need to go against the cluster name instead of the node name.
Its a minor point but if you miss it, you can undermine the point of your HA Pair and or Load balancing cluster.
I am developing a web portal in Asp.Net. Primary target users will be of India Only. But in future I may target overseas users also. I want to know if I should use Sql Server Replication or not. Should I concern about "Replication" at initial stage or can I use it at later stages. Thanks in advance.
I don't think replication means what you think it means. Replication is a means of synchronizing multiple databases with data and it is most useful where databases need to be disconnected at times.
I don't think you need to be concerned about replication if you are developing a web app. If you will have multiple sites in the future, you can still have a single database hosted separately from any of the sites that all the localized sites reference and update independently.
Unless you will have multiple databases to be consolidated into a central db, NO, dont worry about it.
It will bring a whole world of hurt.
I need to set up this scenario:
A SQL Server 2005 database will create a transactional replication subscription from another database to populate a set of lookup tables. These lookup tables will then be published as a merge replication publication to the client's SQL Server Mobile.
I remember seeing a similar scenario defined in the SQL Server Books Online somewhere, but I was unable to find the link anymore. I hope someone can help me find it, or otherwise point me to any other similar links.
Okay, I managed to get the answers I needed at the MSDN SQL Server Replication forum.
The article I was looking for is called: Republishing Data.
Apparently, it is located within "Advanced Replication Features and Internals" of the "Configuring and Maintaining Replications" section. It's a little non-obvious, so I spent most of my time looking in the "Replicating Data Between a Server and Clients" section, instead of there. Good to know, as there seems to be a number of other special scenarios worth looking at in there.
I do not get the interest of having a transactional replication to generate lookup tables. Such tables are not made to be updated from the client side, so why do you want to combine transactional + merge replication when you don't have the data modified by the subscribers?
Maybe the original scenario is not clear, so let me clarify.
The database where the original lookup tables are located either remotely with bad network connection, or operated under heavy load. This approach was suggested so that the lookup tables are replicated to another database which all merge replication with the clients will be performed.
Of course, it may not be the most appropriate approach to our problem, so if anyone has a better idea, we'll like to hear them.
Still, the main reason for this question is to find an article I previously found (but stupidly did not bookmarked) which described our scenario quite well. Any possible leads to this article (title, author, similar topics, etc) are definitely appreciated.