Tìm kiếm
40 kết quả cho “Primary”. Tìm không phân biệt dấu.
- How we've evolved on-call Bài tóm tắt · Monzo · 2019
…sau là . Bối cảnh - Từ bài 2018, Monzo đã có tuyến một gồm primary (kỹ sư kinh nghiệm, biết chỉ huy sự cố) và shadow (người mới học bằng cách quan sát), đều là tình nguyện viên có…
- How we made ClickStack 5x faster for ClickHouse observability Bài tóm tắt · ClickHouse · 2026
…ả workload rộng để bắt hồi quy ở chỗ khác. Thay đổi chính - Primary key bắt đầu bằng bucket thời gian: khoá cũ (ServiceName, TimestampTime) không cho tối ưu read in order (dừng sớm…
- How LinkedIn handles merging code in high-velocity repositories Bài tóm tắt · LinkedIn · 2020
…ày . Trunk-based development. - Ba ràng buộc: nhánh chính ( primary ) luôn xanh; commit vào nhanh; hệ phải tốt cho cả repo rất bận lẫn repo ít commit. - Xếp hàng merge từng commit…
- Goodbye to sequential integers, hello UUIDv7 Bài tóm tắt · Buildkite · 2023
…với vài thay đổi khác trong 6 tuần, tốc độ sinh WAL của DB primary giảm 50% và write IO giảm tương tự, giúp dựng read replica và làm các migration khác dễ hơn. - 2023, UUIDv7 làm…
- The evolution of SQL-based Observability Bài tóm tắt · ClickHouse · 2024
…ice/host/container). - Bài học khi khách triển khai: - Chọn primary/ordering key theo cách lọc ngay từ đầu (cột hay lọc nhất đứng đầu, theo thứ tự drill-down); quét tuyến tính khôn…
- Slack's Migration to a Cellular Architecture Bài tóm tắt · Slack · 2023
…ackend hỏng; Vitess nhất quán mạnh nên mỗi shard chỉ có một primary nhận ghi. Đây là gray failure : mỗi thành phần thấy tính sẵn sàng khác nhau (trong AZ hỏng thấy mọi thứ ổn, ngoà…
- Failover, replica và dự phòng dữ liệu Chủ đề Thành viên
Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:
- Sự cố và postmortem Chủ đề Thành viên
Nhiều bước ngoặt kiến trúc trong wiki bắt đầu từ một sự cố: Netflix lên cloud sau 3 ngày không gửi được DVD, Twitter viết lại hệ thống sau World Cup 2010, Instagram đi nhiều data center sau trận bão 2012. Trang này gom…
- Xử lý sự cố và on-call Chủ đề Thành viên
Khi hệ còn nhỏ, vài người biết hết mọi thứ; có lỗi thì người thấy đầu tiên sửa luôn. Khi có hàng trăm service và hàng trăm engineer, câu hỏi đổi khác:
- Độ tin cậy và multi-region Chủ đề Thành viên
Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một sự cố đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không còn đúng.
- Sharding và tách database Chủ đề Thành viên
Một database quan hệ duy nhất là điểm khởi đầu của hầu hết sản phẩm. Đến một lúc nó không chịu nổi lượng ghi, dữ liệu không còn vừa một máy, hoặc một sự cố ở DB đó làm sập mọi tính năng.
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- Chọn database theo workload Chủ đề Thành viên
Không có database tốt nhất, chỉ có database hợp với mẫu đọc/ghi ở một quy mô cụ thể. Mẫu đó thay đổi khi sản phẩm lớn lên. Ngoài ra, chuyên môn vận hành của đội cũng là một phần của "workload".
- Hạ tầng tìm kiếm Chủ đề Thành viên
Lúc đầu, tìm kiếm là LIKE trên database hoặc một thư viện (Lucene) nhúng trong app. Khi dữ liệu và tính năng tăng, search thành một hệ có trạng thái riêng, khác database ở mấy điểm:
- Query planner và hiệu năng truy vấn Chủ đề Thành viên
Database quan hệ không chạy SQL theo đúng cách nó được viết. Query planner chọn một plan (dùng index nào, join kiểu gì: nested loop, merge, hash; dừng sớm khi có LIMIT hay không) dựa trên thống kê về dữ liệu: số dòng,…
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- Mô hình tổ chức SRE Chủ đề
Lúc nhỏ, một team ops hay SRE tập trung trực và vận hành mọi thứ. Khi chuyển sang microservice và "you build it, you run it", team sản phẩm phải tự sở hữu service trên production, nhưng nhiều team chưa có kỹ năng, còn…
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- Scale dọc trước khi scale ngang Chủ đề
Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏng.
- Sinh ID phân tán Chủ đề Thành viên
Khi chỉ có một database, AUTOINCREMENT là đủ. Khi dữ liệu nằm trên nhiều máy, ID không còn duy nhất toàn hệ thống. Đây thường là thứ đầu tiên vỡ khi phân tán dữ liệu. Yêu cầu hay gặp: duy nhất, sắp được theo thời gian,…
- Ratequeue: Core Queueing-And-Rate-Limiting System (chaos engineering cho failover) Bài tóm tắt · Twilio · 2017
…ên một shard hỏng không ảnh hưởng shard khác); mỗi shard có primary + replica. - Vấn đề: primary hỏng thì tin nhắn trong shard đó đứng yên tới khi người trực thức dậy, vào VPN, đọc…
- Technical Secrets of PolarDB: High Availability - Smooth Switchover Bài tóm tắt · Alibaba · 2025
…e, mất mạng, đo throughput, latency, RTO, RPO. - Khác MySQL primary/secondary truyền thống (replicate binlog, mỗi bên một bản dữ liệu), PolarDB for MySQL dùng storage chia sẻ : pri…
- Lessons from Deploying MySQL GTID at Scale Bài tóm tắt · Meta · 2014
…d mode không đổi được lúc đang chạy và phải giống nhau giữa primary và replica, nên tài liệu bảo đặt primary read-only rồi tắt cả replica set cùng lúc , trái với yêu cầu sẵn sàng c…
- Incident review: API and Dashboard outage on 10 October 2017 Bài tóm tắt · GoCardless · 2017
…i cảnh - Dữ liệu quan trọng nhất nằm trên Postgres 3 node : primary + 1 replica đồng bộ + 1 replica bất đồng bộ (mỗi lần ghi thành công đều có ít nhất 2 bản). - Pacemaker tự promot…
- Postmortem of database outage of January 31 Bài tóm tắt · GitLab · 2017
…đứng tên xin lỗi). Bối cảnh - Đầu 2017, GitLab.com chạy một primary + một secondary hot standby PostgreSQL; secondary chỉ để failover, mọi tải dồn vào primary. Primary đã là điểm h…
- How we rebuilt the search architecture for high availability in GitHub Enterprise Server Bài tóm tắt · GitHub · 2026
…ều dựa vào nó. - Bản HA của GHES theo mẫu leader/follower : primary nhận mọi ghi, replica chỉ đọc và sẵn sàng thay thế. Mẫu này ăn sâu vào mọi thao tác vận hành. - Elasticsearch (b…
- Scaling our on-call process Bài tóm tắt · Monzo · 2022
…ô hình cũ (khoảng 50 engineer): một nhóm trực tuyến đầu gồm primary và shadow . Nhóm này nhận mọi alert, tự sửa hoặc tìm team có thể sửa; sau lưng là các nhóm chuyên gia làm điểm l…
- How Upstash Keeps Your Redis Up When an Availability Zone Isn't Bài tóm tắt · Upstash · 2026
…. Một kiểm tra nền định kỳ riêng để bắt split-brain. - Bầu primary không mất ghi: mỗi lệnh ghi mang số thứ tự tăng dần; replica đã thấy nhiều ghi nhất thắng . Hoà thì ưu tiên prim…
- Hardening EmergencyReparentShard in v25 Bài tóm tắt · Vitess (PlanetScale/CNCF) · 2026
…h - EmergencyReparentShard (ERS) là failover của Vitess khi primary của shard chết hoặc không liên lạc được. VTOrc dùng ERS để tự xử lý nhiều sự cố. Primary chết thì shard không gh…
- Postgres High Availability with CDC Bài tóm tắt · PlanetScale · 2025
…theo cách khó vận hành. Cách Postgres làm - Cụm chuẩn: một primary, hai standby semi-sync ( ANY 1 (r1, r2) ), một client CDC đọc logical replication slot (pgoutput), poll vài giờ…
- Postgres backups under the hood Bài tóm tắt · PlanetScale · 2026
…chiving: WAL được stream liên tục lên S3 (ở PlanetScale mỗi primary có sidecar wal-g ). Base backup chụp lúc database đang chạy nên file bị "nhoè" (trang có thể cũ, mới, hoặc hỏng…
- Three Basecamp outages. One week. What happened? Bài tóm tắt · Basecamp · 2020
…c replication buffer, rơi vào vòng resync làm quá tải Redis primary; Campfire và Pings ngừng. - 1/9 (17 phút sập hẳn): mạng giữa DC lại mất; trong lúc khôi phục một hardware load b…
- The Chubby lock service for loosely-coupled distributed systems Bài tóm tắt · Google · 2006
…ooKeeper. Bối cảnh - Trước Chubby, phần lớn hệ ở Google bầu primary bằng cơ chế tự chế hoặc cần người can thiệp sau mỗi lần hỏng. Chubby được thiết kế làm dịch vụ khoá thô (coarse-…
- VTOrc: Vitess-native Orchestrator Bài tóm tắt · Vitess (PlanetScale/CNCF) · 2022
…ốc của Vitess. Vì chỉ phục vụ một trường hợp (mỗi shard một primary, replica đọc thẳng từ primary, không có replication tầng), nó có thể có chính kiến và đơn giản hơn nhiều. Khác b…
- Moving to DynamoDB to Increase Application Resiliency Bài tóm tắt · CapitalOne · 2021
…st) , service tự failover gần như tức thì, trừ PostgreSQL : primary ở một region, read replica ở region kia, promote mất 10–15 phút . - Ràng buộc: chỉ dùng database managed trên AW…
- How We Built Fly Postgres Bài tóm tắt · Fly.io · 2022
…(cụm 2 node, metrics, health check, alert). Kiến trúc - Một primary, một replica gần đó qua streaming replication bất đồng bộ (WAL). Postgres không tự failover, nên dùng Stolon (Go…
- Partitioning GitHub's relational databases to handle scale Bài tóm tắt · GitHub · 2021
…riêng; thêm read replica; dùng ProxySQL giảm số kết nối tới primary. - Nhưng lõi vẫn là một cluster mysql1 chứa user, repo, issue, PR. Họ liên tục phải chuyển sang máy to hơn (scal…
- Rolling the Heroku Redis Fleet Bài tóm tắt · Heroku · 2018
…. Plan trả phí có HA: standby nhân bản bất đồng bộ, tự thay primary khi hỏng. Thay đổi chính - Immutable infrastructure : không SSH sửa máy; đổi gì thì build image mới và thay máy.…
- Jepsen: Amazon RDS for PostgreSQL 17.4 Bài tóm tắt · Jepsen · 2025
…tgreSQL Multi-AZ cluster: replication đồng bộ (ghi bền trên primary và ít nhất một secondary trước khi ack); endpoint ghi và endpoint đọc. Secondary không hỗ trợ Serializable, nên…