Tìm kiếm
40 kết quả cho “Failover cluster”. Tìm không phân biệt dấu.
- 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:
- Multi-region high availability for Kafka workloads with a single Stretch Cluster Bài tóm tắt · Redpanda · 2026
…g bộ (mirroring) luôn để lại cửa sổ mất dữ liệu và cần bước failover. Thay đổi chính - Stretch Cluster (GA): một cụm logic có broker trải trên nhiều cụm Kubernetes, thường mỗi cụm…
- The exabyte club: LinkedIn's journey of scaling the Hadoop Distributed File System Bài tóm tắt · LinkedIn · 2021
…e (tới một giờ), mọi job phải dừng; nay nâng Standby trước, failover, rồi tới DataNode theo từng rack. - Tune Java: heap NameNode 380 GB cho 1,1 tỷ object; giữ tỉ lệ young:tenured…
- Scaling StreamHub: Transitioning from Kinesis to Kafka for 145 Billion Daily Events Bài tóm tắt · Atlassian · 2026
…không chỉ là kiểm soát chi phí. - Shard nhiều cụm + runbook failover cluster: chuyển shard (khoảng 15 phút), song song dựng cụm sạch từ IaC (khoảng 2 giờ), quá ngưỡng thì chuyển hẳ…
- Constraint Management for cluster operation safety and reliability at Twitter Bài tóm tắt · Twitter · 2023
Team Messaging (Kafka và PubSub) chạy hàng chục cụm Kafka broker trên hybrid Mesos, mỗi cụm từ vài chục đến vài trăm broker. Dữ liệu replicate n bản nên mất tối đa n-1 máy là an toàn; mất nhiều hơn thì lỗi publish.
- Incident review: API and Dashboard outage on 10 October 2017 Bài tóm tắt · GoCardless · 2017
…y nhiều, nên dựng cluster mới và chuyển traffic bằng cơ chế failover không downtime có sẵn: PgBouncer chạy sau một VIP riêng; tạm dừng query ở PgBouncer (xếp hàng) → promote → chuy…
- Scaling Production Globally — The service mesh facelift (Part-1) Bài tóm tắt · Achievers · 2022
…ata residency chặt. Các cụm Kubernetes đã có nhưng không có failover giữa region ; theo team SRE, mất một cụm hay một service trong region dễ xảy ra hơn mất toàn bộ GCP. - Yêu cầu…
- Controlled Chaos with Fault Injection Testing Bài tóm tắt · Riot Games · 2019
…ịnh từ tập thành viên đã biết. - Lỗi ở secondary chỉ lộ khi failover: phải tiêm lỗi đủ nhiều lần để đi qua đường promote. - Kill -9 thường xuyên làm cho kill -9 thành đường tắt máy…
- Follow Up - Preventing Upgrade Failures from etcd v3.5 to v3.6 Bài tóm tắt · etcd (CNCF) · 2025
etcd lưu thông tin thành viên cụm (membership) ở hai kho: v2store (cũ) và v3store. Ở v3.5, v2store là nguồn sự thật; ở v3.6, v3store là nguồn sự thật.
- How we rebuilt the search architecture for high availability in GitHub Enterprise Server Bài tóm tắt · GitHub · 2026
…ch chỉ lo replication document; GitHub tự viết workflow cho failover, xoá index, nâng cấp . - Rollout: tuỳ chọn từ bản 3.19.1 (bật cờ cấu hình rồi config-apply /nâng cấp); khi khở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.
- Jepsen: Amazon RDS for PostgreSQL 17.4 Bài tóm tắt · Jepsen · 2025
RDS for PostgreSQL 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 mức mạnh nhất trên mọi node…
- Improving Resiliency and Stability of a Large-scale Monolithic API Service Bài tóm tắt · LinkedIn · 2017
…g kế thừa config chung; - ước lượng cỡ cụm = QPS tối đa khi failover colo × 1,2 / QPS tối đa mỗi host. Thực tế sai từ 30–300%, nên phải đo lại; - chuyển traffic nội bộ (Rest.li D2)…
- 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…
- 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.
- 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…
- 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:
- 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ả…
- Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) Chủ đề Thành viên
Lỗi trong hệ phân tán là chắc chắn (máy chết, zone mất, dependency chậm, cấu hình sai), nhưng phần lớn lỗi nằm ở những tổ hợp hiếm mà test chức năng không chạm tới. Bài toán là chủ động gây lỗi để biết hệ thống phả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.
- 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:
- 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".
- 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…
- 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…
- Hạ tầng phục vụ LLM inference Chủ đề Thành viên
Phục vụ LLM giống một dịch vụ web ở chỗ cần scale theo tải, deploy phiên bản mới an toàn và phục hồi khi một process chết; nhưng ba đặc điểm làm các công cụ quen thuộc hỏng:
- 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:
- 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.
- 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…
- Resiliency and Disaster Recovery with Kafka Bài tóm tắt · eBay · 2020
…có một nơi ghi duy nhất hoặc số phiên bản để sắp lại (). - Failover hệ streaming không chỉ là đổi địa chỉ broker: còn offset của consumer và việc xử lý trùng (). - Cân nhắc lại có…
- Me and my shadow (link!): Disaster recovery replication made easy Bài tóm tắt · Redpanda · 2026
…ck khi ghi xong ở cụm nguồn; topic bóng chỉ đọc cho tới khi failover, để không lệch nội dung. Failover theo từng topic hoặc cả link; chỉ xoá link khi mọi luồng đã failover. - Recip…
- Redpanda Công ty Thành viên
Streaming tương thích Kafka, Redpanda Cloud chạy BYOC trên ba cloud. Trong sự cố GCP 12/6/2025, theo Redpanda, hàng trăm cluster không bị ảnh hưởng vì không có metadata hay dịch vụ quan trọng nằm ngoài cluster…
- 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…
- Uber Công ty Thành viên
Một vòng đủ: monolith → microservices → tổ chức lại microservices. Năm 2012–2013 Uber có hai monolith; khi lên hàng trăm kỹ sư thì tách. Lý do chủ yếu là tổ chức. Năm 2015 họ có 500+ service và phải chuẩn hoá contract…
- GitHub Công ty Thành viên
Rails + một MySQL; sau đó tách vài tính năng, thêm replica, ProxySQL; nhưng lõi vẫn là cluster mysql1 được scale dọc liên tục. Từ 2019 họ tách ảo bằng schema domain + linter rồi dời vật lý bằng Vitess hoặc write-cutover…
- Twitter Công ty Thành viên
Khi rời một MySQL duy nhất sang Cassandra và MySQL shard (Gizzard), thứ vỡ đầu tiên là sinh ID, dẫn tới Snowflake (64 bit, k-sorted, không phối hợp) . Sau World Cup 2010, họ nhận ra monolith Rails (~200 kỹ sư) và…
- Achievers Công ty Thành viên
Để mở rộng sang nhiều region với data residency và có failover giữa các cụm GKE, Achievers chuyển từ Kong sang Istio làm cả gateway lẫn service mesh (migration xong cuối 2020) và gặp một loạt vấn đề do sidecar . Phần 2…
- Cloudflare Công ty Thành viên
Cloudflare bắt đầu bằng một cluster Postgres cfdb cho hầu hết control plane; từ 2017 các service dời dữ liệu ra dần. Đến 2022–2024 dữ liệu DNS (hàng tỷ record) được tách sang cluster riêng, sau khi mọi service đã đi qua…
- A postmortem of our May 7, 2026 outage Bài tóm tắt · Coinbase · 2026
…c node bỏ phiếu phải nói chuyện xuyên AZ. Nhưng họ không có failover tự động sang AZ khác . - 21:29 AWS tắt EC2 trong placement group: 3/5 node chết, mất quorum . - Khôi phục cần s…
- Meta Công ty Thành viên
Facebook khởi đầu trên LAMP với mỗi trường đại học một DB; mở rộng bằng Memcache, rồi TAO, rồi data center riêng, edge cạnh ISP và region nhiều toà nhà. Giai đoạn 2010–2020 là các ca góc của hệ phân tán: bất nhất cache…
- Atlassian Công ty Thành viên
Atlassian lên AWS năm 2016. Tenant Context Service (ánh xạ tenant → vị trí, gọi nhiều lần trong mỗi request) được tối ưu qua bốn bài học "không có phép màu": DynamoDB, load balancer, cache, client . Cùng năm 2019, nền…