Ich muss die Aurora DB nach oben und dann später wieder herunter, aber ich brauche keine Ausfallzeiten nicht einmal ein bisschen. Ich mache es, indem ich aurora replica erstelle und es promote, dann skaliere ich primär und verkaufe es zurück zum primären. Aber das beinhaltet Ausfallzeiten. Bitte schlagen Sie einen alternativen Weg vor.Brauchen Sie Hilfe in Bezug auf Aurora DB-Skalierung
Ich würde Sie zuerst fragen, in welchem Sinne müssen Sie skalieren? Schreiben? lesen? Wenn Sie derzeit einen Server mit einem hohen Lese-/Niedrigschreib-Verhältnis ausführen, würde ich ein anderes Lese-Replikat (oder mehr) vorschlagen und dann Ihre Anwendung speziell so konfigurieren, dass sie das Lese-Replikat in den speziellen Fällen verwendet, in denen Sie gerade arbeiten Abfragen und nicht Ändern der Daten. In diesem Sinne laden Sie Ihre Schreibvorgänge auf eine separate Instanz der gleichen Daten um und lassen die primäre Schreibweise meist schreiben. Wenn Sie dies tun würden, würde ich auch vorschlagen, die gelesenen Replikate auf andere Verfügbarkeitszonen auszubreiten, falls die AZ Ihrer Primärdatenbank ausfällt, wird eine andere read-replica automatisch zu primary hochgestuft.
bewaffnet mit dieser Information, würde ich vorschlagen, dass Sie mit gelesenen Repliken skalieren, dass Ihre Anwendung konfiguriert ist, zu verwenden, dann können Sie diese Repliken herunterfahren, ohne die Aurora Primär herunterzubringen. Es ist eher ein Konfigurationsproblem im Umgang mit mehreren RDS-Endpunkten.
HTH.
ein Nachteil ist, dass es eine gewisse Verzögerung bei der Replikation zwischen primären und gelesenen Replikaten gibt (meine Instanzen zeigen etwa 10-20 Millisekunden), so müssen Sie dies beachten, wenn Sie einen Schreibvorgang durchführen und dann schnell hintereinander lesen - - Wenn das erste Lesen nach dem ersten Schreiben "zu schnell" erfolgt, sieht das Replikat die Änderung möglicherweise nicht und kann entweder keine Daten (beim Erstellen) oder veraltete Daten (wenn Sie aktualisieren) sehen.
Im Allgemeinen ist dies kein Problem, bis Sie unter starker Last stehen und die Schreibvorgänge auf der Primärdatenbank gesichert werden und Sie beginnen, die Lese-Replik zu lesen, bevor die Schreibvorgänge auf die Primärdatenbank angewendet wurden.
HTH.
danke für Ihre Hilfe. Hier möchte ich klarstellen, dass ich meinen primären Instance-Typ ohne Downtime von Medium auf Large ändern möchte. Ich könnte Lese-Replikat verwenden und es dann auf primärer Ebene heraufstufen und dann den Instanztyp meiner vorherigen primären Datenbank ändern und sie dann wieder auf die primäre Datenbank hochstufen. Aber hier wird es eine gewisse Ausfallzeit für meine Anwendung geben, da es manchmal dauert, bis das Replikat primär wird. Also würde ich gerne wissen, ob es möglich ist, den Instanztyp von aurora db zu ändern? Wenn ja, dann wie – Vicky
Nun, ich weiß es _is_ möglich, Replikate gelesen zu haben, die von einem anderen Dienstangebot sind (Amt von Speicher, CPU, Netzwerk, usw.) als das primäre. Ich denke, die einzige wichtige Sache ist, dass die Lese-Replik in der Lage ist, so viel Prozess zu speichern, wie Ihr db-Datenverkehr benötigt. Auf diese Weise, wenn Sie ohne Ausfallzeiten "skalieren" möchten, würden Sie (1) 'kleinere' Lese-Replik erstellen + warten, bis es vollständig fertig ist mit (2) Fail über die primäre (das können Sie ohne Ausfallzeit) (3) entweder Original-Primär entfernen oder entfernen und ein anderes, kleineres Read-Replika hochfahren. –
^^ Ich habe vergessen zu erwähnen - eine tolle Sache über AWS ist, dass Sie nur für eine Stunde experimentieren können und Sie werden für eine Stunde im Wert von Ressourcen - dann Spin alles runter und Sie sind nicht verpflichtet, etwas auszugeben mehr als das. Ein ganzer Testtag könnte zum Beispiel <75 $ sein. –