---
# System prepended metadata

title: App Java/Kotlin in Casavo vs Amazon RDS

---

# App Java/Kotlin in Casavo vs Amazon RDS 


## In soldoni ...

* AWS cambia sotto il culo il nodo `read` e il nodo `write`
* l'applicazione non cambia IP con cui risolve
* l'applicativo continua a provare a scriere sul nodo (IP) che conosce essere quello `write`
* la transazione non riesce a scrivere (ora a quell'IP risponde il nodo `read`)
* l'applicativo torna funzionante alla successiva risoluzione del DNS che restituisce l'IP del nodo attualmente in `write`

## References

* https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.html
* https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.FastFailover.html
* https://developers.redhat.com/e-books/kubernetes-native-microservices-quarkus-and-microprofile

## Possibili interventi

### pod service con http 

in congiunzione 
- connection pool "valido"
    - readyness probe che fa qualcosa (anche solo select)
    - nel caso di altri servizi (p.e. redis, fargli fare qualcosa anche su redis)
    - ogni 30 secondi (invece dei 5 di default)
    - mi assicura che che connessioni a db sono valide
- ttl
    - "Setting the java DNS time to live (TTL) to a low value, such as under 30 seconds"
    - [in corso prova su snake con 60 secondi](https://github.com/casavo/snake/pull/335)


### POD job (worker & co):
- ttl come sopra
- no connection pooling (usi una sola connessione)
- apre connessione quando serve
- e la chiudo appena finito

### dimensione del pool:
- lato postgres nostro max 20 connessione per utenza
- diversi pod di stessa app usano stesso utenza
- quante aperte all'inizio? -> configurabile da connector/framework
- da impostare su "quante operazioni in contemporanea per processo"
- devo conoscere come funziona JVM & co
- mentorship il martedì mattina -> 

### extra

- tcpKeepAlive 
    - come parametro del connector abilita, ma non sappiamo quali sono gli esatti valori usati nel nostro environment k8s/docker

## Other DB related errors

* `java.net.UnkownHostException postgres.production.k8s.casavo.com`
    - dipende dalla implementazione del newtork del cluster (calico)
    - non risolvibile lato applicativo
    - mitigato su nuovi cluster (hopefully)


## How can we test changes/improvements?

* minikube locale
    * posso provare come si comporta il singolo applicativo
    * get started di minikube
    * [helmchart bitnami cluster postgres](https://bitnami.com/stack/postgresql/helm)
    * applicazione in cluster locale (helm install con values dedicati a minikube)
    * cancello pod nodo `write` (forza `read` a diventare `write`)
    * 
* forziamo failover (staging)
    * avvisare tutte tribe per vedere cosa succede a tutte le app casavo
    * momento dedicato in cui tutti sono avvisati
* aspettiamo prossimo failover
    * incident / post mortem per vedere come è andata
    * tempo per tornare funzionante (write) -> dai log
    * ho dovuto riavviare il pod?
* [AuroraPostgreSQL Testing in code](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.FastFailover.html#AuroraPostgreSQL.BestPracticesFastFailover.Testing)
    * da leggere cosa propone, ma forse meglio non affidarsi a questi risultat


## DOING

* https://hackmd.io/@gVQRZNllSu2SN8GvQEmBpw/H1SsNmH4s/edit  

## Da approfondire

* redis -> client di connessione fa pool?

## altri linguaggi

* python -> @gi0baro
* elixir -> @danilo silva / @simo d'avico / @fabpel
* php -> no connection pool, doris si è dovuto riavviare
