Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Verwendung einer dedizierten Reader-Instanz für Analysen
Führen Sie bei analyselastigen Workloads Ihre Fremdtabellenabfragen auf einer dedizierten Aurora-Reader-Instance aus, damit sie die OLTP-Arbeitslast auf Ihrem Writer nicht unterbrechen. Beachten Sie bei der Einrichtung dieses Readers Folgendes.
+ **Anpassen `shared_buffers`**: Abfragen von Fremdtabellen werden nicht verwendet`shared_buffers`. Sie können den Reader also verkleinern `shared_buffers` und vergrößern`query_mem`, um mehr Speicher pro Abfrage zur Verfügung zu stellen.
+ **Failover-Priorität**: Da das Lesegerät eher auf Analysen als auf Transaktionsdatenverkehr ausgelegt ist, ist es ein schlechtes Schreibgerät, wenn es während eines Failovers hochgestuft wird. Weisen Sie ihm Werbestufe 15 zu (die niedrigste Priorität), sodass Aurora zuerst einen Leser bewirbt, der auf Transaktionen eingestellt ist. Aurora kann es immer noch als letzten Ausweg bewerben, wenn keine andere Instanz verfügbar ist.
+ **Instanzendpunkt**: Connect Analytics-Clients mit dem Instanzendpunkt des Readers oder einem benutzerdefinierten Endpunkt und nicht mit dem Cluster-Reader-Endpunkt, der einen Lastenausgleich auf alle Leser durchführt und Abfragen von Fremdtabellen an Instances sendet, die für andere Workloads optimiert sind.
## Verwaltung lang andauernder Abfragen von Lesern
Long-running Abfragen in fremden Tabellen auf einem Reader wirken sich sowohl auf den Autor als auch auf den Leser aus.
+ **Auswirkung auf den Autor**: Eine lang andauernde Abfrage einer fremden Tabelle bei einem Reader behindert den Writer von der Bereinigung toter Tupel. Während die Abfrage ausgeführt wird, kann der Writer die toten Tupel nicht zurückgewinnen, die sein Vakuum normalerweise entfernt, sodass sie sich ansammeln und die Leistung des Writers beeinträchtigen. Da Abfragen in fremden Tabellen Minuten oder Stunden dauern können, ist dieser Effekt bei Analytics-Readern ausgeprägter.
+ **Auswirkung auf den Leser**: Eine Fremdtabellenabfrage greift auch auf lokale Katalogtabellen zu und kann sich mit regulären PostgreSQL-Tabellen verbinden, sodass sie wie jede andere Abfrage Seitenpuffer an den Reader anheftet. Diese Puffer sind zwar fixiert, aber DDL- oder Vakuumoperationen auf dem Writer können Replikationskonflikte (Snapshot, Lock oder Buffer-Pin) auslösen, die die Abfrage abbrechen oder den Reader neu starten. Da Abfragen in fremden Tabellen in der Regel länger laufen, ist die Wahrscheinlichkeit, dass sie auf diese Konflikte stoßen, höher.
Um diesen Effekt zu begrenzen, `statement_timeout` legen Sie im Analytics-Reader fest, wie lange eine einzelne Abfrage ausgeführt werden kann, und überwachen `oldest_reader_feedback_xid_age` Sie den Writer in Database Insights oder Amazon CloudWatch. Eine geführte Version dieser Diagnose und wie Sie die blockierende Abfrage beenden können, finden Sie unter [Auflösen identifizierbarer Vakuumblocker in Aurora PostgreSQL im *Amazon* Aurora Aurora-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Maintenance.html).