FAQ untuk Mesin PolarDB - PolarDB

Topik ini menjawab pertanyaan umum tentang PolarDB for MySQL.

Pertanyaan dasar

Q: Apa itu PolarDB?
A: PolarDB adalah layanan database relasional berbasis cloud yang tersedia di lebih dari sepuluh wilayah Alibaba Cloud secara global dan menyediakan layanan database online siap pakai. PolarDB mendukung tiga mesin yang sepenuhnya kompatibel dengan MySQL, sepenuhnya kompatibel dengan PostgreSQL, serta sangat kompatibel dengan sintaks Oracle, dengan kapasitas penyimpanan maksimum hingga 200 TB. Untuk informasi lebih lanjut, lihat Apa itu PolarDB for MySQL Enterprise Edition?.
Q: Mengapa database cloud-native PolarDB lebih unggul dibandingkan database tradisional?
A: Dibandingkan dengan database tradisional, PolarDB mendukung penyimpanan data skala besar hingga ratusan TB, menawarkan ketersediaan tinggi, keandalan data, skalabilitas elastis cepat, serta backup tanpa kunci. Untuk informasi lebih lanjut, lihat Manfaat.
Q: Kapan PolarDB dirilis? Kapan layanan ini tersedia secara komersial?
A: PolarDB memasuki pratinjau publik pada September 2017 dan tersedia secara komersial pada Maret 2018.
Q: Apa itu kluster dan node?
A: Edisi kluster PolarDBcluster edition menggunakan arsitektur kluster multi-node. Setiap kluster memiliki satu node utama dan beberapa node read-only. Satu kluster PolarDB mendukung penerapan cross-zone tetapi tidak mendukung penerapan cross-region. Kluster dikelola dan ditagih sebagai satu unit. Untuk informasi lebih lanjut, lihat Glosarium.
Q: Bahasa pemrograman apa saja yang didukung?
A: PolarDB mendukung Java, Python, PHP, Golang, C, C++, .NET, dan Node.js. Bahasa pemrograman apa pun yang mendukung MySQL native dapat langsung menggunakan PolarDB for MySQL. Untuk informasi lebih lanjut, lihat situs web MySQL.
Q: Mesin penyimpanan apa saja yang didukung sistem?
A: PolarDB mendukung dua seri produk. Mesin penyimpanan yang didukung berbeda-beda tergantung serinya:
Semua tabel dalam PolarDB for MySQLcluster edition menggunakan mesin penyimpanan InnoDB. Saat Anda membuat tabel, PolarDB for MySQL secara otomatis mengonversi mesin non-InnoDB seperti MyISAM, Memory, dan CSV ke InnoDB. Oleh karena itu, meskipun tabel sumber Anda menggunakan mesin lain, migrasi ke PolarDB for MySQL tetap dapat berhasil.
Q: Apakah PolarDB merupakan database terdistribusi?
A: Ya. PolarDB adalah kluster penyimpanan terdistribusi berbasis protokol konsistensi Parallel Raft. Mesin komputasinya terdiri dari satu hingga enam belas node komputasi yang tersebar di server berbeda. Kapasitas penyimpanan maksimumnya mencapai 200 TB, dan konfigurasi maksimumnya mendukung 88 vCPU dan memori 710 GB. Anda dapat melakukan penskalaan sumber daya penyimpanan dan komputasi secara online dan dinamis tanpa mengganggu operasi bisnis.
Q: Setelah saya membeli PolarDB, apakah saya perlu membeli middleware database PolarDB-X jika ingin melakukan sharding database dan tabel?
A: Ya.
Q: Apakah PolarDB mendukung partisi tabel?
A: Ya.
Q: Dapatkah saya mengubah wilayah setelah membeli kluster PolarDB?
A: Tidak. Anda tidak dapat mengubah wilayah setelah membeli kluster.
Q: Apakah PolarDB mencakup partisi bawaan?
A: PolarDB melakukan partisi data di lapisan penyimpanan. Hal ini transparan bagi pengguna dan tidak memerlukan tindakan apa pun.
Q: Bagaimana seri single-node menjamin ketersediaan layanan dan keandalan data?
A: Seri single-node menyediakan produk database khusus berbasis satu node komputasi. Meskipun hanya menggunakan satu node, seri single-node menjamin ketersediaan layanan tinggi dan keandalan data tinggi menggunakan teknologi seperti penjadwalan komputasi sub-detik dan penyimpanan multi-replika terdistribusi.
Q: Bagaimana cara membeli kluster PolarDB dalam mode single-node?
A: Seri produk single-node saat ini tidak tersedia lagi, tetapi Anda dapat membeli kluster PolarDB single-node dengan mengatur jumlah node read-only menjadi 0 saat pembelian kluster.

Kompatibilitas

Q: Apakah PolarDB for MySQL kompatibel dengan MySQL komunitas?
A: PolarDB for MySQL 100% kompatibel dengan MySQL komunitas.
Q: Tingkat isolasi transaksi apa saja yang didukung oleh PolarDB for MySQL?
A: PolarDB for MySQL mendukung READ_UNCOMMITTED, READ_COMMITTED (default), dan REPEATABLE_READ. Layanan ini tidak mendukung SERIALIZABLE.
Q: Apakah SHOW PROCESSLIST berbeda dari MySQL komunitas?
A: Jika Anda melakukan kueri menggunakan titik akhir utama, tidak ada perbedaan. Jika Anda melakukan kueri menggunakan titik akhir kluster, hasilnya mungkin sedikit berbeda. Beberapa baris dengan ID thread yang sama akan muncul, masing-masing sesuai dengan node dalam kluster PolarDB for MySQL.
Q: Apakah mekanisme metadata lock (MDL) di PolarDB for MySQL berbeda dari MySQL komunitas?
A: Mekanisme MDL di PolarDB for MySQL konsisten dengan MySQL komunitas. Namun, karena PolarDB for MySQL menggunakan penyimpanan bersama, node read-only mungkin mengakses data antara selama operasi DDL di node utama, sehingga menyebabkan inkonsistensi data. Untuk mencegah hal ini, PolarDB for MySQL menyinkronkan kunci MDL eksklusif yang terlibat dalam operasi DDL ke node read-only melalui redo log. Hal ini memblokir thread pengguna lain di node read-only dari mengakses data tabel selama operasi DDL. Dalam beberapa kasus, hal ini dapat memblokir operasi DDL. Jalankan perintah show processlist untuk memeriksa status eksekusi DDL. Jika status menunjukkan Wait for syncing with replicas, masalah ini telah terjadi. Untuk langkah penyelesaian, lihat Lihat status eksekusi DDL dan status kunci MDL.
Q: Apakah format Binlog berbeda dari MySQL native?
A: Tidak.
Q: Apakah PolarDB mendukung performance_schema dan skema sys?
A: Ya.
Q: Apakah pengumpulan statistik tabel di PolarDB for MySQL berbeda dari MySQL komunitas?
A: Statistik tabel di node utama PolarDB for MySQL sesuai dengan MySQL komunitas. Untuk memastikan rencana eksekusi yang konsisten antara node utama dan node read-only, node utama menyinkronkan statistik yang diperbarui ke node read-only. Node read-only juga dapat memuat statistik terbaru dari disk menggunakan perintah ANALYZE TABLE.
Q: Apakah PolarDB mendukung transaksi XA, dan apakah ada perbedaan dibandingkan dengan MySQL resmi?
A: Ya. Tidak ada perbedaan.
Q: Apakah PolarDB mendukung indeks teks penuh?
A: Ya.
Catatan
Saat Anda menggunakan indeks teks penuh, node read-only mungkin mengalami latensi cache indeks yang ringan. Kami merekomendasikan menggunakan titik akhir utama untuk semua operasi baca/tulis indeks teks penuh guna memastikan Anda membaca data terbaru.
Q: Apakah PolarDB mendukung Percona Toolkit?
A: Ya. Namun, kami merekomendasikan penggunaan DDL online.
Q: Apakah PolarDB mendukung gh-ost?
A: Ya. Namun, kami merekomendasikan penggunaan DDL online.

Penagihan

Q: Apa saja yang termasuk dalam penagihan PolarDB?
A: Penagihan mencakup storage space, node komputasi, backup (dengan kuota gratis yang disertakan), dan SQL Explorer (opsional). Untuk informasi lebih lanjut, lihat Ikhtisar item penagihan.
Q: Apa saja yang termasuk dalam storage space yang ditagih?
A: Storage space yang ditagih mencakup file tabel database, file indeks, file undo log, file redo log, file Binlog, file slow log, dan sejumlah kecil file sistem. Untuk informasi lebih lanjut, lihat Ikhtisar.
Q: Berapa biaya untuk menambahkan node read-only?
A: Biaya node read-only sama dengan node utama. Untuk detailnya, lihat Detail harga node komputasi.
Q: Apakah menambahkan node read-only menggandakan kapasitas penyimpanan?
A: PolarDB menggunakan arsitektur komputasi-penyimpanan terpisah. Node read-only hanya menambahkan sumber daya komputasi. Kapasitas penyimpanan tidak bertambah.
Penyimpanan menggunakan model serverless. Anda tidak memilih ukuran penyimpanan saat pembelian. Penyimpanan diskalakan secara online dan otomatis seiring pertumbuhan data Anda. Anda hanya membayar jumlah data aktual yang disimpan. Setiap spesifikasi kluster memiliki kapasitas penyimpanan maksimum. Untuk meningkatkan batas penyimpanan, tingkatkan spesifikasi kluster.
Q: Bagaimana cara menghentikan biaya untuk kluster pay-as-you-go?
A: Jika Anda tidak lagi membutuhkan kluster tersebut, lepaskan kluster. Setelah dilepas, tidak ada biaya tambahan yang dikenakan.
Q: Dapatkah saya mengubah konfigurasi kluster selama peningkatan sementara?
A: Selama peningkatan sementara (saat status kluster Berjalan), Anda dapat meningkatkan kluster secara manual. Namun, downgrade manual, skalabilitas otomatis, dan penambahan atau penghapusan node tidak didukung.
Q: Berapa bandwidth Internet untuk PolarDB? Apakah dikenakan biaya?
A: PolarDB tidak memiliki batas bandwidth Internet. Bandwidth bergantung pada layanan SLB yang Anda gunakan. PolarDB tidak membebankan biaya untuk koneksi jaringan publik.
Q: Mengapa saya dikenakan biaya harian untuk kluster subscription?
A: Item penagihan PolarDB mencakup node komputasi (node utama dan node read-only), storage space, data backup (dikenakan biaya hanya jika melebihi kuota gratis), SQL Explorer (opsional), dan Global Database Network (GDN) (opsional). Untuk detailnya, lihat Ikhtisar item penagihan. Subscription berarti Anda membayar di muka untuk biaya node komputasi saat membuat kluster. Biaya storage space, data backup, dan SQL Explorer tidak termasuk. Seiring penggunaan storage space oleh kluster Anda, biaya per jam dikenakan ke akun Anda. Oleh karena itu, meskipun menggunakan subscription, Anda mungkin menerima tagihan pay-as-you-go.
Q: Apakah ada biaya tambahan untuk migrasi dari RDS ke PolarDB dengan migrasi satu klik?
A: Migrasi satu klik gratis. Anda hanya dikenakan biaya untuk instans RDS dan kluster PolarDB.
Q: Mengapa biaya penyimpanan masih dikenakan untuk data tabel PolarDB setelah Anda menggunakan perintah DELETE?
A: delete menandai baris untuk dihapus tetapi tidak melepaskan ruang tabel.

Akses kluster (pemisahan baca/tulis)

Q: Bagaimana cara menerapkan pemisahan baca/tulis untuk PolarDB?
A: Gunakan titik akhir kluster di aplikasi Anda. Pemisahan baca/tulis bekerja secara otomatis berdasarkan mode baca/tulis yang dikonfigurasi. Untuk informasi lebih lanjut, lihat Konfigurasikan proksi database.
Q: Berapa banyak node read-only yang dapat didukung oleh kluster PolarDB?
A: PolarDB menggunakan arsitektur kluster terdistribusi. Setiap kluster memiliki satu node utama dan hingga 15 node read-only (minimal satu untuk ketersediaan tinggi).
Q: Mengapa beban tidak merata di antara node read-only?
A: Ketidakseimbangan beban dapat terjadi karena beberapa node read-only memiliki koneksi lebih sedikit atau karena titik akhir kluster kustom mengecualikan node read-only tertentu.
Q: Mengapa beban di node utama tinggi atau rendah?
A: Beban tinggi di node utama (database utama) dapat disebabkan oleh koneksi langsung ke titik akhir utama, permintaan baca yang diarahkan ke database utama, trafik transaksi yang tinggi, latensi replikasi tinggi yang menyebabkan kueri diarahkan ke node utama, atau kegagalan node read-only yang mengarahkan permintaan baca ke node utama.
Beban rendah di node utama dapat terjadi jika database utama dikonfigurasi untuk menolak permintaan baca.
Q: Bagaimana cara mengurangi beban di node utama?
A: Gunakan satu atau beberapa metode berikut:
- Hubungkan ke kluster PolarDB menggunakan titik akhir kluster. Untuk informasi lebih lanjut, lihat Konfigurasikan proksi database.
- Jika volume transaksi tinggi menyebabkan beban berat di node utama, aktifkan pemisahan transaksi di konsol. Hal ini mengarahkan beberapa kueri dalam transaksi ke node read-only. Untuk informasi lebih lanjut, lihat Pemisahan transaksi.
- Jika latensi replikasi menyebabkan kueri diarahkan ke node utama, turunkan tingkat konsistensi (misalnya, gunakan konsistensi akhir). Untuk informasi lebih lanjut, lihat Tingkat konsistensi.
- Menerima permintaan baca juga dapat memberikan beban berat pada node utama. Anda dapat mengaktifkan fitur mengalihkan bacaan dari node utama di konsol untuk mengurangi jumlah permintaan baca yang diarahkan ke node utama. Untuk informasi lebih lanjut, lihat Mengalihkan bacaan dari node utama.
Q: Mengapa saya tidak dapat membaca data yang baru saja saya masukkan?
A: Masalah ini mungkin disebabkan oleh konfigurasi tingkat konsistensi. Titik akhir kluster PolarDB mendukung tingkat konsistensi berikut:
- Konsistensi akhir: Bahkan dalam sesi yang sama (koneksi) atau lintas sesi, konsistensi akhir tidak menjamin pembacaan data yang baru dimasukkan secara langsung.
- Konsistensi sesi: Anda selalu dapat membaca data yang dimasukkan dalam sesi yang sama.
- Konsistensi global: Menjamin Anda dapat membaca data terbaru baik dalam sesi yang sama maupun lintas sesi.
Catatan
Tingkat konsistensi yang lebih tinggi mengurangi performa dan meningkatkan beban di node utama. Pilih dengan hati-hati. Konsistensi sesi memenuhi kebutuhan sebagian besar aplikasi. Untuk pernyataan yang memerlukan konsistensi kuat, gunakan petunjuk /* FORCE_MASTER */. Untuk informasi lebih lanjut, lihat Tingkat konsistensi.
Q: Bagaimana cara memaksa SQL dijalankan di node utama?
A: Saat menggunakan titik akhir kluster, tambahkan /* FORCE_MASTER */ atau /* FORCE_SLAVE */ sebelum pernyataan SQL untuk memaksa routing. Untuk informasi lebih lanjut, lihat Sintaks Hint.
- /* FORCE_MASTER */ memaksa permintaan diarahkan ke database utama. Gunakan ini untuk permintaan baca yang memerlukan konsistensi tinggi.
- /* FORCE_SLAVE */ memaksa permintaan diarahkan ke node read-only. Gunakan ini untuk kasus di mana proksi PolarDB memerlukan sintaks khusus untuk mengarahkan ke node read-only demi kebenaran (misalnya, panggilan prosedur tersimpan atau penggunaan multistatement, yang secara default diarahkan ke node utama).
Catatan
- Hint memiliki prioritas routing tertinggi dan mengesampingkan pengaturan tingkat konsistensi serta pemisahan transaksi. Evaluasi penggunaannya sebelum menerapkannya.
- Jangan sertakan perintah modifikasi parameter GUC dalam hint. Misalnya, hindari /*FORCE_SLAVE*/ set enable_hashjoin = off;. Perintah semacam ini dapat menghasilkan hasil kueri yang tidak terduga.
Q: Dapatkah saya menetapkan titik akhir berbeda untuk aplikasi bisnis yang berbeda? Apakah titik akhir ini menyediakan isolasi?
A: Anda dapat membuat beberapa titik akhir kustom untuk aplikasi bisnis yang berbeda. Jika node dasarnya berbeda, titik akhir kustom menyediakan isolasi dan tidak saling memengaruhi. Untuk petunjuk pembuatan titik akhir kustom, lihat Tambahkan titik akhir kluster kustom.
Q: Jika saya memiliki beberapa node read-only, bagaimana cara membuat titik akhir single-node untuk node read-only tertentu?
A: Anda dapat membuat titik akhir single-node hanya ketika mode baca/tulis titik akhir kluster adalah read-only dan kluster memiliki tiga node atau lebih. Untuk langkah-langkah detailnya, lihat Konfigurasikan titik akhir kluster.
Peringatan
Setelah Anda membuat titik akhir single-node, titik akhir tersebut mungkin tidak tersedia hingga satu jam jika node gagal. Jangan gunakan di lingkungan produksi.
Q: Berapa banyak titik akhir single-node yang dapat saya buat dalam satu kluster?
A: Jika kluster Anda memiliki tiga node, Anda dapat membuat titik akhir single-node hanya untuk satu node read-only. Jika kluster Anda memiliki empat node, Anda dapat membuat titik akhir single-node untuk dua node read-only. Pola ini berlanjut sesuai jumlah node.
Q: Saya hanya menggunakan titik akhir utama, tetapi node read-only menunjukkan beban. Apakah titik akhir utama mendukung pemisahan baca/tulis?
A: Titik akhir utama tidak mendukung pemisahan baca/tulis. Titik akhir ini selalu terhubung ke node utama. QPS kecil di node read-only adalah hal normal dan tidak terkait dengan titik akhir utama.

Manajemen dan pemeliharaan

Q: Bagaimana cara menambahkan kolom dan indeks secara online?
A: Anda dapat menggunakan DDL online native, pt-osc, dan gh-ost. Kami merekomendasikan penggunaan DDL online native.
Catatan
Saat menggunakan pt-osc, jangan gunakan parameter yang terkait dengan deteksi master-slave, seperti recursion-method. pt-osc mendeteksi status master-slave menggunakan replikasi Binlog. Namun, PolarDB menggunakan replikasi fisik secara internal dan tidak menyediakan informasi replikasi berbasis Binlog.
Q: Apakah PolarDB mendukung bulk insert?
A: Ya.
Q: Jika saya hanya menulis data ke node write-only, apakah PolarDB mendukung bulk insert? Berapa jumlah maksimum nilai per insert?
A: Ya. Jumlah maksimum nilai per insert ditentukan oleh parameter max_allowed_packet. Untuk detailnya, lihat Replikasi dan max_allowed_packet.
Q: Apakah PolarDB mendukung bulk insert menggunakan titik akhir kluster?
A: Ya.
Q: Apakah ada latensi replikasi antara node utama (primary) dan node read-only (standby)?
A: Ya. Latensi replikasi berada pada level milidetik.
Q: Apa penyebab peningkatan latensi replikasi?
A: Latensi replikasi meningkat dalam kasus-kasus berikut:
- Beban tulis tinggi di node utama menghasilkan redo log berlebihan, sehingga membebani node read-only.
- Beban tinggi di node read-only mengonsumsi sumber daya yang dibutuhkan untuk menerapkan redo log.
- Kemacetan I/O memperlambat pembacaan dan penulisan redo log.
Q: Bagaimana cara memastikan konsistensi kueri saat latensi replikasi ada?
A: Gunakan titik akhir kluster dan pilih tingkat konsistensi yang sesuai. Tingkat konsistensi, dari tertinggi ke terendah, adalah konsistensi global (konsistensi kuat), konsistensi sesi, dan konsistensi akhir. Untuk informasi lebih lanjut, lihat Tingkat konsistensi.
Q: Dapatkah RPO bernilai nol selama kegagalan single-node?
A: Ya.
Q: Bagaimana cara kerja peningkatan spesifikasi (misalnya, dari 2 vCPU dan 8 GB ke 4 vCPU dan 16 GB) di backend? Apa dampaknya terhadap bisnis?
A: Baik proksi PolarDB maupun node database harus ditingkatkan ke konfigurasi baru. Peningkatan bergilir di beberapa node meminimalkan dampak terhadap bisnis. Setiap peningkatan memakan waktu sekitar 10 hingga 15 menit. Dampak terhadap bisnis berlangsung tidak lebih dari 30 detik, selama itu terjadi 1 hingga 3 pemutusan koneksi sementara. Untuk informasi lebih lanjut, lihat Ubah spesifikasi secara manual.
Q: Berapa lama waktu yang dibutuhkan untuk menambahkan node? Apakah berdampak pada bisnis?
A: Penambahan setiap node memakan waktu lima menit dan tidak berdampak pada bisnis. Untuk petunjuknya, lihat Tambahkan node.
Catatan
Koneksi pemisahan baca/tulis baru yang dibuat setelah penambahan node read-only akan meneruskan permintaan ke node tersebut. Koneksi pemisahan baca/tulis yang sudah ada tidak meneruskan permintaan ke node baru. Anda harus memutus dan menyambung ulang koneksi, misalnya dengan me-restart aplikasi Anda.
Q: Berapa lama waktu yang dibutuhkan untuk memperbarui ke revisi terbaru? Apakah berdampak pada bisnis?
A: PolarDB menggunakan peningkatan bergilir di beberapa node untuk meminimalkan dampak terhadap bisnis. Pembaruan biasanya memakan waktu tidak lebih dari 30 menit. Selama pembaruan, proksi database atau mesin kernel direstart, yang mungkin menyebabkan pemutusan koneksi sementara. Lakukan pembaruan selama jam sepi dan pastikan aplikasi Anda memiliki mekanisme penyambungan ulang otomatis. Untuk informasi lebih lanjut, lihat Manajemen versi minor.
Q: Bagaimana cara kerja failover otomatis?
A: PolarDB menggunakan arsitektur ketersediaan tinggi aktif-aktif. Failover otomatis terjadi antara node utama yang dapat dibaca/ditulis dan node read-only. Sistem secara otomatis memilih node utama baru. Setiap node PolarDB memiliki prioritas failover yang menentukan kemungkinannya dipilih sebagai node utama. Saat prioritasnya sama, node memiliki peluang pemilihan yang sama. Untuk informasi lebih lanjut, lihat Failover otomatis atau manual node utama/standby.
Q: Izin apa saja yang diperlukan untuk menghentikan koneksi di PolarDB for MySQL?
A: Di MySQL, menghentikan koneksi (menggunakan perintah KILL) memerlukan izin tertentu. Untuk menghentikan koneksi pengguna reguler lain, Anda memerlukan izin PROCESS.
Catatan
- Menghentikan koneksi Anda sendiri: Pengguna mana pun dapat menghentikan koneksi mereka sendiri tanpa izin tambahan.
- Menghentikan sesi lain untuk pengguna yang sama: Memerlukan izin PROCESS.
- Menghentikan koneksi pengguna reguler lain: Akun dengan hak istimewa tinggi harus menggunakan perintah KILL dengan hati-hati di PolarDB for MySQL.
Q: Apakah error [ERROR] InnoDB: fil_space_extend space_name:xxx dalam log operasional memengaruhi bisnis yang ada?
A: Ini tidak memengaruhi bisnis yang ada. Pesan log ini menunjukkan bahwa setelah node baca/tulis kluster PolarDB memperluas file, node read-only menyinkronkan informasi ukuran file di memori. Tingkat log untuk kluster MySQL 5.7 belum disesuaikan dari ERROR. Oleh karena itu, di node read-only, pesan ini dapat dianggap sebagai pesan tingkat INFO dan tidak memengaruhi bisnis Anda.
Q: Apa arsitektur proksi database? Apakah mendukung failover? Bagaimana ketersediaan tinggi dijamin?
A: Proksi database menggunakan arsitektur ketersediaan tinggi dual-node. Trafik didistribusikan secara merata 1:1 di kedua node proksi. Sistem terus-menerus memeriksa status kesehatan node proksi. Saat sebuah node gagal, sistem secara aktif memutus koneksi di node tersebut. Node sehat yang tersisa secara otomatis menangani seluruh trafik, memastikan layanan tidak terganggu. Sistem juga secara otomatis membangun kembali dan memulihkan node proksi yang gagal. Proses ini biasanya selesai dalam waktu dua menit. Selama periode ini, kluster database tetap dapat diakses.
Dalam kasus ekstrem, koneksi di node yang gagal mungkin tidak segera terputus dan menjadi tidak responsif. Untuk mengatasi hal ini, konfigurasikan kebijakan timeout yang wajar di sisi klien (seperti socketTimeout dan connectTimeout JDBC). Hal ini memungkinkan lapisan aplikasi mendeteksi dan menghentikan koneksi yang hang secara tepat waktu, meningkatkan toleransi kesalahan dan efisiensi respons.
Q: Bagaimana cara melihat log error untuk kluster PolarDB for MySQL?
A: Buka Konsol PolarDB. Di panel navigasi kiri halaman detail kluster target, buka Diagnostics and Optimization > Log Management. Kemudian, lihat log error di tab Operational Logs.

Q: Apakah PolarDB for MySQL secara otomatis membuat primary key implisit untuk tabel tanpa primary key?

A: Ya. PolarDB for MySQL secara default membuat primary key implisit untuk tabel tanpa primary key.

Cara melihat primary key implisit

-- Setel parameter untuk menampilkan primary key implisit
SET show_ipk_info = 1;

-- Lihat struktur tabel
SHOW CREATE TABLE t;

Kolom __#alibaba_rds_row_id#__ adalah primary key implisit.

+-------+------------------------------------------------------------------------------------------------------------+
| Table | Create Table                                                                                               |
+-------+------------------------------------------------------------------------------------------------------------+
| t     | CREATE TABLE `t` (
  `id` int(11) DEFAULT NULL,
  `__#alibaba_rds_row_id#__` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'Implicit Primary Key by RDS',
  KEY `__#alibaba_rds_row_id#__` (`__#alibaba_rds_row_id#__`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
+-------+------------------------------------------------------------------------------------------------------------+

Q: Mengapa aplikasi saya melaporkan Lock wait timeout exceeded, dan mengapa saya menemukan transaksi dengan trx_mysql_thread_id sama dengan 0?
A: Saat aplikasi Anda berinteraksi dengan PolarDB for MySQL dan mengalami gangguan bisnis akibat tunggu kunci, serta Anda mengamati thread dengan thread_id sama dengan 0 di database, hal ini biasanya berarti transaksi XA (terdistribusi) yang belum selesai sedang memegang kunci. Bagian ini memandu Anda melalui troubleshooting.
Gejala
- Aplikasi atau klien Anda menerima error ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction saat terhubung ke database.
- Setelah login ke database dan menjalankan SELECT * FROM information_schema.innodb_trx;, Anda menemukan transaksi dengan trx_mysql_thread_id sama dengan 0. Transaksi ini berjalan lama dan memblokir transaksi lain.
Penyebab
Di mesin penyimpanan InnoDB, trx_mysql_thread_id sama dengan 0 mengidentifikasi transaksi XA. Hal ini umum terjadi selama proses commit dua fase transaksi XA. Setelah transaksi berhasil menjalankan XA PREPARE dan memasuki status prepared, jika manajer transaksi eksternal gagal mengirim XA COMMIT (commit) atau XA ROLLBACK (rollback) karena masalah jaringan, pengecualian program, atau alasan lain, transaksi tetap dalam status prepared. Selama dalam status ini, transaksi memegang kunci yang telah diperolehnya, memblokir transaksi lain yang membutuhkan sumber daya tersebut dan akhirnya menyebabkan timeout tunggu kunci.
Solusi
Anda harus melakukan intervensi manual dan melakukan commit (COMMIT) atau rollback (ROLLBACK) transaksi XA yang prepared berdasarkan konteks bisnis Anda.
1. Temukan transaksi XA yang belum dikomit: Jalankan perintah XA RECOVER; untuk mencantumkan transaksi XA yang belum dikomit. Catat nilai formatID, gtrid_length, bqual_length, dan data untuk transaksi yang perlu Anda tangani. Nilai-nilai ini penting untuk langkah berikutnya.
2. Lakukan commit atau rollback transaksi XA secara manual: Setelah mengidentifikasi transaksi XA, pilih untuk melakukan commit atau rollback sesuai kebutuhan.
  1. Dapatkan identifier transaksi XA (xid): xid terdiri dari gtrid, bqual, dan formatID. Bangun xid menggunakan nilai yang diambil pada langkah sebelumnya.
    gtrid: Ekstrak string dengan panjang gtrid_length dari awal field data.
    bqual: Ekstrak string dengan panjang bqual_length dari akhir field data.
    formatID: Gunakan nilai field formatID secara langsung.
    Menggunakan langkah sebelumnya sebagai contoh, bangun tiga bagian xid. Anda dapat menggunakan fungsi substring untuk membagi field data.
    SELECT substring('192.168.1.2_app_name_test',1,11) AS gtrid, substring('192.168.1.2_app_name_test',-14) AS bqual; +-------------+----------------+ | gtrid | bqual | +-------------+----------------+ | 192.168.1.2 | _app_name_test | +-------------+----------------+
    gtrid: '192.168.1.2'
    bqual: '_app_name_test'
    formatID: 10000
  2. Lakukan commit atau rollback transaksi XA: Melakukan commit atau rollback transaksi XA secara manual dapat menyebabkan status akhirnya berbeda dari maksud koordinator asli, berisiko menyebabkan inkonsistensi data. Sebelum menjalankan perintah berikut, pahami sepenuhnya konteks bisnis dan pastikan aman untuk dilanjutkan.
    Commit: Jika Anda menentukan transaksi harus dikomit, jalankan:
    XA COMMIT '192.168.1.2', '_app_name_test', 10000;
    Rollback: Jika Anda menentukan transaksi harus di-rollback, jalankan:
    XA ROLLBACK '192.168.1.2', '_app_name_test', 10000;
3. Setelah eksekusi berhasil, kunci yang dipegang oleh transaksi XA yang belum dikomit dilepaskan, dan layanan database kembali normal.
Untuk informasi lebih lanjut tentang sintaks transaksi XA, lihat Dokumentasi MySQL: Pernyataan XA.
Mengapa kluster PolarDB for MySQL 8.0 yang berbeda menunjukkan perilaku penanganan error yang tidak konsisten saat membandingkan tipe tanggal dan waktu yang tidak valid?
- Deskripsi: Kluster PolarDB for MySQL 8.0 dibagi menjadi dua versi: MySQL 8.0.1 dan MySQL 8.0.2. Versi-versi ini sepenuhnya kompatibel dengan MySQL 8.0.13 dan MySQL 8.0.18, masing-masing. Namun, keduanya menangani tipe tanggal dan waktu yang tidak valid secara tidak konsisten.
  Secara khusus, saat membandingkan literal string dengan tipe waktu, sistem mencoba mengonversi string tersebut ke tipe waktu. Jika string tersebut merupakan tanggal yang tidak valid, konversi gagal. Kedua versi berperilaku berbeda saat gagal: MySQL 8.0.13 hanya mengeluarkan WARNING, sedangkan MySQL 8.0.18 mengembalikan kode error ER_WRONG_VALUE. Oleh karena itu, kedua versi kluster PolarDB for MySQL 8.0 ini menunjukkan perilaku error yang tidak konsisten saat membandingkan field tanggal dan waktu yang tidak valid.
- Solusi: Untuk memastikan hasil eksekusi SQL yang konsisten (semua berhasil atau semua gagal), gunakan versi mesin utama yang sama di beberapa kluster PolarDB for MySQL—semua MySQL 8.0.1 atau semua MySQL 8.0.2.

Backup dan pemulihan

Q: Metode backup apa yang digunakan PolarDB?
A: PolarDB menggunakan snapshot untuk backup. Untuk informasi lebih lanjut, lihat Metode backup 1: Backup otomatis dan Metode backup 2: Backup manual.
Q: Seberapa cepat pemulihan database?
A: Pemulihan (kloning) dari set cadangan (snapshot) memakan waktu 40 menit per TB. Pemulihan titik-waktu tertentu memerlukan penerapan redo log, yang memakan waktu sekitar 20 hingga 70 detik per GB. Waktu pemulihan total adalah jumlah kedua bagian tersebut.

Performa dan kapasitas

Q: Mengapa peningkatan performa PolarDB for MySQL dibandingkan RDS for MySQL tidak terlihat jelas?
A: Sebelum membandingkan performa PolarDB for MySQL dan RDS for MySQL, tinjau pertimbangan berikut untuk mendapatkan hasil perbandingan yang akurat dan wajar.
- Bandingkan PolarDB for MySQL dan RDS for MySQL dengan spesifikasi yang identik.
- Bandingkan PolarDB for MySQL dan RDS for MySQL dengan versi yang identik.
  Versi berbeda menggunakan mekanisme implementasi yang berbeda. Misalnya, MySQL 8.0 dioptimalkan untuk CPU multi-core dengan mengabstraksi thread seperti Log_writer, log_fluser, log_checkpoint, dan log_write_notifier. Namun, performa pada sistem dengan core CPU lebih sedikit mungkin lebih buruk daripada MySQL 5.6 atau 5.7. Hindari membandingkan PolarDB for MySQL 5.6 dengan RDS for MySQL 5.7 atau 8.0 karena MySQL 5.6 menggunakan pengoptimal yang lebih lama.
- Kami merekomendasikan mensimulasikan workload produksi nyata atau menggunakan sysbench untuk perbandingan performa. Hal ini menghasilkan hasil yang lebih mendekati skenario dunia nyata.
- Saat membandingkan performa baca, hindari penggunaan pernyataan SQL tunggal.
  PolarDB menggunakan arsitektur komputasi-penyimpanan terpisah. Pernyataan tunggal mengalami latensi jaringan, sehingga mengurangi performa baca dibandingkan RDS. Tingkat hit cache database produksi biasanya di atas 99%. Hanya pembacaan pertama yang memicu I/O. Pembacaan berikutnya menggunakan buffer pool dan tidak memicu I/O, sehingga menghasilkan performa yang setara.
- Saat membandingkan performa tulis, hindari penggunaan pernyataan SQL tunggal. Sebagai gantinya, simulasi workload produksi.
  Untuk membandingkan dengan performa RDS, bandingkan PolarDB (node utama + node read-only) dengan RDS (instans utama + instans read-only semi-sinkron). PolarDB menggunakan mekanisme kuorum untuk penulisan, artinya penulisan berhasil jika ditulis ke mayoritas dari tiga replika (dua atau lebih). PolarDB menjamin redundansi data dan replikasi sinkron kuat di lapisan penyimpanan. Membandingkan dengan replikasi semi-sinkron RDS for MySQL (bukan asinkron) lebih tepat.
Untuk hasil perbandingan performa antara PolarDB for MySQL dan RDS for MySQL, lihat Perbandingan performa: PolarDB for MySQL vs. RDS for MySQL.
Q: Berapa jumlah maksimum tabel? Pada titik mana performa mungkin menurun?
A: Jumlah maksimum tabel dibatasi oleh jumlah file. Untuk detailnya, lihat Batasan.
Q: Dapatkah partisi tabel meningkatkan performa kueri PolarDB?
Secara umum, performa dapat ditingkatkan jika kueri SQL dibatasi pada satu partisi saja.
Q: Apakah PolarDB mendukung pembuatan 10.000 database? Berapa jumlah maksimum database?
A: PolarDB mendukung pembuatan 10.000 database. Jumlah maksimum database dibatasi oleh jumlah file. Untuk detailnya, lihat Batasan.
Q: Apakah jumlah maksimum koneksi terkait dengan jumlah node read-only? Dapatkah saya meningkatkan jumlah maksimum koneksi dengan menambahkan node read-only?
A: Jumlah node read-only tidak memengaruhi jumlah maksimum koneksi. Jumlah maksimum koneksi untuk PolarDB ditentukan oleh spesifikasi node. Untuk detailnya, lihat Batasan. Untuk meningkatkan jumlah maksimum koneksi, tingkatkan spesifikasi.
Q: Bagaimana IOPS dibatasi dan diisolasi? Dapatkah beberapa node kluster PolarDB bersaing untuk I/O?
A: Setiap node dalam kluster PolarDB memiliki IOPS yang ditetapkan sesuai spesifikasinya. IOPS diisolasi antar node dan tidak memengaruhi node lain.
Q: Apakah performa yang menurun di node read-only memengaruhi node utama?
A: Beban tinggi atau peningkatan latensi replikasi di node read-only mungkin sedikit meningkatkan konsumsi memori di node utama.
Q: Apa dampak performa dari mengaktifkan Binlog?
A: Mengaktifkan Binlog tidak memengaruhi performa SELECT. Hal ini memengaruhi performa INSERT, UPDATE, dan DELETE. Dalam workload baca/tulis seimbang, mengaktifkan Binlog mengurangi performa tidak lebih dari 10%.
Q: Apa dampak performa dari mengaktifkan SQL Explorer (audit log SQL lengkap)?
A: Tidak ada.
Q: Protokol jaringan berkecepatan tinggi apa yang digunakan PolarDB?
A: PolarDB menggunakan teknologi RDMA dual 25 Gbps antara node komputasi dan node penyimpanan, serta antara replika node penyimpanan. Hal ini menghadirkan performa I/O dengan latensi rendah dan throughput tinggi.
Q: Berapa bandwidth maksimum untuk koneksi jaringan publik PolarDB?
A: Bandwidth maksimum untuk koneksi jaringan publik PolarDB adalah 10 Gbit/s.

Permasalahan tabel besar

Q: Keunggulan apa yang ditawarkan PolarDB for MySQL untuk penyimpanan tabel besar dibandingkan database lokal tradisional?
A: Di PolarDB for MySQL, sebuah tabel secara fisik dibagi di beberapa server penyimpanan. Oleh karena itu, I/O untuk sebuah tabel didistribusikan di beberapa disk penyimpanan. Throughput I/O keseluruhan (bukan latensi I/O) jauh lebih unggul dibandingkan database lokal terpusat.
Q: Bagaimana cara mengoptimalkan tabel besar?
A: Gunakan tabel partisi.
Q: Kapan sebaiknya menggunakan tabel partisi?
A: Gunakan tabel partisi saat Anda perlu mengontrol jumlah data yang diakses oleh kueri melalui pemangkasan partisi dan ingin pemangkasan ini transparan terhadap kode aplikasi Anda (tidak perlu perubahan kode). Misalnya, Anda dapat menggunakan tabel partisi untuk membersihkan data bisnis historis secara berkala (seperti menghapus partisi bulan terlama dan membuat partisi baru untuk bulan berikutnya guna menyimpan hanya data enam bulan terakhir).
Q: Apa cara terbaik untuk menyalin tabel besar (misalnya, menyalin seluruh tabel A ke tabel B) dalam database PolarDB for MySQL yang sama?
A: Gunakan pernyataan SQL berikut:
```
create table B as select * from A
```

Stabilitas

Q: Dapatkah saya mengoptimalkan koneksi PHP berumur pendek di bawah konkurensi tinggi?
A: Ya. Aktifkan pool koneksi tingkat sesi di titik akhir kluster. Untuk informasi lebih lanjut, lihat Konfigurasikan titik akhir kluster.
Q: Bagaimana cara mencegah pernyataan SQL yang tidak efisien menurunkan performa database secara keseluruhan?
A: Jika kluster PolarDB for MySQL Anda menjalankan versi 5.6 atau 8.0, gunakan fitur kontrol konkurensi Concurrency Control untuk mengendalikan aliran pernyataan tertentu.
Q: Apakah PolarDB mendukung timeout sesi idle?
A: Ya. Ubah parameter wait_timeout untuk menyesuaikan periode timeout sesi idle. Untuk petunjuknya, lihat Setel parameter kluster dan node.
Q: Bagaimana cara mengidentifikasi pernyataan SQL lambat?
A: Anda dapat mengidentifikasi pernyataan SQL lambat dengan dua cara berikut:
- Kueri SQL lambat secara langsung di konsol. Untuk informasi lebih lanjut, lihat SQL Lambat.
- Setelah terhubung ke kluster database, jalankan show processlist; untuk mengidentifikasi pernyataan SQL dengan waktu eksekusi lama. Untuk petunjuk menghubungkan ke kluster database, lihat Hubungkan ke kluster database.
Q: Bagaimana cara menghentikan pernyataan SQL lambat?
A: Setelah mengidentifikasi pernyataan SQL lambat, periksa ID-nya dan jalankan kill <Id> untuk menghentikannya.

Siklus hidup data

Q: Bagaimana PolarDB for MySQL mengarsipkan data hot dan warm ke cold storage?
A: PolarDB for MySQL mendukung pengarsipan data hot dari engine InnoDB dan data warm dari engine X-Engine di PolarStore. Anda dapat menentukan kebijakan DDL untuk mengarsipkan data ke media cold storage OSS dalam format CSV atau ORC. Setelah data diarsipkan, ruang penyimpanan di PolarStore dilepaskan, dan biaya penyimpanan database secara keseluruhan berkurang secara efektif. Untuk informasi lebih lanjut, lihat Arsipkan data dingin secara manual.
Q: Apakah PolarDB for MySQL mendukung pemisahan dan pengarsipan otomatis data hot, warm, dan cold? Bagaimana cara kerjanya?
A: PolarDB for MySQL mendukung pemisahan dan pengarsipan otomatis data hot, warm, dan cold. Menggunakan kebijakan DLM yang ditentukan, data di PolarStore secara otomatis diarsipkan ke media penyimpanan OSS berbiaya rendah, mengurangi biaya penyimpanan database. Untuk informasi lebih lanjut, lihat Arsipkan data dingin secara otomatis.