Mi sono messo a fare i conti con l'utilizzo di Route CN ponderato Route 53 per bilanciare le repliche di lettura RDS (e l'origine). Al momento ho 3 set di record CNAME per readdb.example.com.
I primi punti del db di origine in db.example.com. Questo è nel caso in cui ci sia un errore di replica. L'applicazione può tornare al database originale per le letture. Oppure, se lo desideri, puoi fare in modo che la sorgente carichi una parte del carico di lettura, a seconda di come imposti il peso. La politica di routing è impostata su ponderata. Il peso per la sorgente è impostato su 1, quindi richiede un carico molto piccolo del carico di lettura. Il TTL è impostato su un valore basso. Ho provato i valori da 1 a 10. L'ho lasciato a 10 per ora. Devi anche inserire un Set ID che è una stringa univoca ("Database di origine").
Il secondo set di record punta a una delle repliche di lettura (readdb1.blahblah.rds.amazonaws.com). Il criterio di routing è ponderato e TTL è 10 come prima. Ha anche bisogno di un ID set univoco. Ho impostato il peso per questo tra 5-50, a seconda. Questo, lo associo a un controllo sanitario, che devi creare prima del tempo. Probabilmente puoi usare un semplice healthcheck che punta alla replica, ma ho fatto qualcosa di leggermente diverso.
ho messo un file come questo su ciascuno dei miei server applicativi (sto usando PHP Elastic Beanstalk, ma si poteva fare qualcosa di simile in altre configurazioni/lingue presumo):
<?php if($instanceid = $_GET["id"]): ?>
<?php
exec("aws rds describe-db-instances --db-instance-identifier " . escapeshellarg($instanceid), $rdsinfo);
$rdsinfo = implode(' ',$rdsinfo);
$rdsinfo = json_decode($rdsinfo, true);
if($rdsinfo["DBInstances"][0]["StatusInfos"][0]["Normal"] && $rdsinfo["DBInstances"][0]["DBInstanceStatus"] === "available"){
echo "GOOD!";
}
else {
echo "BAD!";
};
/* Then there's some other stuff in here that is a little unrelated to the question */
?>
<?php endif ?>
utilizza questo file l'interfaccia della riga di comando di AWS installata sulle applicazioni Elastic Beanstalk e richiede solo che le variabili ambientali per AWS_ACCESS_KEY_ID, AWS_DEFAULT_REGION e AWS_SECRET_KEY siano specificate in anticipo. Quindi esegui un controllo sulla salute Route 53 che punta a http://www.example.com/rdshealthcheck/rdsshealthcheck.php?id=readdb1. Imposta la stringa di ricerca su "BUONA!" Penso che una stringa di ricerca costi $ 1/mese/controllo sanitario, il che sembra ragionevole.
Se si dispone di una seconda replica di lettura, è possibile creare un altro healthcheck che punti a http://www.example.com/rdshealthcheck/rdsshealthcheck.php?id=readdb2 o come si chiama.
ho effettivamente utilizzare solo una replica di lettura in questo momento, ma è significativamente più grande rispetto al mio db di origine. Per me è stato più economico, perché il mio DB di origine è multi-az. Mantengo il terzo set di record e il secondo controllo sanitario in giro nel caso in cui la prima replica mi dia problemi. In questo modo, non devo aspettare che il primo si cancelli prima di riavviarlo. Invece, cancello immediatamente il primo e avvio il secondo usando il nome specificato nel terzo recordset (e il secondo controllo dello stato).
Una cosa che mi preoccupa di questo approccio è che alcuni linguaggi come Java memorizza nella cache le risoluzioni DNS per migliorare le prestazioni che può portare a non avere il mio traffico ben equilibrato a tutte le mie repliche di lettura quanto qui di seguito: http://docs.aws. amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-jvm-ttl.html –
A meno che non si dispone di più istanze di back-end, che memorizza nella cache indirizzi diversi. –
@PauloMiguelAlmeida Grazie per l'informazione! – turutosiya