Replikacja baz danych SQL

Serwis otrzymuje dumpy bazy danych SQL. Po otrzymaniu dumpa stawia bazę z niego. Taka logika biznesowa, nie wchodźmy w to głębiej.

Te postawione bazy są readonly, tam by design nigdy nie będzie zapisów.

Ten serwis się skaluje na wiele instancji – ale fajnie jakby też skalować te postawione readonly bazy danych SQL. Chciałbym je replikować na wiele nodów po pomyślnym postawieniu bazy z dumpa.

Jak to zrobić i co poczytać?

Implementować to samemu od zera (czy chodzi o master-slave replication??) czy mogę skorzystać z jakiegoś bardziej gotowego rozwiązania (jakiego?), ale koniecznie SQL-agnostic bym chciał, bo dumpy są różnych typów baz.

Java Spring Kafka ale mogę dołożyć cokolwiek będzie trzeba

A czemu po prostu nie postawisz wielu instancji read only z tego dumpa ? Przed tym jakiś load balancer i będzie rozrzucać zapytania po bazach.
Bo jak rozumiem, nie ma tam żadnej real-time replikacji, tylko wpada plik sql i z niego powstaje baza. Skoro one są i tak read only, to po co replikować (w domyśle replikuje się zmiany, nie ma zmian - replikacja nie jest potrzebna).

A jak często te bazy są nadpisywane? Jaki problem chcesz rozwiązać tymi dodatkowymi nodami? Czy możesz się ograniczyć do jakiś ba danych, czy to ma być każdy istniejąca baza SQL Ile masz takich baz do zreplikowania. Co się dzieje z tymi bazami? Czy jest problem, jak będzie chwilowo baza niedostępna albo nieaktualna?

Legenda napisał(a):

ale fajnie jakby też skalować te postawione readonly bazy danych SQL. Chciałbym je replikować na wiele nodów po pomyślnym postawieniu bazy z dumpa.

Na chłopski rozum, baza która nie podlega aktualizacji ma znacznie lżej, nie gospodaruje transakcjami, nie tworzy loga transakcyjnego, nie zachodzi dezaktualizacja cache, tylko serwuje kwerendy select, mając bardzo pozytywny odzew od cache
Jest pewność, ze jeden node nie wytrzyma ?

@Legenda:
Przepracuj pytania od @S4t

Dzięki za rozjaśnienie tematu, muszę jeszcze to sobie poukładać.

Replikacja baz danych jest mechanizmem wbudowanym czasami w same silniki. W najprostszej wersji, jest master ze swoim transaction logiem (listą wykonanych na bazie komend), ten transaction log leci do replik, które go sobie przetwarzają i odbudowują stan.
Możliwe jest również zestawienie replikacji active-active, ale w takim przypadku programista musi zadbać o brak konfliktów zmian (np. jednoczesnej zmiany tego samego rekordu).
Na jakimś tam poziomie abstrakcji, to jak działa baza danych bardzo mocno przypomina event sourcing z cache stanu aktualnego. Baza dostaje zmiany w postaci listy komend CRUD, trzyma wyniki tych zmian w pamięci, co jakiś czas robi update plików z danymi i "odcina" transaction log. Czasami były bardziej rozbudowane schematy działania takich replik, podwójne zatwierdzanie itd.
Obecnie rzadko się spotyka wykorzystywanie takich mechanizmów i kierunek jest raczej na ogarnianie takich tematów za pomocą wzorców architektonicznych jak saga.

W twoim przypadku, z tego co rozumiem, chcesz skalować odczyt, np. masz bazę z kartoteką towarów i chcesz, żeby zwiększyć wydajność przeszukiwania różnych kategorii stawiając repliki. Ponieważ nie ma tu zmian danych, możesz to zrobić, jak ci radzą, czyli odtwarzać tę samą bazę na tylu instancjach ilu potrzebujesz, dorabiając do tego jakieś mechanizmy automatycznej aktualizacji, bo prawdopodobnie nie chcesz, żeby wynik był zwracany zawsze z tej samej wersji danych.