Вже згадував про можливості EXPLAIN в пості PostgreSQL: AWS RDS Performance and monitoring, але це настільки цікава і корисна штука, що варто про неї поговорити окремо. До того ж, в AWS RDS для PostgreSQL є можливість включити логування Execution Plans з EXPLAIN, що теж корисно для моніторингу і дебагу, тому подивимось як це включити і… Читати далі »
Мігруємо наш Backend API з DynamoDB на AWS RDS PostgreSQL, і кілька раз RDS падав. Власне, враховуючи те, що ми задля економії взяли db.t3.small з двома vCPU і двома гігабайтами пам’яті – то доволі очікувано, але стало цікаво чому ж саме все падало. Через кілька днів почав цю тему дебажити, і хоча причини поки не… Читати далі »
Продовжуємо рухатись до запуску нашого self-hosted GitLab в production. Див. попередні частини – GitLab: компоненти, архітектура, інфраструктура та запуск з Helm-чарту в Minikube та GitLab: Helm-чарт values, залежності та деплой у Kubernetes з AWS S3. Міграція даних Ще дуже хотілося написати пост про міграцію даних з GitLab Cloud до self-hosted, але немає часу, та й… Читати далі »
Продовжимо серію постів про Apache Druid. В першій частині розібралися з самім Друідом – його архітектурою та моніторингом, в другій частині – розгорнули кластер PostgreSQL та налаштували його моніторинг. Наступні задачі: переключити Druid на використання PostgreSQL в ролі metadata storage замість Apache Derby та прибрати зі схеми Apache ZooKeeper, а замість нього підключити druid-kubernetes-extensions Почнемо… Читати далі »
Отже, Друід ми запустили – див. Apache Druid: огляд, запуск в Kubernetes та моніторинг з Prometheus. Поки що в дефолтному вигляді, тобто в ролі сторейджа для метаданих використовується локальна база Apache Derby. Далі будемо переключати Друід на PostgreSQL, ще згодом – прибирати звідти ZooKeeper. Ну а для початку – запустимо кластер PostgreSQL в Kubernetes, додамо… Читати далі »