Mereplikasi data dari Spanner ke Spanner Omni

Dokumen ini menjelaskan pola, langkah-langkah konfigurasi, dan panduan operasional untuk menyiapkan topologi disaster recovery antara Spanner terkelola di Google Cloud dan Spanner Omni di lingkungan eksternal seperti AWS atau pusat data lokal.

Dengan menggabungkan streaming transaksi menggunakan aliran data perubahan dan konektivitas jaringan khusus melalui Cross-Cloud Interconnect, Anda dapat mencapai tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO) yang rendah di seluruh batas cloud.

Ringkasan arsitektur

Dalam topologi disaster recovery lintas cloud, Spanner di Google Cloud berfungsi sebagai database utama, dan Spanner Omni berfungsi sebagai deployment standby atau situs disaster recovery sekunder. Anda dapat mereplikasi perubahan transaksional secara terus-menerus menggunakan aliran data perubahan.

Tabel berikut membandingkan kemampuan database, peran, dan batasan operasional antara deployment Spanner utama dan deployment Spanner Omni sekunder di AWS.

Perbandingan deployment Spanner utama dan Spanner Omni sekunder

Kemampuan atau dimensi	Situs utama: Spanner di Google Cloud	Situs sekunder: Spanner Omni di AWS
Model deployment	Layanan terkelola sepenuhnya di Google Cloud.	Software yang dikelola sendiri di AWS, seperti Amazon Elastic Compute Cloud (Amazon EC2) atau Amazon Elastic Kubernetes Service (Amazon EKS).
SLA ketersediaan	Hingga 99,999% untuk konfigurasi multi-region dan 99,99% untuk konfigurasi regional. Untuk mengetahui informasi selengkapnya, lihat SLA Spanner.	Dikelola oleh pelanggan; bergantung pada infrastruktur dan topologi Anda.
Mode replikasi	Replikasi berbasis Paxos sinkron di seluruh zona dan region.	Pengambilan data perubahan (CDC) asinkron dan hampir real-time menggunakan aliran data perubahan.
Toleransi durasi kehilangan data (RPO)	Hampir nol dalam instance terkelola.	Subdetik hingga detik di seluruh batas cloud, bergantung pada throughput pipeline dan latensi jaringan.
Batas waktu pemulihan (RTO)	Failover otomatis dan langsung di seluruh replika.	Bergantung pada runbook pengalihan traffic dan DNS Anda.
Lapisan transit jaringan	Peering Jaringan Virtual Private Cloud (VPC) atau Cloud Interconnect.	Cross-Cloud Interconnect yang terhubung ke AWS Direct Connect.
Target penyimpanan cadangan	Cadangan Spanner yang dikelola Google, yang hanya dapat dipulihkan ke Spanner terkelola.	Cloud Storage atau Amazon Simple Storage Service (Amazon S3), yang hanya dapat dipulihkan ke Spanner Omni.

Sebelum memulai

Sebelum mengonfigurasi replikasi antara Spanner dan Spanner Omni, pastikan lingkungan Anda memenuhi persyaratan berikut:

• Sediakan kapasitas tujuan yang sesuai: Sesuaikan ukuran deployment Spanner Omni tujuan Anda agar sesuai dengan kapasitas I/O CPU, memori, dan penyimpanan instance Spanner utama Anda. Deployment yang terlalu kecil dapat menyebabkan jeda replikasi dan mencegah cluster standby menangani workload selama failover. Untuk mengetahui informasi selengkapnya, lihat Persyaratan sistem.
• Menyinkronkan skema database dan data dasar pengukuran: Buat database dan tabel tujuan di Spanner Omni menggunakan dialek SQL, GoogleSQL atau PostgreSQL, dan definisi skema yang sama dengan database Spanner sumber Anda. Karena Anda tidak dapat memulihkan cadangan Spanner terkelola ke Spanner Omni, ekspor data yang ada dari Spanner ke file Avro di Cloud Storage dan impor ke Spanner Omni. Untuk mengetahui informasi selengkapnya, lihat Skema dan model data, Mengembangkan dengan Spanner Omni, Mengekspor database dari Spanner ke Avro, dan Mengimpor dan mengekspor data.
• Membuat konektivitas jaringan pribadi: Konfigurasikan pemilihan rute jaringan pribadi antara jaringan VPC Google Cloud Anda dan lingkungan eksternal Anda sehingga worker replikasi Anda dapat terhubung ke Spanner dan endpoint gRPC Spanner Omni. Untuk mengetahui informasi selengkapnya, lihat Memilih produk Network Connectivity dan Mempercepat replikasi dengan Cross-Cloud Interconnect.

Mereplikasi data secara terus-menerus menggunakan aliran data perubahan

Untuk aplikasi yang memerlukan kelangsungan bisnis lintas cloud, aliran data perubahan Spanner menghasilkan perubahan data transaksional (operasi INSERT, UPDATE, dan DELETE) dalam urutan stempel waktu commit. Pipeline replikasi berkelanjutan membaca data perubahan dari Spanner di Google Cloud dan menulisnya ke deployment Spanner Omni Anda.

Menggunakan aliran data perubahan untuk replikasi lintas cloud memberikan manfaat berikut:

• Standby aktif-pasif: Mempertahankan replika warm di Spanner Omni yang siap menyajikan workload saat Anda memulai failover.
• Replikasi selektif: Anda dapat mengonfigurasi aliran data perubahan untuk memantau seluruh database atau membatasinya ke tabel dan kolom tertentu untuk mengurangi biaya transfer lintas cloud.
• Paritas dialek: Karena Spanner Omni mendukung dialek dan semantik skema GoogleSQL dan PostgreSQL yang sama dengan Spanner, kueri aplikasi Anda akan berjalan tanpa modifikasi setelah cutover.

Langkah 1: Buat aliran data perubahan di database sumber

Buat aliran data perubahan di database Spanner sumber untuk melacak perubahan pada tabel target. Misalnya, jalankan pernyataan DDL ini di database Spanner Anda:

CREATE CHANGE STREAM CHANGE_STREAM_NAME
FOR TABLE_NAMES
OPTIONS (
  retention_period = '7d',
  value_capture_type = 'NEW_ROW_AND_OLD_VALUES'
);

Ganti kode berikut:

• CHANGE_STREAM_NAME: nama aliran perubahan Anda, misalnya, CsToOmniDrStream.
• TABLE_NAMES: daftar tabel yang dipisahkan koma untuk dilacak, misalnya, Customers, Orders, AccountBalances, atau ALL untuk melacak semua tabel dalam database.

Menetapkan retention_period ke '7d' akan mempertahankan data aliran perubahan hingga tujuh hari, yang membantu mencegah kehilangan data jika pipeline replikasi Anda mengalami pemeliharaan yang lama atau gangguan konektivitas. Untuk mengetahui informasi selengkapnya, lihat Membuat dan mengelola aliran perubahan.

Langkah 2: Deploy pipeline change data capture

Untuk menstreaming perubahan dari Spanner ke Spanner Omni, deploy pipeline change data capture (CDC) berkelanjutan menggunakan Dataflow dengan Apache Beam, atau jalankan pod worker kustom di Google Kubernetes Engine (GKE) atau Amazon EKS.

Pipeline replikasi produksi melakukan tugas-tugas berikut:

• Membaca partisi: Menggunakan Spanner Change Streams API atau konektor Apache Beam SpannerIO untuk membaca data perubahan di seluruh partisi aliran data perubahan dinamis. Untuk mengetahui informasi selengkapnya, lihat Partisi, kumpulan data, dan kueri aliran perubahan dan Memproses kumpulan data aliran perubahan menggunakan Dataflow.
• Membuat buffer dan mengurutkan mutasi: Mengurutkan dan mengelompokkan transaksi sesuai dengan stempel waktu commit (commit_timestamp) per rentang kunci atau tabel untuk mempertahankan konsistensi transaksional dan memaksimalkan throughput tulis.
• Menulis ke Spanner Omni: Terhubung melalui gRPC ke endpoint pribadi deployment Spanner Omni dan menerapkan mutasi dalam batch. Jika Anda menggunakan konektor SpannerIO Apache Beam dengan enkripsi, gunakan Apache Beam 2.69.0 atau yang lebih baru untuk TLS, atau 2.75.0 atau yang lebih baru untuk mutual TLS (mTLS). Untuk mengetahui informasi selengkapnya, lihat Menggunakan Apache Beam dan SpannerIO untuk terhubung ke Spanner Omni dan Autentikasi dan otorisasi.
• Memantau jeda replikasi: Melacak perbedaan antara waktu saat ini dan commit_timestamp data perubahan yang diproses sehingga Anda dapat memberikan pemberitahuan tentang penundaan replikasi.

Jika Anda menggunakan Dataflow atau Apache Beam, Anda harus menggunakan Apache Beam Java SDK karena Python SDK tidak menyertakan konektor aliran data perubahan. Untuk pod worker kustom, contoh Python ini menunjukkan cara mengonfigurasi klien Spanner Omni menggunakan enkripsi TLS dan menerapkan batch mutasi aliran data perubahan ke database tujuan. Untuk workload bervolume tinggi, antrekan dan kelompokkan mutasi yang tidak tumpang-tindih dalam urutan stempel waktu commit di seluruh proses worker paralel, bukan meng-commit satu data sekaligus:

from google.cloud import spanner
from google.cloud.spanner_v1 import InstanceType

# Configure the Spanner Omni target client
omni_client = spanner.Client(
    client_options={"api_endpoint": "ENDPOINT"},
    instance_type=InstanceType.OMNI,
    ca_certificate="PATH_TO_CA_CERT",
)
# Spanner Omni uses "default" as the instance ID
omni_instance = omni_client.instance("default")
omni_database = omni_instance.database("DATABASE_ID")


def apply_cdc_mutations_to_omni(records):
    """Applies a batch of ordered change stream records to Spanner Omni."""

    def write_batch(transaction):
        for record in records:
            table_name = record["tableName"]
            mutation_type = record["mutationType"]  # INSERT, UPDATE, DELETE
            row_data = record.get("columnValues", {})

            if mutation_type in ("INSERT", "UPDATE"):
                transaction.insert_or_update(
                    table=table_name,
                    columns=list(row_data.keys()),
                    values=[list(row_data.values())],
                )
            elif mutation_type == "DELETE":
                key_columns = record["keyValues"]
                transaction.delete(
                    table=table_name,
                    keyset=spanner.KeySet(keys=[list(key_columns.values())]),
                )

    omni_database.run_in_transaction(write_batch)

Ganti kode berikut:

• ENDPOINT: endpoint dan port gRPC pribadi instance Spanner Omni Anda, misalnya, spanner-omni.internal.example.com:15000.
• PATH_TO_CA_CERT: jalur file ke sertifikat certificate authority (CA) untuk deployment Spanner Omni Anda.
• DATABASE_ID: ID database Spanner Omni tujuan Anda.

Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi koneksi klien, lihat Menggunakan library klien Python untuk terhubung ke Spanner Omni.

Mempercepat replikasi dengan Cross-Cloud Interconnect

Mengandalkan internet publik atau tunnel VPN IPsec antara Google Cloud dan penyedia cloud lain dapat menyebabkan jitter jaringan, paket hilang, batas bandwidth, dan jeda replikasi variabel. Untuk workload produksi yang memerlukan RPO rendah, gunakan Cross-Cloud Interconnect untuk membuat konektivitas fisik khusus berkecepatan tinggi antara Google Cloud dan penyedia cloud eksternal Anda.

Tabel berikut membandingkan karakteristik jaringan antara koneksi internet publik atau koneksi VPN IPsec dan Cross-Cloud Interconnect.

Perbandingan opsi transit jaringan untuk replikasi lintas cloud

Metrik jaringan	Internet publik atau VPN IPsec	Cross-Cloud Interconnect
Kapasitas link	1,25 Gbps hingga 3 Gbps per tunnel.	Bandwidth optik khusus 10 Gbps atau 100 Gbps per link.
Latensi dan jitter jaringan	Jalur transit internet yang bervariasi dan tidak dapat diprediksi.	Pemilihan rute pribadi yang deterministik dan berlatensi rendah.
SLA ketersediaan	Tidak ada SLA performa menyeluruh.	SLA ketersediaan 99,9% atau 99,99% jika dikonfigurasi dengan koneksi redundan.
Enkripsi transfer data	Overhead IPsec dan batas kriptografi software.	Enkripsi MACsec kecepatan jalur untuk Cloud Interconnect (IEEE 802.1AE). Untuk mengetahui informasi selengkapnya, lihat Ringkasan MACsec untuk Cloud Interconnect.
Biaya transfer data	Tarif egress internet standar.	Pengurangan tarif transfer data Cloud Interconnect.

Alur kerja konfigurasi jaringan tingkat tinggi

Untuk menyiapkan Cross-Cloud Interconnect untuk pipeline replikasi Anda, selesaikan langkah-langkah tingkat tinggi berikut:

1. Memesan koneksi Cross-Cloud Interconnect: Pesan port Cross-Cloud Interconnect utama dan redundan di fasilitas colocation yang dipasangkan dengan lokasi penyedia cloud jarak jauh Anda. Misalnya, jalankan perintah gcloud compute interconnects create:

   gcloud compute interconnects create CONNECTION_NAME \
     --interconnect-type=DEDICATED \
     --link-type=CAPACITY \
     --requested-link-count=LINK_COUNT \
     --location=GOOGLE_CLOUD_LOCATION \
     --remote-location=REMOTE_LOCATION \
     --noc-contact-email=CONTACT_EMAIL
   

   Ganti kode berikut:

   • CONNECTION_NAME: nama koneksi Cross-Cloud Interconnect Anda.
   • CAPACITY: kapasitas link, seperti LINK_TYPE_ETHERNET_10G_LR atau LINK_TYPE_ETHERNET_100G_LR.
   • LINK_COUNT: jumlah link yang akan diminta.
   • GOOGLE_CLOUD_LOCATION: domain ketersediaan edge untuk lokasi Google Cloud , misalnya, iad-zone1-1.
   • REMOTE_LOCATION: lokasi penyedia cloud jarak jauh, misalnya, aws-us-east-1.
   • CONTACT_EMAIL: alamat email operasi jaringan Anda.

   Untuk mengetahui informasi selengkapnya, lihat Memilih lokasi dan Memesan port AWS.

2. Konfigurasi Cloud Router dan peering BGP: Buat lampiran VLAN dan konfigurasi sesi Border Gateway Protocol (BGP) antara Cloud Router di jaringan VPC Google Cloud Anda dan gateway pribadi virtual atau gateway koneksi langsung di lingkungan cloud jarak jauh Anda. Untuk mengetahui informasi selengkapnya, lihat Ringkasan Cloud Router, Mengonfigurasi resource Google Cloud , dan Mengonfigurasi resource AWS Anda.

3. Validasi penerapan rute: Pastikan tabel rute di kedua jaringan menerapkan blok CIDR yang tidak tumpang tindih sehingga worker pipeline CDC dan node Spanner Omni Anda berkomunikasi secara eksklusif melalui alamat IP pribadi. Untuk mengetahui informasi selengkapnya, lihat Memverifikasi koneksi Anda.

Untuk petunjuk penyiapan lengkap, lihat Menghubungkan ke Amazon Web Services dalam dokumentasi Cross-Cloud Interconnect.

Checklist failover dan runbook

Saat Anda menjalankan pengalihan atau failover dari Spanner di Google Cloud ke Spanner Omni, ikuti langkah-langkah operasional berikut:

1. Mengosongkan perubahan yang sedang berlangsung: Hentikan penulisan aplikasi ke database Spanner utama (jika dapat dijangkau) dan pastikan pipeline replikasi CDC Anda telah memproses semua data aliran perubahan hingga stempel waktu commit terbaru.
2. Mengalihkan koneksi aplikasi: Perbarui profil konfigurasi aplikasi, string koneksi, atau secret Kubernetes Anda untuk terhubung ke endpoint Spanner Omni, bukan Spanner diGoogle Cloud.
3. Perbarui DNS dan perutean traffic: Alihkan data DNS atau target load balancer global Anda untuk merutekan traffic klien ke tingkat aplikasi dan load balancer yang berada di depan deployment Spanner Omni Anda.
4. Sinkronkan ulang setelah pemulihan: Setelah Anda memulihkan lingkunganGoogle Cloud utama, balikkan arah replikasi sebelum Anda melakukan failback. Anda menangkap perubahan dari Spanner Omni dengan menggunakan aliran perubahan dan konektor Debezium untuk memublikasikan perubahan ke Apache Kafka, dengan konsumen yang menerapkannya ke Spanner. Atau, Anda dapat mengekspor database Spanner Omni ke file Avro di Cloud Storage dan mengimpornya ke Spanner. Untuk mengetahui informasi selengkapnya, lihat Mengimpor dan mengekspor data dan Mengimpor file Avro Spanner.

Langkah berikutnya

• Membuat dan mengelola cadangan Spanner Omni
• Memulihkan cadangan Spanner Omni
• Mengimpor dan mengekspor data
• Menggunakan Apache Beam dan SpannerIO untuk terhubung ke Spanner Omni
• Menggunakan Debezium untuk terhubung ke Spanner Omni