Globale aktive Tabellen in NDCS
Oracle NoSQL Database Cloud Service unterstützt eine globale aktive Tabellenarchitektur, in der Sie Tabellen erstellen, über mehrere Regionen hinweg replizieren und synchronisierte Daten über die regionalen Replikate hinweg verwalten können.
Unternehmen von heute müssen ihren Kunden schnellere und bessere Services bieten. Die Netzwerklatenz ist ein entscheidender Parameter für die Bewertung der Performance jeder Anwendung. Netzwerklatenz ist die minimale Zeit, die ein Datenpaket benötigt, um über das Netzwerk zu reisen. Nutzer erwarten, ihre Online-Aktivitäten von überall aus reibungslos und schnell abzuschließen. Um diese Erwartungen zu erfüllen, müssen Unternehmen Anwendungen und Daten in verteilten Regionen hosten, die ihren Benutzern am nächsten stehen.
Oracle NoSQL Database Cloud Service bietet eine Lösung für diese Anforderungen über Global Active-Tabellen. Mit diesem Feature können in einer Region geschriebene Anwendungsdaten transparent über mehrere Regionen hinweg repliziert werden.
- Lesen und schreiben Sie lokal, und greifen Sie global auf Ihre Daten zu: Eine Aktiv-Aktiv-Konfiguration von Global Active-Tabellen in mehreren Regionen stellt sicher, dass ein für eine Tabelle in einer Region ausgeführtes Update automatisch auf die Replikate der Tabelle in anderen Replikationsregionen repliziert wird. Auf die Daten kann von jeder replizierten Region aus zugegriffen werden.
- Performance: Mit Global Active-Tabellen können Sie Ihre Daten lokal lesen und schreiben. Dadurch erhalten Sie eine einstellige Millisekundenlatenz, die für den lokalen Zugriff für Ihre global verteilte Anwendung in beliebiger Größenordnung charakteristisch ist. Dies kann die Performance massiv skalierter globaler Anwendungen steigern und die Latenz für Anwendungsanforderungen reduzieren.
- Einfach einzurichten und zu verwalten: Oracle NoSQL Database Cloud Service macht das Deployment und die Verwaltung der Replikation mit mehreren Regionen mit globalen aktiven Tabellen überflüssig. Das Hinzufügen regionaler Tabellenreplikate ist einfach und kann mit APIs, Terraform oder der OCI-Konsole erfolgen.
- Mehrere Regionen - Ausfallsicherheit: Globale aktive Tabellen ermöglichen auch Fehlertoleranz bei einem seltenen Regionsfehler. Wenn eine einzelne Region nicht verfügbar oder offline ist, können die Anwendungsanforderungen an eine Region umgeleitet werden, in der die Tabelle repliziert wird. Lese- und Schreibvorgänge können für diese Tabelle ausgeführt werden.
Wie wähle ich ein globales aktives Setup in NDCS aus?
Mit dem Feature "Globale aktive Tabellen" können in einer Region geschriebene Anwendungsdaten transparent über mehrere Regionen hinweg repliziert werden.
Ein seltenes Ereignis eines Ausfalls einer einzelnen Region sollte die Benutzererfahrung nicht beeinträchtigen. Beispiel: Wenn eine einzelne Region offline, isoliert oder herabgestuft wird, sollte Ihre Anwendung in eine andere Region umgeleitet werden und weiterhin Lese- und Schreibvorgänge wie zuvor ausführen. Kurz gesagt, Ihre Datenbank muss Disaster Recovery bereitstellen, auch wenn eine Region ausfällt. Mit einer globalen aktiven Tabelle in Oracle NoSQL Database Cloud Service (NDCS) können Sie Disaster Recovery über eine aktiv-aktive Konfiguration bereitstellen oder Daten aktiv über mehrere Regionen hinweg replizieren, um mit lokalem Datenzugriff eine geringe Latenz zu erreichen.
Berücksichtigen Sie die Bedürfnisse eines Reisenden, der von einer beliebten Website einkauft. Sie können am selben Tag aus verschiedenen Teilen der Welt auf dieselbe Shopping-Website zugreifen. Sie müssen sicherstellen, dass die Benutzer eine minimale Latenzzeit und eine nahtlose Interaktion erhalten, unabhängig davon, wo sie sich befinden.
Das Feature "Globale aktive Tabelle" in NDCS bietet eine Lösung für beide oben beschriebenen Szenarios. Lassen Sie uns jedes der beiden Szenarios untersuchen und verstehen, wie eine Global Active-Tabelle die beste Lösung für High Availability, geringe Latenz und Disaster Recovery ist.
Gehen Sie im ersten Szenario davon aus, dass Ihr Unternehmen NDCS in Phoenix (US -West), Frankfurt (Deutschland) und Tokio (Japan) verwendet, und Sie haben eine Tabelle mit dem Namen ShoppingCart, in der die Einkaufsinformationen von Kunden gespeichert werden, die in verschiedenen Regionen der Welt einkaufen. In diesem Beispiel bedient Ihr Unternehmen seine Kunden über Data Center, die ihnen geografisch am nächsten sind. Ein solches Setup umfasst mehrere geografische Standorte, an denen Oracle NoSQL Database Cloud Service verfügbar ist. Eine Architektur mit mindestens zwei geografisch verteilten Regionen und dem NoSQL Database Cloud-Service, der in jeder dieser Regionen verfügbar ist, wird als globale aktive Tabellenarchitektur bezeichnet. Die Tabelle ShoppingCart ist eine globale aktive Tabelle und wird in mehreren Regionen repliziert.
In einer Aktiv-Aktiv-Konfiguration ist NDCS in mehreren Regionen verfügbar, und die Daten über alle Regionen hinweg werden synchronisiert. Wenn eine Region ausfällt, funktionieren globale aktive Tabellen in den anderen Replikatregionen weiterhin wie gewohnt und sind von der ausgefallenen Region nicht betroffen. Wenn die nicht erfolgreiche Region zurückkehrt, wird das regionale Tabellenreplikat mit den anderen Regionen synchronisiert. Die Tabelle Global Active bietet Disaster Recovery, wenn eine Region heruntergefahren ist und Ihre Anwendung mit einem anderen Replikat verbunden ist.
Im zweiten Szenario gehen Sie davon aus, dass der Benutzer in Phoenix online einkauft und seinem Warenkorb ein Mobiltelefon hinzufügt. Die NDCS-Region an der Westküste dient dieser Session, und der Benutzer erlebt eine minimale Lese- und Schreibanforderungslatenz aus dem lokalen Datenspeicher der Region. Dieser Benutzer steigt dann in ein Flugzeug nach Deutschland, landet 13 Stunden später, kommt zum Hotel, verbindet sich mit dem WLAN-Netzwerk, geht zum Online-Shop des Mobilunternehmens und findet, dass es ein anderes Modell des Telefons gibt, das attraktiver aussieht. So beschließt der Benutzer, den Warenkorb mit diesem neuen Modell des Telefons zu aktualisieren und fährt fort, den mobilen E-Commerce-Shop zu durchsuchen. Der regionale Datenspeicher in Frankfurt, dem proximalsten Datenspeicher, dient dieser Session und bietet dem Benutzer die gleiche Lese- und Schreiberfahrung mit geringer Latenz wie in den USA. Der Benutzer reist dann nach Japan und beschließt, einen lokalen mobilen Laden zu besuchen, um mehr Informationen über die neuesten Mobilmodelle zu erhalten. Der Benutzer aktualisiert dann den Warenkorb mit dem neuesten Modell des Telefons, das im Mobile Store vorhanden ist. Da NoSQL Database Cloud Service in drei Regionen verfügbar ist, eine in Phoenix, eine in Deutschland und eine in Japan, und es gibt mehr als eine regionale Tabellenreplik, wenn der Benutzer den Warenkorb aktualisiert oder den mobilen E-Commerce-Shop durchsucht, werden die personalisierten Suchergebnisse und andere Daten aus einer lokalen Region abgerufen, die dem Benutzer am nächsten ist. Diese Art der lokalen Verarbeitung bietet die geringsten Latenzen, die beste Performance und eliminiert den Wide Area Network-Zugriff.
Grundlagen
In globalen aktiven Tabellen verwendete Terminologie:
- Region: Eine Oracle Cloud Infrastructure-(OCI-)Region. Es handelt sich um einen einzigen lokalisierten geografischen Bereich, in dem Kunden ihre Anwendungen bereitstellen können.
- Absenderregion: Eine Region, aus der eine Tabellenaktualisierung auf andere Regionen repliziert wird.
- Empfängerregion: Eine Region, in der die Tabellenaktualisierung von einer anderen Region empfangen wird.
- Singleton-Tabelle: Eine Tabelle, die nicht regional repliziert wird.
- Regionales Tabellenreplikat: Ein Replikat einer Tabelle, die in einer anderen Region erstellt wurde.
- Globale aktive Tabelle: Eine Tabelle, die mindestens ein regionales Tabellenreplikat enthält.
Grundlegende Regeln zum Erstellen und Verwalten von globalen aktiven Tabellen:
- Die Singleton-Tabelle muss mindestens eine JSON-Spalte enthalten.
- Der Schemastatus der Tabelle muss FROZEN lauten.
- Im Empfängerbereich darf noch keine Tabelle mit demselben Namen vorhanden sein.
- In der Empfängerregion muss das Compartment (mit demselben Namen wie das Compartment in der Absenderregion) bereits vorhanden sein.
- Vor dem Löschen einer Tabelle müssen alle regionalen Tabellenreplikate der Tabelle entfernt werden.
Hinweis:
In NDCS wird die regionale Tabellenreplikation asynchron im Hintergrund ausgeführt.Sie können untergeordnete Tabellen in einer globalen aktiven Tabelle erstellen. Eine untergeordnete Tabelle einer globalen aktiven Tabelle kann eine Singleton-Tabelle oder eine globale aktive Tabelle sein. Um die untergeordnete Tabelle zu einer globalen aktiven Tabelle zu machen, müssen Sie das Schema der untergeordneten Tabelle einfrieren und ein regionales Replikat hinzufügen. Sie können aus einem der regionalen Replikate der übergeordneten Tabelle auswählen.
Globaler aktiver Tabellenworkflow
Was wird in einer globalen aktiven Tabelle repliziert?
- Tabellendefinition/Schema
- Indizes in der Tabelle - Anzahl und Definitionen sekundärer Indizes.
- Daten in der Tabelle.
- Lesekapazität und Schreibkapazität - Standardmäßig entspricht der Lesegrenzwert eines regionalen Replikats dem aller anderen regionalen Replikate der globalen aktiven Tabelle. Lesevorgänge sind jedoch rein lokal, sodass Sie optional die eigenen Leselimits für jede Region festlegen können. Standardmäßig entspricht der Schreibgrenzwert eines regionalen Replikats dem aller anderen regionalen Replikate der Global Active-Tabelle. Schreibgrenzen können jedoch in jeder Region auf unterschiedliche Werte festgelegt werden.
- Speicherkapazität: Da alle regionalen Replikate der globalen aktiven Tabelle dieselben Tabellendaten speichern, wird der Speichergrenzwert eines regionalen Replikats in alle anderen regionalen Replikate der globalen aktiven Tabelle kopiert.
- Standardtabellengültigkeitsdauer (TTL) der Tabelle
Regionales Tabellenreplikat hinzufügen
Hinweis:
Wenn Sie ein regionales Tabellenreplikat hinzufügen, wird die Tabelle in der Empfängerregion in demselben Compartment mit demselben Tabellennamen wie die Tabelle in der Absenderregion platziert. Während der Lebensdauer der globalen aktiven Tabelle können Sie sie jederzeit in ein anderes Compartment verschieben.Kapazität (Leseeinheiten, Schreibeinheiten und Speicher) für regionale Tabellenreplikate
Wenn Sie ein regionales Replikat einer Tabelle hinzufügen, werden in den Feldern Lesekapazität, Schreibkapazität und Speicherkapazität automatisch die entsprechenden Werte der Tabelle in der Absenderregion vorgegeben. Sie können jedoch die Werte der Lese- und Schreibkapazität der Tabelle im Empfängerbereich bearbeiten und ändern. Die Speicherkapazität der Tabelle kann nicht geändert werden. Die Tabelle in der Empfängerregion hat dieselbe Speicherkapazität wie die Tabelle in der Absenderregion. Der Kapazitätsmodus einer globalen aktiven Tabelle kann entweder bedarfsgesteuert oder bereitgestellt werden. Sie können auch den Kapazitätsmodus jedes regionalen Replikats für eine globale aktive Tabelle ändern, nachdem sie erstellt wurde. Die Änderung des Kapazitätsmodus ist lokal für dieses regionale Replikat und wirkt sich nicht auf andere regionale Replikate der Global Active-Tabelle aus.
TTL von Datensätzen in regionalen Tabellenreplikaten
Die Tablesezeit (TTL) gibt an, wie lange (Anzahl der Stunden oder Tage) die Daten in der Tabelle gültig sind. Mit Oracle NoSQL Database Cloud Service können Entwickler eine Ablaufzeit für Tabellenzeilen festlegen, nach der die Zeilen automatisch ablaufen und nicht mehr verfügbar sind. Nach der angegebenen Dauer laufen die Zeilen automatisch ab und sind nicht mehr verfügbar. Die TTL im regionalen Tabellenreplikat ist derselbe Wert wie die TTL der Tabelle in der Absenderregion. Wenn eine Zeile auf andere Regionen repliziert wird, wird ihre Ablaufzeit als absoluter Zeitstempel repliziert. Daher läuft diese Zeile gleichzeitig ab, unabhängig davon, wann sie repliziert wurde.
Nachdem ein regionales Tabellenreplikat erstellt wurde, wird es mit den Daten aus der Tabelle der Absenderregion initialisiert. Wenn während dieser Initialisierung der Tabellendaten der TTL-Wert erreicht wird, laufen diese Zeilen ab, und ein Lesevorgang sieht diese Datensätze nicht.
Geltungsbereich von DDL-Vorgängen, nachdem regionale Tabellenreplikate erstellt wurden:
- Index hinzufügen
- Index löschen
- Änderung der Speicherkapazität der Tabelle
- Änderung in Tabelle TTL
- Änderung bei Leseeinheiten
- Änderung bei Schreibeinheiten
- Änderung des Kapazitätsmodus von "Bei Bedarf" in "Bereitgestellt" oder umgekehrt
Überlegungen zur Datenmodellierung für globale aktive Tabellen
Warum müssen Sie das Schema einer Tabelle fixieren?
In einer globalen aktiven Tabellenkonfiguration sind Tabellen in NDCS über mehrere Regionen hinweg bereitgestellt, und alle Regionen verarbeiten gleichzeitig Lese- und Schreibanforderungen. Die Anwendung, die eine Verbindung zu NDCS herstellt, sollte so ausgelegt sein, dass sie eine Verbindung zur nächsten Replikationsregion herstellt. Primärschlüssel, Shard-Schlüssel und Daten der Tabelle müssen in allen Replikationsregionen identisch sein, da diese drei Elemente ein wesentlicher Bestandteil der Verwendung der Tabelle und der Ausführung von Abfragen sind. Da die Tabellendatensätze in einer globalen aktiven Tabelle in mehreren Regionen gleichzeitig in die Tabelle geschrieben werden können, muss ein Konsens über das Schema für die Tabelle erreicht werden. Sie können dies tun, indem Sie verhindern, dass sich das Schema ändert und alle Regionen in einen sofortigen Konsens über das Schema für eine Tabelle zwingen. Der Einfachheit halber erfordert der Oracle NoSQL Cloud Service, dass ein Schema für jede Tabelle eingefroren wird, die an der regionalen Replikation teilnimmt. Daher muss das Tabellenschema vor der Konvertierung einer Singleton-Tabelle in eine globale aktive Tabelle gesperrt werden, und es sind keine weiteren Schemaänderungen zulässig. Wenn Sie das Schema einer globalen aktiven Tabelle nach dem Erstellen regionaler Replikate ändern müssen, müssen Sie zuerst alle regionalen Replikate löschen, das Schema der Tabelle ändern und dann die regionalen Replikate erneut hinzufügen. Der Oracle NoSQL Cloud-Service füllt alle regionalen Replikate mit den aktuellsten Daten aus der Absenderregion erneut auf.
Warum ist beim Fixieren des Schemas mindestens eine JSON-Spalte in einer Tabelle erforderlich?
Die Koordination einer Schemaänderung in regionalen Tabellenreplikaten ist schwierig und führt zu potenziellen Fehlerfällen. Die Bereitstellung einer JSON-Spalte bietet mehr Flexibilität im Schema und verhindert eine Schemaänderung.
Identität in einer globalen aktiven Tabelle definieren
-
Die Identität eines Datensatzes in einem regionalen Tabellenreplikat muss für alle regionalen Replikate der Tabelle eindeutig sein. Natürliche Schlüssel (global eindeutige IDs, die jeden Datensatz in einer Tabelle identifizieren) können nur dann als Identität in globalen aktiven Tabellen verwendet werden, wenn sie die Eindeutigkeit in allen regionalen Tabellenreplikaten gewährleisten können.
- Bei der Verwendung der systemgenerierten Identität in einer globalen aktiven Tabelle muss UUID verwendet werden. In den meisten Fällen sollte die Identitätsspalte nicht verwendet werden, da sie in regionalen Tabellenreplikaten nicht eindeutig ist.
Policys und Benutzerberechtigungen
Die IAM-Policys einer Tabelle sind spezifisch für die Absenderregion.
Wenn ein Benutzer ein Replikat einer Singleton-Tabelle oder einer globalen aktiven Tabelle hinzufügt, wird keine Policy oder Benutzerberechtigung in der Empfängerregion hinzugefügt. Der Benutzer in der Quellregion, der Replikate erstellen und verwalten möchte, muss außerdem über die erforderlichen Berechtigungen im Empfängerbereich verfügen. Andernfalls wird ein Fehler angezeigt, wenn der Benutzer ein regionales Tabellenreplikat hinzufügt.
Nachdem die regionalen Tabellenreplikate erstellt wurden, erfordert die Replikation von Datenänderungen von einer Absenderregion in die Empfängerregion keine Benutzerberechtigung. Das bedeutet, dass Datenänderungen in einer Replikattabelle unabhängig von der Benutzerberechtigung in allen anderen Tabellenreplikaten repliziert werden. Die Berechtigungen, die zum Erstellen und Verwalten der regionalen Tabellenreplikate erforderlich sind, werden unten aufgeführt.
Replikat hinzufügen:
Die Benutzer, die Replikate einer Tabelle verwalten möchten, müssen NOSQL_TABLE_ALTER Berechtigung in der Absenderregion und in allen vorhandenen Empfängerregionen haben. Die Benutzer, die ein neues Replikat erstellen möchten, benötigen NOSQL_TABLE_CREATE-Berechtigung in der Empfängerregion (in der ein Replikat erstellt werden muss). Wenn Sie ein regionales Tabellenreplikat erstellen, wird die vorhandene Lese- und Schreibberechtigung der Tabelle in der Absenderregion nicht in der Empfängerregion erstellt. Die Benutzer, die ein neues Replikat in der Empfängerregion erstellen möchten, sind für die Erstellung der Lese- und Schreibberechtigungen der Tabelle für jedes von ihnen erstellte regionale Tabellenreplikat verantwortlich.
Replikat löschen:
Die Benutzer, die Replikate einer Tabelle verwalten möchten, müssen über die Berechtigung NOSQL_TABLE_ALTER in der Absenderregion und in allen vorhandenen Empfängerregionen verfügen. Die Benutzer, die ein Replikat löschen möchten, benötigen die Berechtigung NOSQL_TABLE_DROP in der Empfängerregion (in der ein Replikat gelöscht werden muss).
Index erstellen:
Die Benutzer, die Indizes in regionalen Tabellenreplikaten erstellen möchten, benötigen die Berechtigung NOSQL_INDEX_CREATE.
Index löschen:
Die Benutzer, die Indizes in regionalen Tabellenreplikaten löschen möchten, benötigen die Berechtigung NOSQL_INDEX_DROP.
Tabellenlimits/TTL/ aktualisieren:
Die Benutzer, die Replikate einer Tabelle verwalten möchten, müssen über die Berechtigung NOSQL_TABLE_ALTER in allen regionalen Tabellenreplikaten verfügen.
Lese-, Schreib- und ACID-Transaktionen
Nachdem Sie eine globale aktive Tabelle erstellt haben, können Sie Lese- oder Schreibvorgänge für die Tabelle mit den vorhandenen Datenzugriffs-APIs oder DML-Anweisungen ausführen.
Für die beste Latenz wird Ihre Anwendung in der Regel aus einem lokalen regionalen Replikat gelesen. Die Daten im lokalen regionalen Replikat umfassen auch die Datenaktualisierungen, die aus anderen regionalen Tabellenreplikaten repliziert werden. Wenn Sie einen Schreibvorgang (INSERT, UPDATE oder DELETE) für eine globale aktive Tabelle ausführen, werden die Änderungen asynchron über mehrere Regionen hinweg repliziert. Wenn Sie also eine Zeile in der Absenderregion schreiben, wird der Schreibvorgang vollständig in der Absenderregion ausgeführt, ohne darauf zu warten, dass die Replikatregionen aktualisiert werden. Wenn mehrere Regionen eine Zeile mit demselben Primärschlüssel aktualisieren, wird eine Regel angewendet, um zu entscheiden, welche Aktualisierung der Region als endgültig betrachtet wird. In allen diesen Fällen führt diese integrierte Konfliktlösungsregel dazu, dass das Update mit dem letzten Zeitstempel gewinnt und in der Datenbank festgeschrieben wird. Diese Regel gilt auch, wenn der TTL-Wert aus mehreren Regionen gleichzeitig aktualisiert wird.
ACID-Transaktionen sind lokal für eine Region. Wenn eine Transaktion festgeschrieben wird, ist sie nur in der Region, in der sie geschrieben wurde, atomar, konsistent, isoliert und dauerhaft. Die Konsistenzmodellsemantik eines regionalen Tabellenreplikats ist mit der einer nicht replizierten Tabelle identisch. Die Konsistenz der regionalen Tabellenreplikate ist nicht absolut. Absolute Konsistenz ist lokal für eine einzelne Region, in der Sie den Lesevorgang ausführen. Lesezugriffe auf die Daten, die von der Absenderregion in die Empfängerregionen repliziert werden, sind immer konsistent.
Schreibvorgänge aus einer Absenderregion werden innerhalb einer Zeitverzögerung über alle Empfängerregionen hinweg repliziert. Diese Zeitverzögerung zum Replizieren der Änderungen über mehrere Regionen hinweg umfasst die Zeit, die für den Empfang der Daten aus dem regionalen Tabellenreplikat in der Absenderregion und die Zeit, die für den Abschluss der Schreibvorgänge in der Empfängerregion benötigt wird. Schließlich erhält die Empfängerregion die Aktualisierung aus der Absenderregion, und die Empfängerregion verpasst nie eine Transaktionsaktualisierung, die in der Absenderregion erfolgt ist. Alle regionalen Tabellenreplikate erhalten schließlich das Schreiben und werden dauerhaft.
Überblick über Replica Lag
Wenn Sie einen Schreibvorgang (INSERT, UPDATE oder DELETE) für eine globale aktive Tabelle ausführen, werden die Änderungen asynchron über mehrere Regionen hinweg repliziert.
Wenn Sie also eine Zeile in der Absenderregion schreiben, wird der Schreibvorgang vollständig in der Absenderregion ausgeführt, ohne darauf zu warten, dass die Replikatregionen aktualisiert werden. Die Netzwerklatenz führt bei der Replikation der Änderungen an den Empfängerregionen zu einer Zeitverzögerung. Die Latenz für die Replikation der Änderungen über mehrere Regionen hinweg umfasst die Zeit, die für den Empfang von Schreibvorgängen aus dem Replikat und deren Anwendung in der Empfängerregion benötigt wird. Wenn keine Anwendungsschreibvorgänge für die Tabelle in der Absenderregion vorhanden sind, verwendet der Service die Ping-Mechanismen, um eine Annäherung der Verzögerung zu berechnen. Die Lag-Statistik ist weiterhin in der Empfängerregion verfügbar.
Weitere Informationen zur Replikationsverzögerungsmetrik finden Sie unter Details zu Replikationsverzögerungen.
Übersicht über das Erstellen einer globalen aktiven Tabelle
Beim Erstellen einer globalen aktiven Tabelle wird zunächst eine Singleton-Tabelle erstellt und anschließend in eine globale aktive Tabelle konvertiert.
- Erstellen Sie eine Singleton-Tabelle, und stellen Sie sicher, dass eine Spalte JSON ist.
- Ändern Sie den Schemastatus der Tabelle von Wechselbar in Gesperrt.
- Legen Sie die Region fest, in der Sie ein regionales Replikat der Tabelle hinzufügen möchten. Beim Hinzufügen eines regionalen Replikats werden die Felder "Lesekapazität", "Schreibkapazität" und "Speicherkapazität" automatisch mit den entsprechenden Werten der Absenderregion aufgefüllt. Sie können die Lese- und Schreibkapazität der Tabelle ändern.
- Der Cloud-Service erstellt die Tabelle in der Empfängerregion. Wenn die Tabelle in der Quellregion Daten enthält, wird mit dem Kopieren von Daten aus der Absenderregion in die Empfängerregion begonnen. Beim Kopieren der Daten aus der Absenderregion in die Empfängerregion erhöht sich der Initialisierungsprozentsatz von 0 auf 100. Sie können den Wert des Initialisierungsprozentsatzes unter den Tabelleninformationen in der OCI-Konsole wie unten gezeigt anzeigen. Im neuen regionalen Tabellenreplikat sind keine DML-Vorgänge zulässig, bis der Initialisierungsprozess abgeschlossen ist.
