Tìm kiếm
40 kết quả cho “Sync replication”. Tìm không phân biệt dấu.
- Evaluating MySQL Parallel Replication Part 2: Slave Group Commit Bài tóm tắt · Booking.com · 2015
…nt / binlog commit wait usec ở MariaDB, binlog group commit sync delay / ... no delay count ở MySQL): nhóm lớn hơn thì slave chạy song song được nhiều hơn, đổi lại master chậm đi m…
- Evaluating MySQL Parallel Replication Part 3: Benchmarks in Production Bài tóm tắt · Booking.com · 2015
…pdates ; slave có binlog; slave không binlog), độ bền (cao: sync binlog=1 , innodb flush log at trx commit=1 ; thấp: 0 và 2), và số luồng slave parallel threads . Kết quả (theo Boo…
- How Uber Scaled Data Replication to Move Petabytes Every Day Bài tóm tắt · Uber · 2026
…e của Uber (hơn 350 PB) nằm ở cả on-premises lẫn cloud. HiveSync (dựng từ dự án ReAir của Airbnb) giữ các lake đồng bộ, cả bulk lẫn tăng dần, dùng Distcp của Hadoop (copy phân tán…
- Me and my shadow (link!): Disaster recovery replication made easy Bài tóm tắt · Redpanda · 2026
…ng thật về khả năng DR thay vì giả định. Bài học cho SWE - Async replication luôn có cửa sổ mất dữ liệu (RPO 0); hỏi xem cửa sổ đó đo được và nhỏ cỡ nào (). - Thứ cần sao chép khôn…
- Better Crash-safe replication for MySQL Bài tóm tắt · Booking.com · 2014
…ug/feature request cho MySQL và đề xuất lưu thêm "vị trí đã sync cuối cùng" để chỉ cắt relay log tới đó, không tải lại tất cả. Cách làm tạm - Chạy Binlog Server ngay trên mỗi slave…
- Three Basecamp outages. One week. What happened? Bài tóm tắt · Basecamp · 2020
…liên DC vượt kích thướ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 p…
- Multi-region high availability for Kafka workloads with a single Stretch Cluster Bài tóm tắt · Redpanda · 2026
…cụm trông khoẻ nhưng broker sắp restart đang giữ replica in-sync duy nhất của một partition; restart là producer acks=1 có thể mất dữ liệu. - Sau khi restart: pod báo Ready với Kub…
- Business Continuity & Disaster Recovery in the Microservices world Bài tóm tắt · Walmart · 2019
Hệ Integrated Fulfilment (app và backend cho nhân viên cửa hàng soạn đơn pickup/giao hàng) tăng trưởng mạnh và được viết lại. Yêu cầu chính: liên tục kinh doanh; một sự cố ảnh hưởng khách hàng nhiều nước.
- Lessons from Deploying MySQL GTID at Scale Bài tóm tắt · Meta · 2014
…h (cách cũ không dùng được với GTID). - Kết hợp GTID + semi-sync: primary crash thì promote replica trong 30 giây, không mất dữ liệu ; primary cũ nếu còn nhất quán thì trỏ lại vào…
- Call me maybe: Kafka Bài tóm tắt · Jepsen · 2013
…n: mỗi partition một leader (bầu qua ZooKeeper) giữ ISR (in-sync replica); ghi commit khi mọi node trong ISR ack. LinkedIn tuyên bố chịu được f−1 lỗi với f node vì theo kinh nghiệm…
- Jepsen: Redpanda 21.10.1 Bài tóm tắt · Jepsen · 2022
…, quảng bá "không mất dữ liệu mặc định" vì chỉ ack sau khi fsync trên đa số replica (Kafka mặc định có thể ack trước fsync). - Ngữ nghĩa transaction của Kafka được tài liệu mô tả m…
- Postgres High Availability with CDC Bài tóm tắt · PlanetScale · 2025
…á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ờ một lần. - Slot là đối tượ…
- Atomic slot migration with Redis 8.4 Bài tóm tắt · Redis · 2026
…pike ở cả hai đầu. Atomic slot migration (ASM) - Giống full sync replication ở mức slot : chép toàn bộ nội dung slot sang đích kèm luồng delta, xong thì chuyển quyền sở hữu một lần…
- How we built a real-time service that handles 20,000 updates per second Bài tóm tắt · Trigger.dev · 2025
…cho phép subscribe sau sự kiện (). - Postgres lo ghi, tầng sync lo fan-out tới trình duyệt (). Bài học cho SWE - Realtime không đồng nghĩa với WebSocket: long poll trên luồng thay…
- How WhatsApp Grew to Nearly 500 Million Users, 11,000 cores, and 70 Million Messages a Second Bài tóm tắt · WhatsApp · 2014
…nghẽn tin tới nó (họ patch Mnesia để làm vậy khi replicate async dirty ); dùng cast thay call trừ khi cần kết quả từ DB; call dùng timeout thay vì monitor; nosuspend cho cast best-…
- SecDb Observability Journey Bài tóm tắt · Goldman Sachs · 2023
…cuối: ứng dụng ghi vào bất kỳ thành viên nào, tiến trình SecSync phân phối cập nhật và phát hiện bất nhất. - Giám sát cũ là một TSDB gắn chặt với SecDb cùng công cụ vẽ PlotTool, vố…
- 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:
- 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.
- 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ả…
- Cache và invalidation Chủ đề Thành viên
Cache là cách rẻ nhất để một DB chịu được lượng đọc tăng nhiều lần. Vì vậy nó xuất hiện ngay từ giai đoạn đầu (Instagram 2011, Facebook 2004–2010). Cái giá đến sau, và lặp lại ở hầu hết các nguồn:
- Batching và khấu hao round-trip Chủ đề Thành viên
Nhiều nút thắt không nằm ở việc mỗi thao tác tốn bao nhiêu công, mà ở chi phí cố định trả cho mỗi thao tác: một round-trip mạng, một lần fsync, một PUT lên object storage, một syscall, một transaction. Khi chi phí cố…
- Mã hoá đầu cuối và hệ thống mà server không được đọc Chủ đề Thành viên
Một hệ thống bình thường giả định server thấy hết dữ liệu: server fan-out tin nhắn, lưu bản sao lưu, đồng bộ thiết bị, thu log để vận hành, chạy model, chống lạm dụng. Khi sản phẩm hứa chính nhà vận hành cũng không đọc…
- Đổi ngôn ngữ và runtime Chủ đề Thành viên
Ngôn ngữ ban đầu được chọn để làm nhanh. Khi lớn lên, nó có thể thành nút thắt về hiệu năng, latency, hoặc tổ chức code. Có ba hướng: tối ưu runtime đang dùng, cải tiến dần, hoặc viết lại có phạm vi.
- 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…
- 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".
- Realtime và fan-out Chủ đề Thành viên
Một sự kiện (tin nhắn, ảnh, tweet, vote) phải tới rất nhiều người, rất nhanh, qua rất nhiều kết nối mở cùng lúc.
- 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…
- 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.
- 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…
- 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…
- 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:
- Booking.com Công ty Thành viên
Booking.com scale đọc bằng hàng nghìn slave MySQL (2014). Crash-safe replication của MySQL 5.6 tải lại binlog từ master sau mỗi lần khởi động, đè lên card mạng của master; họ đặt Binlog Server cục bộ trên slave để phục…
- How We Built a Cross-Region Caching Library Bài tóm tắt · Wix · 2022
…ỉ replication DB thì pod ở region B vẫn trả giá trị cũ. Một sync service đọc CDC của DynamoDB qua Kinesis Data Streams và đẩy thành message Kafka nội bộ (một topic mỗi bảng); một d…
- Disaster Recovery for Databases: High-availability Architecture of PolarDB-X Bài tóm tắt · Alibaba · 2026
…đồng bộ (nhanh, mất dữ liệu, failover cần người kiểm); semi-sync (gần 0, khi trễ thì tụt về bất đồng bộ nên vẫn có thể mất); đồng thuận đa số Paxos/Raft (RPO = 0, failover tự động…
- Jepsen Công ty Thành viên
Jepsen là dự án kiểm thử độc lập về tính an toàn của database và hệ phân tán, không phải một công ty kể về hệ của mình; báo cáo 6/2020 áp công cụ Elle lên PostgreSQL một node và tìm ra chế độ "serializable" không…
- Jepsen: MySQL 8.0.34 Bài tóm tắt · Jepsen · 2023
…ew; lỗi giả lập: pause, crash, partition, mất dữ liệu chưa fsync (LazyFS). Thay đổi chính (kết quả) - Repeatable Read cho phép G2-item (write skew) ngay trên một node khoẻ: 214 chu…
- Trigger.dev Công ty Thành viên
Nền tảng background job chạy trên Postgres. Năm 2024 vacuum bị chặn vì xmin horizon kẹt làm bảng queue (Graphile Worker) đầy dead tuple và CPU 99%; failover mới gỡ được . Năm 2026, để nâng cấp cụm Aurora 56 TB mà không…
- Walmart Công ty Thành viên
Nhiều team ở Walmart dùng Cassandra làm nguồn chính (hàng chục tới hàng trăm nghìn ops/giây). Năm bài học (2017): shard key nhân tạo chống partition lệch, tách Solr khỏi Cassandra, không đọc/ghi cả hàng, cẩn thận với…
- Instacart Công ty Thành viên
Năm 2020, để bật mã hoá at-rest cho RDS Postgres vài TB mà không downtime nhiều giờ, Instacart dựng replica logic từ snapshot (đẩy vị trí replication khớp LSN của snapshot) thay vì copy toàn bộ; cách này về sau dùng cho…