Tìm kiếm
40 kết quả cho “Replica lag”. Tìm không phân biệt dấu.
- Evaluating MySQL Parallel Replication Part 3: Benchmarks in Production Bài tóm tắt · Booking.com · 2015
…um.com/booking-com-infrastructure/evaluating-mysql-parallel-replication-part-3-benchmarks-in-production-db5811058d74) Phần 3 của series "Evaluating MySQL Parallel Replication" (Jea…
- Evaluating MySQL Parallel Replication Part 2: Slave Group Commit Bài tóm tắt · Booking.com · 2015
…um.com/booking-com-infrastructure/evaluating-mysql-parallel-replication-part-2-slave-group-commit-459026a141d2) Phần 2 của series "Evaluating MySQL Parallel Replication" (Jean-Fran…
- Better Parallel Replication for MySQL Bài tóm tắt · Booking.com · 2015
…tps://medium.com/booking-com-infrastructure/better-parallel-replication-for-mysql-14e2d7857813) Phần 1 của series "Evaluating MySQL Parallel Replication" (Jean-François Gagné); phầ…
- 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:
- How we used delayed replication for disaster recovery with PostgreSQL Bài tóm tắt · GitLab · 2019
…[bài gốc](https://about.gitlab.com/blog/2019/02/13/delayed-replication-for-disaster-recovery-with-postgresql/) Bối cảnh - GitLab.com (2/2019): khoảng 3 triệu user, gần 7 triệu pro…
- Me and my shadow (link!): Disaster recovery replication made easy Bài tóm tắt · Redpanda · 2026
…ps://www.redpanda.com/blog/shadow-linking-disaster-recovery-replication-made-easy) Bài của nhà cung cấp giới thiệu tính năng của chính họ (Shadowing, bản enterprise). Mọi nhận định…
- Postmortem of database outage of January 31 Bài tóm tắt · GitLab · 2017
…snapshot đĩa Azure (chỉ bật cho máy NFS, không cho DB), và replication (chỉ để failover, không phải DR). Chuyện gì đã xảy ra - Tải DB tăng vọt (spam, cộng một job xoá cứng một nhâ…
- Automatic Apache Kafka Migrations With Orbit Bài tóm tắt · WarpStream · 2026
Chuyển một cụm Kafka sang WarpStream gồm ba phần: dữ liệu, consumer, producer. Một cụm thường phục vụ nhiều team.
- Avoiding Double Payments in a Distributed Payments System Bài tóm tắt · Airbnb · 2019
…lượng, xoá sớm quá thì mất tác dụng idempotent. - Không đọc replica : replica lag vài giây có thể khiến retry không thấy kết quả đã ghi ở master và trả tiền lần nữa. Scale master b…
- YouTube Architecture Bài tóm tắt · YouTube · 2007
…ạng xã hội sang cụm kém hơn. Sharding giảm 30% phần cứng và replica lag về 0. - Data center: từ managed hosting (sống bằng thẻ tín dụng) sang colocation để tự quyết phần cứng và hợ…
- Debugging Production with Event Logging Bài tóm tắt · Zillow · 2018
…code gây ra. Ba nguyên nhân: 1. Job chạy sau khi lưu đọc từ replica chưa kịp nhận bản ghi mới từ master. 2. Job được xếp hàng trong callback after save của Rails, chạy trước khi tr…
- From Always-On to On-Demand: Scaling Kafka Sinks with KEDA Bài tóm tắt · trivago · 2026
…hiệu tới quá muộn. Muốn chịu đợt cao điểm thì phải đặt min replica cao, chạy không 24/7. - Câu hỏi đúng là "có việc đang chờ không?", tức là consumer lag . Thay đổi chính - KEDA v…
- How We Cut Kafka Consumer Deployment Costs by 83% Bài tóm tắt · trivago · 2026
…ược consumer group, kéo dài mọi lần deploy; lag cao , và số replica đã bằng số partition nên không thêm pod được nữa. Đã có 19 sự cố P1 . Điều tra - Tái hiện dễ ở môi trường test:…
- How Uber Conquered Database Overload: From Static Rate-Limiting to Intelligent Load Management Bài tóm tắt · Uber · 2026
…eo độ dài; hàng đợi riêng cho đọc, ghi, chậm (scan, delete, replication); LIFO thích ứng : bình thường FIFO, quá tải thì LIFO để ưu tiên request mới còn cơ hội thành công, bỏ việc…
- Building Self-driving Kafka clusters using open source components Bài tóm tắt · Slack · 2022
…sumer thì chỉnh lại để vẫn là bội số. - Giới hạn băng thông replication khi rebalance (trước đó nó ăn hết tài nguyên của producer/consumer lúc cao điểm), và chỉ chuyển ít partition…
- Instacart's Item Availability Architecture: Solving for scale and consistency Bài tóm tắt · Instacart · 2023
Điểm availability real-time từ phần 2 phải phục vụ ba nhu cầu: lấy qua RPC của team ML; lọc hàng loạt ở bước retrieval của search (RPC quá chậm); và nhất quán giữa mọi màn hình (một nơi báo hết hàng, nơi khác báo còn là…
- The Stack That Helped Medium Drive 2.6 Millennia of Reading Time Bài tóm tắt · Medium · 2016
…dữ liệu mới cần truy vấn/lọc linh hoạt; Neo4j (1 master, 2 replica) cho quan hệ người–bài–tag–collection, đi đồ thị để gợi ý. - Dữ liệu phân tích: Redshift; nạp liên tục dữ liệu l…
- 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.
- Độ 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.
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), gọi đồng bộ từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn sự cố bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- 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…
- Chi phí hạ tầng và build vs buy Chủ đề Thành viên
Khi còn nhỏ, chi phí hạ tầng là chuyện phụ và cloud là lựa chọn hiển nhiên. Khi lớn lên, hoá đơn có thể chiếm phần lớn giá vốn. Hai câu hỏi xuất hiện: tối ưu chi phí trên nền đang có thế nào, và khi nào nên tự xây (hoặc…
- Load shedding, rate limit và backpressure Chủ đề Thành viên
Mọi hệ đều có lúc nhận nhiều việc hơn sức làm: spike của người dùng, client nội bộ có bug, dependency chậm đi, retry dồn lại. Theo Discord, khi chạm giới hạn năng lực thì đó là bài toán kinh tế: hoặc tăng cung (thê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,…
- 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:
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một mặt…
- Nền tảng ML (feature, training, serving, giám sát model) Chủ đề Thành viên
Model ML đầu tiên của một công ty thường được nhúng thẳng vào một service có sẵn, với feature tính trong vài script và train bằng một job riêng. Khi số model và số người làm model tăng, bốn chỗ cùng hỏng:
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- 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:
- Bảo mật hạ tầng và quản lý secret Chủ đề Thành viên
Khi hệ thống lớn lên, số credential (mật khẩu DB, API key, SSH key, token, cookie phiên) tăng theo số service, pipeline, nhà cung cấp, và chúng rải vào code, cấu hình, hệ build, log. Các nguồn trong wiki cho thấy kẻ tấn…
- GitLab Công ty Thành viên
GitLab.com (~3 triệu user, 2019) dùng một replica Postgres trễ 8 giờ để khôi phục sau một lần xoá nhầm trong 90 phút . Cùng năm, team Delivery bỏ release tháng có feature freeze và làm continuous delivery ngay trên hạ…
- The growing pains of database architecture Bài tóm tắt · Figma · 2023
…- Lên máy lớn nhất (r5.12xlarge → r5.24xlarge). - Thêm read replica. - DB mới cho tính năng mới. - PgBouncer khi số kết nối lên hàng nghìn. Giới hạn của các biện pháp này: lượt ghi…
- LinkedIn Công ty Thành viên
Bài khung là bài nhìn lại năm 2015 . LinkedIn bắt đầu năm 2003 là một monolith tên Leo. Service đầu tiên tách ra là member graph, vì đồ thị kết nối có profile tải khác hẳn; DB profile được đỡ bằng scale dọc rồi replica…
- How Figma's databases team lived to tell the scale Bài tóm tắt · Figma · 2024
…igma tăng gần 100 lần từ 2020 . Cuối 2022 đã có cache, read replica và khoảng 12 DB tách dọc (). - Họ đo trần theo nhiều chiều (CPU, IO, kích thước bảng, số hàng ghi) bằng dữ liệu…
- trivago Công ty Thành viên
Service PSE-kafka đẩy giá khách sạn sang dịch vụ Ads bị consumer lag kéo dài (19 sự cố P1) dù CPU chỉ 10%. Năm 2026 một đợt điều tra tìm ra ba nút thắt cùng lúc (consumer tự viết từ 2019, độ trễ cố ý trong RAM, pool…
- Migrating billions of records: moving our active DNS database while it's in use Bài tóm tắt · Cloudflare · 2024
…đầu Cloudflare dựa vào một cluster Postgres cfdb (primary + replica) cho hầu hết control plane. Từ khoảng 2017 nhiều service đã dời dữ liệu ra microservice riêng. - 2022: dữ liệu D…
- The Real Cost of a Single Insert in Postgres Bài tóm tắt · Tiger Data · 2026
…Các vòng lặp chồng nhau: nhiều index hơn → nhiều WAL hơn → replica trễ hơn; bloat lại đẩy người ta thêm index. Bài học cho SWE - Index là thuế ghi vĩnh viễn : index phục vụ một bá…
- Scaling Pinterest - From 0 To 10s Of Billions Of Page Views A Month In Two Years Bài tóm tắt · Pinterest · 2013
…embase. - Redis cho home feed chỉ snapshot mỗi 3 giờ, không replication: mất máy thì mất vài giờ dữ liệu, chấp nhận để đơn giản (bình luận dưới bài phản bác rằng điều này chỉ đúng…