Jeda replikasi

Halaman ini menjelaskan cara memecahkan masalah dan memperbaiki jeda replikasi untuk replika baca Cloud SQL.

Ringkasan

Replika baca Cloud SQL menggunakan replikasi berbasis baris MySQL menggunakan ID transaksi global (GTID). Perubahan ditulis ke log biner instance utama dan dikirim ke replika, tempat perubahan tersebut diterima, lalu diterapkan ke database.

Jeda replikasi dapat terjadi dalam beberapa skenario, seperti:

Instance utama tidak dapat mengirimkan perubahan dengan cukup cepat ke replika.
Replika tidak dapat menerima perubahan dengan cukup cepat.
Replika tidak dapat menerapkan perubahan dengan cukup cepat.

Menggunakannetwork_lag metrik untuk memantau dua skenario pertama saat instance utama tidak dapat mengirim perubahan dengan cukup cepat atau replika tidak dapat menerima perubahan dengan cukup cepat.

Jeda total diamati dengan metrik replica_lag. Perbedaan antara replica_lag dan network_lag dapat menunjukkan alasan ketiga ketika replika tidak dapat menerapkan perubahan replikasi dengan cukup cepat. Metrik ini dijelaskan di bagian Memantau jeda replikasi di bawah.

Konfigurasi replika yang lebih cepat

Kami memiliki dua cara untuk membuat replika MySQL menerapkan perubahan lebih cepat. Pengguna dapat mengonfigurasi replika mereka dengan opsi berikut:

Replikasi paralel
Pembersihan berperforma tinggi

Replikasi paralel

Replikasi paralel dapat membantu jeda replikasi dengan mengonfigurasi replika agar menggunakan beberapa thread yang bertindak secara paralel untuk menerapkan perubahan pada replika. Untuk mengetahui informasi tentang cara menggunakan replikasi paralel, lihat Mengonfigurasi replikasi paralel.

Pembersihan berperforma tinggi

Secara default, Cloud SQL untuk MySQL mengosongkan log pengulangan ke disk setelah setiap transaksi. Pembersihan berperforma tinggi mengurangi frekuensi pembersihan log pengulangan ke disk menjadi satu kali per detik, sehingga meningkatkan performa penulisan.

Tetapkan flag innodb_flush_log_at_trx_commit pada replika baca ke 2. Anda juga harus menetapkan flag sync_binlog ke nilai yang lebih tinggi agar flag innodb_flush_log_at_trx_commit berlaku.

Lihat Tips untuk menggunakan flag untuk mengetahui informasi selengkapnya tentang flag ini.

Jika flag innodb_flush_log_at_trx_commit ditetapkan pada replika baca dan Cloud SQL mendeteksi bahwa mungkin terjadi error, Cloud SQL akan otomatis membuat ulang replika.

Mengoptimalkan kueri dan skema

Bagian ini menyarankan beberapa pengoptimalan skema dan kueri umum yang dapat Anda lakukan untuk meningkatkan performa replikasi.

Tingkat isolasi kueri dalam replika baca

Tingkat isolasi transaksi REPEATABLE READ dan SERIALIZABLE memperoleh kunci yang mungkin memblokir perubahan replikasi. Sebaiknya kurangi tingkat isolasi untuk kueri Anda di replika. Tingkat isolasi transaksi READ COMMITTED mungkin akan berperforma lebih baik.

Catatan: Tingkat isolasi transaksi default MySQL adalah REPEATABLE READkarena alasan historis.

Transaksi yang berjalan lama di database utama

Jika sejumlah besar baris diperbarui dalam satu transaksi, hal ini dapat menyebabkan lonjakan tiba-tiba dalam jumlah perubahan yang perlu diterapkan ke instance utama, lalu dikirim ke replika. Hal ini berlaku untuk pembaruan atau penghapusan pernyataan tunggal yang memengaruhi banyak baris sekaligus. Perubahan dikirim ke replika setelah di-commit. Menerapkan lonjakan perubahan tiba-tiba pada replika dapat meningkatkan kemungkinan pertentangan kunci dalam replika jika beban kueri pada replika juga tinggi, yang menyebabkan jeda replikasi.

Pertimbangkan untuk membagi transaksi besar menjadi beberapa transaksi yang lebih kecil.

Kunci utama tidak ada

Replika baca Cloud SQL menggunakan replikasi berbasis baris, yang berperforma buruk jika tabel MySQL yang direplikasi tidak memiliki kunci utama. Kami merekomendasikan agar semua tabel yang direplikasi memiliki kunci utama.

Untuk MySQL 8 atau yang lebih baru, sebaiknya tetapkan flag sql_require_primary_key ke ON untuk mewajibkan tabel dalam database Anda agar memiliki kunci utama.

Penguncian eksklusif karena DDL

Perintah bahasa definisi data (DDL), seperti ALTER TABLE dan CREATE INDEX, dapat menyebabkan jeda replikasi dalam replika karena kunci eksklusif. Untuk menghindari pertentangan kunci, pertimbangkan untuk menjadwalkan eksekusi DDL saat beban kueri lebih rendah pada replika.

Replika kelebihan muatan

Jika replika baca menerima terlalu banyak kueri, replikasi dapat diblokir. Pertimbangkan untuk membagi pembacaan di antara beberapa replika untuk mengurangi beban pada setiap replika.

Untuk menghindari lonjakan kueri, pertimbangkan untuk melakukan throttling replika baca kueri baca di logika aplikasi Anda atau di lapisan proxy jika Anda menggunakannya.

Jika ada lonjakan aktivitas pada instance utama, pertimbangkan untuk menyebarkan update.

Database primer monolitik

Sebaiknya lakukan sharding database utama secara vertikal (atau horizontal) untuk mencegah satu atau beberapa tabel yang terjeda menahan semua tabel lainnya.

Memantau jeda replikasi

Anda dapat menggunakan metrik replica_lag dan network_lag untuk memantau jeda replikasi dan mengidentifikasi apakah penyebab jeda berada pada database utama, jaringan, atau replika.

Metrik	Deskripsi
Jeda replikasi (`cloudsql.googleapis.com/database/replication/replica_lag`)	Jumlah detik saat status replika terjeda dibandingkan status instance utama. Ini adalah perbedaan antara waktu saat ini dan stempel waktu asli saat database utama meng-commit transaksi yang saat ini diterapkan pada replika. Secara khusus, penulisan mungkin dianggap tertinggal meskipun telah diterima oleh replika, jika replika belum menerapkan penulisan ke database. Metrik ini melaporkan nilai `Seconds_Behind_Master` saat `SHOW SLAVE STATUS` dijalankan di replika. Untuk mengetahui informasi selengkapnya, lihat Memeriksa Status Replikasi di Manual Referensi MySQL.
Nomor error thread I/O terakhir (`cloudsql.googleapis.com/database/mysql/replication/last_io_errno`)	Menunjukkan error terakhir yang menyebabkan thread I/O gagal. Jika nilainya bukan nol, ini berarti replikasi rusak. Hal ini jarang terjadi, tetapi bisa saja terjadi. Periksa dokumentasi MySQL untuk memahami apa yang ditunjukkan oleh kode error. Misalnya, file binlog dalam instance utama mungkin telah dihapus sebelum replika menerimanya. Cloud SQL biasanya akan otomatis membuat ulang replika jika replikasi rusak. Metrik `last_io_errno` ini mungkin memberi tahu Anda alasannya.
Nomor error thread SQL terakhir (`cloudsql.googleapis.com/database/mysql/replication/last_sql_errno`)	Menunjukkan error terakhir yang menyebabkan thread SQL gagal. Jika nilainya bukan nol, ini berarti replikasi rusak. Hal ini jarang terjadi, tetapi bisa saja terjadi. Periksa dokumentasi MySQL untuk memahami apa yang ditunjukkan oleh kode error. Cloud SQL biasanya akan otomatis membuat ulang replika jika replikasi rusak. Metrik `last_sql_errno` ini dapat memberi tahu Anda alasannya.
Latensi jaringan (`cloudsql.googleapis.com/database/replication/network_lag`)	Durasi waktu, dalam detik yang diperlukan dari penulisan binlog di database utama untuk mencapai thread IO di replika. Jika `network_lag` nol, atau dapat diabaikan, tetapi `replica_lag` tinggi, ini menunjukkan bahwa thread SQL tidak dapat menerapkan perubahan replikasi dengan cukup cepat.

Memverifikasi replikasi

Untuk memverifikasi bahwa replikasi berfungsi, jalankan pernyataan berikut terhadap replika tersebut:

mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
               Slave_IO_State: Queueing master event to the relay log
                  Master_Host: xx.xxx.xxx.xxx
                  Master_User: cloudsqlreplica
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.199927
          Read_Master_Log_Pos: 83711956
               Relay_Log_File: relay-log.000025
                Relay_Log_Pos: 24214376
        Relay_Master_Log_File: mysql-bin.199898
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 24214163
              Relay_Log_Space: 3128686571
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: Yes
           Master_SSL_CA_File: master_server_ca.pem
           Master_SSL_CA_Path: /mysql/datadir
              Master_SSL_Cert: replica_cert.pem
            Master_SSL_Cipher:
               Master_SSL_Key: replica_pkey.pem
        Seconds_Behind_Master: 2627
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 321071839
                  Master_UUID: 437d04e9-8456-11e8-b13d-42010a80027b
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: System lock
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:52111095710-52120776390
            Executed_Gtid_Set: 437d04e9-8456-11e8-b13d-42010a80027b:1-52113039508
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

Jika replikasi terjadi, Slave_IO_State (kolom pertama) akan menampilkan Waiting for master to send event atau pesan serupa. Selain itu, kolom Last_IO_Error kosong.

Jika replikasi tidak terjadi, kolom Slave_IO_State akan menampilkan status Connecting to master dan kolom Last_IO_Error akan menampilkan status error connecting to master cloudsqlreplica@x.x.x.x:3306.

Menurut dokumentasi MySQL, beberapa kolom menarik lainnya yang terkait dengan jeda replikasi adalah:

Kolom	Deskripsi
`Master_Log_File`	Nama file log biner sumber yang saat ini dibaca oleh thread I/O
`Read_Master_Log_Pos`	Posisi dalam file log biner sumber saat ini yang telah dibaca oleh thread I/O.
`Relay_Log_File`	Nama file log relai yang saat ini dibaca dan dijalankan oleh thread SQL.
`Relay_Log_Pos`	Posisi dalam file log relai saat ini yang telah dibaca dan dijalankan oleh thread SQL.
`Relay_Master_Log_File`	Nama file log biner source yang berisi peristiwa terbaru yang dijalankan oleh thread SQL.

Pada contoh di atas, Relay_Master_Log_File memiliki nilai mysql-bin.199898. Master_Log_Filememiliki nilaimysql-bin.199927 Akhiran numerik 199898 kurang dari 199927. Artinya, meskipun replika telah menerima file log mysql-bin.199927 yang lebih baru, replika tersebut masih menerapkan mysql-bin.199898 lama.

Dalam hal ini, thread SQL tertinggal dalam replika.

Anda juga dapat terhubung ke database utama dan menjalankan:

SHOW MASTER STATUS;

Perintah ini menunjukkan file binlog mana yang sedang ditulis di database utama.

Jika file log biner database utama lebih baru daripada Master_Log_File yang berada dalam replika, artinya thread I/O mengalami ketertinggalan. Replika masih membaca file log biner lama dari database utama.

Saat thread I/O tertinggal, metrik network_lag juga tinggi. Jika thread SQL tertinggal, tetapi thread I/O tidak, berarti metrik network_lag tidak terlalu tinggi, tetapi replica_lag tinggi.

Perintah sebelumnya memungkinkan Anda mengamati detail jeda saat jeda terjadi, tetapi metrik network_lag dan replica_lag memberi Anda cara untuk melihat kemunculan jeda di masa lalu.