코드 저장소 위치를 찾은 경험 공유 내용, 2년 전 litestream과 litefs 사용에 불편함이 있었지만 이번에는 대부분의 문제가 해결된 느낌이라는 의견, 이제는 데이터베이스에 litestream을 자유롭게 적용할 수 있고 여러 writer 문제에 대한 걱정이 줄어들었다는 관점, read replica FUSE 레이어의 장점을 기대하는 입장, 관련 풀 리퀘스트에서 lease 인수 방식에 대해 소개(lease가 이미 있으면 새로운 프로세스가 1초 간격으로 재시도해 빠른 롤링 리스타트 지원), 실용적인 접근 방식이라는 생각
새로운 Litestream에서 내가 바라던 모든 기능이 구현된 것 같다는 느낌, 기대감과 흥분되는 감정
매우 똑똑하고 배포가 간단해지는 방식에 대해 긍정적 시각, 수천 개의 SQLite DB 백업이 필요한 상황에서 지금까지는 fanotify와 SQLite의 Backup API로 임시 방편을 제작 경험, wildcard replication이 많은 파일을 지원한다면 Litestream으로 전환하고 싶다는 기대
LTX 전환 이후 한 디렉토리에 수백, 수천 개의 데이터베이스가 있어도 /data/*.db 복제가 가능해진 점 강조, 이 부분이 이전에는 결정적 장애였다는 입장, 이젠 멀티 테넌트 환경에서 각 사용자 별 데이터베이스 단위로 원하는 시점 복구나 데이터 다운로드 및 이관이 가능해지는 점에 대한 긍정적인 전망
ben에게 감사 인사와 함께 실사용 경험을 공유, 약 1년 이상 write-heavy 내부용 케이스에(압축 기준 약 12GB) litestream을 프로덕션에서 사용하며 월 비용이 극소수(azure 기준 몇 백원)에 불과하다는 점 소개, 새로운 변경 사항 적용을 기대하는 입장
Fly의 SQLite 기반 개발자 경험이 좀 더 다듬어지길 바라는 마음, 현재 아쉬운 점으로 자체 UI와 CLI가 부족해 초기 데이터베이스를 Fly Machine에 세팅하는 작업이 생각보다 많은 과정이라는 점, fly console은 SQLite와 제대로 연동이 안되고 별도 머신에서 실행되어 데이터가 있는 볼륨에 접속할 수 없는 점, 결국 fly ssh console —pty로 직접 해당 머신에 들어가야 하는 불편함 지적, SQLite 기반 웹앱은 소규모가 대부분이라 수익을 내려면 많은 개수를 운영해야 한다는 고충
Rails 8과 SQLite 조합에 대한 개인의 선택 방향 질문, 최근 Postgres보다 더 선호하는지 궁금증 제기
Litestream을 막 조사하던 중 타이밍 좋게 글을 접한 개인적 경험 공유, VPS에서 Sqlite를 사용하며 Litestream 도입을 고려 중, Litestream 프로세스가 실행 중인 동안 특정 시점으로 데이터베이스를 복구할 수 있는지 질문, auto-checkpointing이 프로세스가 다운됐을 때 WAL을 소비하기 때문에 복구 불가 시간대(예시: 장애로 2:00~3:00 동안 프로세스 중지, 1:55 또는 3:05에는 복구 가능하지만 2:00~3:00 사이 복구 정보는 사라짐)에 대해 궁금증 표시
Litestream은 WAL 세그먼트를 특정 시간 단위로 저장, 기본적으로 WAL 변경 내역을 매초 전송해서(설정한 보존기간 내) 원하는 시점의 초 단위 복구가 가능하다는 설명
DST(일광절약시간) 처리 문제에 대한 질문, 유럽 기준 3월 30일에 2:00에서 3:00로 시간이 점프하는 상황에서의 동작 방식 궁금증 제기
과거 dynamodb 기반 DonutDB라는 sqlite vfs를 만든 경험 공유, S3에 CAS(Content Addressable Storage) 기능이 추가된 점을 계기로 DonutDB를 S3 지원 버전으로 리뉴얼하려고 했고, 이번에 lightstream이 이를 지원해줘서 직접 개발할 필요가 없어진 점 반가움 표시, 새로운 도구 사용에 대한 기대
S3에 CAS(Content Addressable Storage)가 추가됐다는 언급에 대해 공식 자료나 참고 링크를 요청, CAS 의미가 맞는지 확인하고 싶다는 궁금증 표현
앱 배포시 기존 방식에서는 새로운 서버 인스턴스를 띄워 헬스체크가 통과되면 트래픽을 전환하고 기존 서버를 종료하는데, 이 전환 과정에서 데이터베이스 변경사항 손실 문제가 있었다고 회상, 이번 변경 사항으로 이 문제가 해결됐는지 궁금증 제기
서버를 일회성 웹 서버 인스턴스가 아닌 프로덕션 데이터베이스 관점으로 봐야 한다는 의견, python/sqlite 웹앱 배포시 머신 전체를 바꾸지 않고 패키지만 업그레이드하고 systemd 서비스를 재시작하는 방식을 사용, 다운타임 줄이려면 SO_REUSEPORT 등으로 전환 과정을 고민할 수 있고, 이때 새 구버전 프로세스가 데이터베이스를 동시에 사용할 수 있지만 DB 스키마 변경이 포함되면 일정 다운타임은 불가피하다고 판단, 이는 다른 DB도 마찬가지일 수 있다는 견해
쉽게 해결되진 않는 문제라는 입장, 여전히 한 writer만 lease를 잡을 수 있기 때문, 새 서비스가 실행돼도 이전 writer가 내려가야만 lease를 얻을 수 있음, writer 교체를 위한 도구는 제공되지만 요청 대기 또는 짧은 다운타임은 어쩔 수 없다는 설명
litestream으로 사용자별로 수많은 데이터베이스를 복제하려면(문서에서 다루는 대표 use case), 런타임에 새로운 데이터베이스를 동적으로 추가할 방법이 궁금하다는 질문, 현재 설정 파일이 정적이고 실시간 API를 찾지 못했다는 경험 공유
이 문제는 결국 해결될 것으로 예상, 새로운 SQLite 탐지 로직이 까다롭지만 불가능하지 않다고 지적, 그 전까지는 라이브러리 형태로 쉽게 사용 가능하다는 안내
Hacker News 의견
코드 저장소 위치를 찾은 경험 공유 내용, 2년 전 litestream과 litefs 사용에 불편함이 있었지만 이번에는 대부분의 문제가 해결된 느낌이라는 의견, 이제는 데이터베이스에 litestream을 자유롭게 적용할 수 있고 여러 writer 문제에 대한 걱정이 줄어들었다는 관점, read replica FUSE 레이어의 장점을 기대하는 입장, 관련 풀 리퀘스트에서 lease 인수 방식에 대해 소개(lease가 이미 있으면 새로운 프로세스가 1초 간격으로 재시도해 빠른 롤링 리스타트 지원), 실용적인 접근 방식이라는 생각
새로운 Litestream에서 내가 바라던 모든 기능이 구현된 것 같다는 느낌, 기대감과 흥분되는 감정
매우 똑똑하고 배포가 간단해지는 방식에 대해 긍정적 시각, 수천 개의 SQLite DB 백업이 필요한 상황에서 지금까지는 fanotify와 SQLite의 Backup API로 임시 방편을 제작 경험, wildcard replication이 많은 파일을 지원한다면 Litestream으로 전환하고 싶다는 기대
LTX 전환 이후 한 디렉토리에 수백, 수천 개의 데이터베이스가 있어도 /data/*.db 복제가 가능해진 점 강조, 이 부분이 이전에는 결정적 장애였다는 입장, 이젠 멀티 테넌트 환경에서 각 사용자 별 데이터베이스 단위로 원하는 시점 복구나 데이터 다운로드 및 이관이 가능해지는 점에 대한 긍정적인 전망
ben에게 감사 인사와 함께 실사용 경험을 공유, 약 1년 이상 write-heavy 내부용 케이스에(압축 기준 약 12GB) litestream을 프로덕션에서 사용하며 월 비용이 극소수(azure 기준 몇 백원)에 불과하다는 점 소개, 새로운 변경 사항 적용을 기대하는 입장
Fly의 SQLite 기반 개발자 경험이 좀 더 다듬어지길 바라는 마음, 현재 아쉬운 점으로 자체 UI와 CLI가 부족해 초기 데이터베이스를 Fly Machine에 세팅하는 작업이 생각보다 많은 과정이라는 점, fly console은 SQLite와 제대로 연동이 안되고 별도 머신에서 실행되어 데이터가 있는 볼륨에 접속할 수 없는 점, 결국 fly ssh console —pty로 직접 해당 머신에 들어가야 하는 불편함 지적, SQLite 기반 웹앱은 소규모가 대부분이라 수익을 내려면 많은 개수를 운영해야 한다는 고충
Litestream을 막 조사하던 중 타이밍 좋게 글을 접한 개인적 경험 공유, VPS에서 Sqlite를 사용하며 Litestream 도입을 고려 중, Litestream 프로세스가 실행 중인 동안 특정 시점으로 데이터베이스를 복구할 수 있는지 질문, auto-checkpointing이 프로세스가 다운됐을 때 WAL을 소비하기 때문에 복구 불가 시간대(예시: 장애로 2:00~3:00 동안 프로세스 중지, 1:55 또는 3:05에는 복구 가능하지만 2:00~3:00 사이 복구 정보는 사라짐)에 대해 궁금증 표시
Litestream은 WAL 세그먼트를 특정 시간 단위로 저장, 기본적으로 WAL 변경 내역을 매초 전송해서(설정한 보존기간 내) 원하는 시점의 초 단위 복구가 가능하다는 설명
DST(일광절약시간) 처리 문제에 대한 질문, 유럽 기준 3월 30일에 2:00에서 3:00로 시간이 점프하는 상황에서의 동작 방식 궁금증 제기
과거 dynamodb 기반 DonutDB라는 sqlite vfs를 만든 경험 공유, S3에 CAS(Content Addressable Storage) 기능이 추가된 점을 계기로 DonutDB를 S3 지원 버전으로 리뉴얼하려고 했고, 이번에 lightstream이 이를 지원해줘서 직접 개발할 필요가 없어진 점 반가움 표시, 새로운 도구 사용에 대한 기대
앱 배포시 기존 방식에서는 새로운 서버 인스턴스를 띄워 헬스체크가 통과되면 트래픽을 전환하고 기존 서버를 종료하는데, 이 전환 과정에서 데이터베이스 변경사항 손실 문제가 있었다고 회상, 이번 변경 사항으로 이 문제가 해결됐는지 궁금증 제기
서버를 일회성 웹 서버 인스턴스가 아닌 프로덕션 데이터베이스 관점으로 봐야 한다는 의견, python/sqlite 웹앱 배포시 머신 전체를 바꾸지 않고 패키지만 업그레이드하고 systemd 서비스를 재시작하는 방식을 사용, 다운타임 줄이려면 SO_REUSEPORT 등으로 전환 과정을 고민할 수 있고, 이때 새 구버전 프로세스가 데이터베이스를 동시에 사용할 수 있지만 DB 스키마 변경이 포함되면 일정 다운타임은 불가피하다고 판단, 이는 다른 DB도 마찬가지일 수 있다는 견해
쉽게 해결되진 않는 문제라는 입장, 여전히 한 writer만 lease를 잡을 수 있기 때문, 새 서비스가 실행돼도 이전 writer가 내려가야만 lease를 얻을 수 있음, writer 교체를 위한 도구는 제공되지만 요청 대기 또는 짧은 다운타임은 어쩔 수 없다는 설명
litestream으로 사용자별로 수많은 데이터베이스를 복제하려면(문서에서 다루는 대표 use case), 런타임에 새로운 데이터베이스를 동적으로 추가할 방법이 궁금하다는 질문, 현재 설정 파일이 정적이고 실시간 API를 찾지 못했다는 경험 공유