Lets say we have a microservice A and a B. B has its own database. However B has to be horizontally scaled, thus we end up having 3 instances of B. What happens to the database? Does it scale accordingly, does it stays the same (centralized) database for the 3 B instances, does it become a distributed database, what happens?
The answer is based on the which kind of data should be shared from 3 B instances. Some occasions:
The B is just read data without write anything, the DB can use replicate methodology, and three B instance just read data from different DB instance, and DB was replicated.
The B instance can read/write data without interrupt other B instance, that mean every B instance can have designated data, and no data sharing between instances, the database was changed to three databases with same schema but totally different data;
The B instances should share the most of data, and every instance can occasion write the data back to the DB. So B instance should use one DB and some DB lock to avoid conflict between the instances.
In other some different situation, there will be many other approaches to solve the issue such as using memory DB like redis, queue service like rabbitMQ for B instance.
using one database by mutliple service instances is ok when you are using data partitioning.
As explained by Chris Richardson in pattern database per service,
Instances of the same service should share the same database
Related
Two microservices share the same database because they each contribute part of the database's content, this occasionally causes data overwrites or errors. Which of the following strategies will help to reduce this problem ?*
A) Develop a transaction manager component between the microservices and the database to control access.
B) Rely on standard database locking mechanisms.
C) Use a first write principle to allow the first microservice to write data to determine the record status.
D) Separate the database into two partitions and allow each microservice dedicated access to its own partition.
E) Create a condition in each microservice where one writes during odd seconds and the other writes during even seconds.
Need guidance. I have two databases A & B, each residing in different servers. Database A is primary, at the main site and database B is at remote location, user side. Table structure in B is a subset of A. Database B will fetch certain data from A for certain functionalities to work and when data is updated by users in B, they need to be updated in A. The problem here is, the there is connectivity issue between A and B as B is in a remote area.
When connection is alive, both databases should be in sync. And when connection goes off, B should be able to function actions basing on last pulled data from A. and when connection restores, data sync should happen.
I am using Oracle 12c. Please help guys.
Regards
Say I have a microservice A and it has 3 instances. Similarly for microservice B there are 5 instances of B service.
I will have separate DB for Microservice A and B that is fine. But is it necessary to have separate db instance for each microservice instance of A or B?
I mean to say for the 3 instances of Microservice A, do I need to have 3 separate instances of db? Or all the instances of A will point to one db instance? Which is better approach?
The question is broad and there is no better or worst approach it purely depends on your use cases and user load.
From your question I understood you need to spawn separate instances of a single microservice, so ideally all instances of service A should have access to same data. You can create multi master architecture in which you can connect your services to each replica by setting up a multi master data base. This articles gives you an overview on it scale-out-blog. However doing this will be having many implication and you need to carefully design your services to achieve this.
You can also create separate instances pointing to same DB in which you don't need to care about replication and other complex issues.
I have unique problem trying to see what is the best implementation for this.
I have table which has half million rows. Each row represents
business entity I need to fetch information about this entity from
internet and update back on the table asynchronously
. (this process takes about 2 to 3 minutes) .
I cannot get all these rows updated efficiently with 1 instance of
microservices. so planning to scale this up to multiple instances
my microservice instances is async daemon fetch business entity 1 at time and process the data & finally update the data back to the table.
. Here is where my problem between multiple instances how do I ensure no 2 microservice instance works with same business entity (same row) in the update process? I want to implement an optimal solution microservices probably without having to maintain any state on the application layer.
You have to use an external system (Database/Cache) to save information about each instance.
Example: Shedlock. Creates a table or document in the database where it stores the information about the current locks.
I would suggest you to use a worker queue. Which looks like a perfect fit for your problem. Just load the whole data or id of the data to the queue once. Then let the consumers consume them.
You can see an clear explanation here
https://www.rabbitmq.com/tutorials/tutorial-two-python.html
In my project, I have a microservice [say A] and it has a SQL database. We have a 5 node cluster and each of the node this microservice runs. So, We have 5 instances running of service A on the cluster. Now, suppose there is a select query in a particular function of the microservice that is retrieving data from the database. Now, since 5 instance are running, all the 5 instance will use the same query and will work on the same data. Is there any way, in which, we can divide data among 5 instances of service A.
Application clustering is different to database clustering. You cannot "divide" data among the 5 instances of application services since all application instances require a similar set of data to function (unless your application is designed to work on a subset of the data, i.e. each application instance is used to serve a specific list of countries, then you might be able to break the data up by country).
You can look into clustering at the database level for ideas on how you can cluster at the SQL level: https://www.brentozar.com/archive/2012/02/introduction-sql-server-clusters/ .