Pertanyaan umum mengenai mesin PolarDB - PolarDB - Alibaba Cloud Documentation Center

Topik ini menyediakan jawaban atas pertanyaan yang sering diajukan mengenai PolarDB for MySQL, , dan .

Pertanyaan umum

T: Apa itu PolarDB?
J: PolarDB adalah layanan database relasional cloud yang tersedia di pusat data di lebih dari 10 wilayah di seluruh dunia, menawarkan pengalaman siap pakai. PolarDB mendukung tiga engine yang kompatibel 100% dengan MySQL, kompatibel 100% dengan PostgreSQL, dan sangat kompatibel dengan sintaks Oracle. Layanan ini menyediakan kapasitas penyimpanan hingga 200 TB. Untuk informasi lebih lanjut, lihat Apa itu PolarDB for MySQL Enterprise Edition?, , atau
T: Mengapa PolarDB merupakan pilihan yang lebih baik dibandingkan database tradisional?
J: Dibandingkan dengan database tradisional, PolarDB dapat menyimpan ratusan terabyte data serta menyediakan fitur-fitur seperti ketersediaan tinggi, keandalan tinggi, skalabilitas elastis cepat, dan backup tanpa kunci. Untuk informasi lebih lanjut, lihat Manfaat, , atau .
T: Kapan PolarDB dirilis dan kapan tersedia secara komersial?
J: PolarDB dirilis dalam pratinjau publik pada September 2017 dan tersedia secara komersial pada Maret 2018.
T: Apa itu kluster dan node?
J: PolarDB Cluster Edition menggunakan arsitektur multi-node. Sebuah kluster berisi satu node utama dan beberapa node read-only. Satu kluster PolarDB dapat ditempatkan lintas zona tetapi tidak lintas wilayah. Layanan ini dikelola dan ditagih berdasarkan tingkat kluster. Untuk informasi lebih lanjut, lihat Istilah, , atau .
T: Bahasa pemrograman apa saja yang didukung?
J: PolarDB mendukung berbagai bahasa pemrograman, termasuk Java, Python, PHP, Go, C, C++, .NET, dan Node.js. Bahasa pemrograman apa pun yang mendukung MySQL native dapat digunakan dengan PolarDB for MySQL. Untuk informasi lebih lanjut, kunjungi situs web resmi MySQL.
T: Mesin penyimpanan apa saja yang didukung?
J: PolarDB menawarkan dua seri produk. Mesin penyimpanan yang didukung bervariasi tergantung seri tersebut.
PolarDB for MySQL Cluster Edition menggunakan mesin penyimpanan InnoDB untuk semua tabel. Saat Anda membuat tabel, PolarDB for MySQL secara otomatis mengonversi mesin non-InnoDB, seperti MyISAM, Memory, dan CSV, menjadi InnoDB. Hal ini memastikan bahwa meskipun tabel sumber Anda tidak menggunakan InnoDB, tabel tersebut tetap dapat dimigrasikan ke PolarDB for MySQL.
T: Apakah PolarDB merupakan database terdistribusi?
J: Ya. PolarDB adalah kluster penyimpanan terdistribusi berbasis protokol konsensus Parallel Raft. Mesin komputasinya terdiri dari 1 hingga 16 node komputasi yang didistribusikan di server yang berbeda. Kluster ini menyediakan kapasitas penyimpanan maksimum 200 TB dan mendukung hingga 88 core CPU serta 710 GB memori. Anda dapat melakukan penskalaan dinamis sumber daya penyimpanan dan komputasi secara online tanpa memengaruhi beban kerja Anda.
T: Setelah membeli kluster PolarDB, apakah saya juga perlu membeli middleware database PolarDB-X untuk menerapkan sharding?
J: Ya.
T: Apakah PolarDB mendukung partisi tabel?
J: Ya.
T: Bisakah saya mengubah wilayah kluster PolarDB setelah pembelian?
J: Tidak, Anda tidak dapat mengubah wilayah kluster setelah pembelian.
T: Apakah PolarDB secara otomatis menyertakan mekanisme partisi?
J: Ya. PolarDB melakukan partisi di lapisan penyimpanan, yang transparan bagi pengguna.
T: Bagaimana kluster single-node memastikan ketersediaan layanan dan keandalan data?
J: Kluster single-node berjalan pada satu node komputasi untuk tujuan tertentu. Meskipun hanya memiliki satu node, kluster single-node memanfaatkan teknologi seperti penjadwalan komputasi instan dan penyimpanan multi-replika terdistribusi untuk memastikan ketersediaan layanan dan keandalan data yang tinggi.
T: Bagaimana cara membeli kluster PolarDB single-node?
J: Seri produk single-node tidak lagi tersedia. Namun, Anda dapat membuat kluster yang berfungsi sebagai kluster single-node dengan mengatur jumlah node read-only menjadi 0 saat membeli kluster PolarDB.

Kompatibilitas

T: Apakah PolarDB kompatibel dengan MySQL Community Edition?
J: PolarDB for MySQL kompatibel 100% dengan MySQL Community Edition.
T: Tingkat isolasi transaksi apa saja yang didukung?
J: PolarDB for MySQL mendukung tingkat isolasi READ-UNCOMMITTED, READ-COMMITTED (default), dan REPEATABLE-READ. Tingkat isolasi SERIALIZABLE tidak didukung.
T: Apakah output SHOW PROCESSLIST berbeda dari MySQL Community Edition?
J: Jika Anda terhubung ke kluster menggunakan titik akhir utama, output-nya sama. Jika Anda menggunakan titik akhir kluster, output-nya sedikit berbeda. Anda akan menemukan beberapa catatan dengan ID thread yang sama, masing-masing sesuai dengan node di kluster PolarDB for MySQL.
T: Apakah mekanisme metadata lock (MDL) di PolarDB for MySQL berbeda dari MySQL Community Edition?
J: Tidak, mekanisme MDL di PolarDB for MySQL sama dengan MySQL Community Edition. Namun, karena node PolarDB for MySQL menggunakan arsitektur shared-storage, ketika Anda melakukan operasi DDL pada node utama, node read-only mungkin membaca data antara dari operasi DDL tersebut, sehingga menyebabkan inkonsistensi data. Untuk mencegah hal ini, PolarDB for MySQL menyinkronkan MDL eksklusif yang terlibat dalam operasi DDL ke node read-only melalui redo log. Hal ini memblokir thread pengguna lain di node read-only untuk mengakses tabel selama operasi DDL. Dalam beberapa kasus, hal ini dapat menghentikan sementara operasi DDL. Anda dapat menjalankan perintah SHOW PROCESSLIST untuk melihat status eksekusi operasi DDL. Jika statusnya Wait for syncing with replicas, berarti telah terjadi penghentian sementara. Untuk informasi lebih lanjut tentang cara mengatasi masalah ini, lihat Lihat status eksekusi pernyataan DDL dan status MDL.
T: Apakah format binlog berbeda dari format MySQL native?
J: Tidak, tidak ada perbedaan.
T: Apakah performance schema dan sys schema didukung?
J: Ya.
T: Apakah mekanisme pengumpulan statistik tabel berbeda dari MySQL Community Edition?
J: Statistik tabel pada node utama kluster PolarDB for MySQL konsisten dengan MySQL Community Edition. Untuk memastikan rencana eksekusi yang konsisten antara node utama dan node read-only, setiap pembaruan statistik pada node utama disinkronkan ke node read-only. Selain itu, Anda dapat menjalankan perintah ANALYZE TABLE pada node read-only untuk memuat proaktif statistik terbaru dari disk.
T: Apakah PolarDB mendukung transaksi XA? Apakah berbeda dari implementasi resmi MySQL?
J: Ya, PolarDB mendukung transaksi XA, dan tidak ada perbedaan dari implementasi resmi MySQL.
T: Apakah PolarDB mendukung pencarian teks penuh?
J: Ya.
Catatan
Saat menggunakan indeks teks penuh, mungkin terjadi latensi data pada cache indeks di node read-only. Kami menyarankan agar Anda menggunakan titik akhir utama untuk operasi baca dan tulis yang melibatkan indeks teks penuh guna memastikan Anda mendapatkan data terbaru.
T: Apakah Percona Toolkit didukung?
J: Ya, tetapi kami menyarankan Anda menggunakan online DDL.
T: Apakah gh-ost didukung?
A: Ya, tetapi kami menyarankan Anda menggunakan DDL online.

Penagihan

T: Apa saja item yang dapat ditagih dari kluster PolarDB?
J: Item yang dapat ditagih mencakup storage space, node komputasi, backup (dengan kuota gratis), dan SQL Explorer (opsional). Untuk informasi lebih lanjut, lihat Item yang dapat ditagih, , atau .
T: Apa saja yang termasuk dalam storage space yang dikenai biaya?
J: Storage space yang dikenai biaya 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, , atau .
T: Bagaimana saya dikenai biaya jika menambahkan node read-only?
J: Harga node read-only sama dengan harga node utama. Untuk informasi lebih lanjut, lihat Detail harga node komputasi, , atau .
T: Jika saya menambahkan node read-only, apakah kapasitas penyimpanan menjadi dua kali lipat?
J: Tidak. PolarDB menggunakan arsitektur yang memisahkan komputasi dan penyimpanan. Saat Anda membeli node read-only, Anda menambahkan sumber daya komputasi, yang tidak meningkatkan kapasitas penyimpanan.
Storage space bersifat serverless, sehingga Anda tidak perlu memilih kapasitas saat melakukan pembelian. Kapasitas ini akan diskalakan secara otomatis seiring pertumbuhan data Anda, dan Anda hanya dikenai biaya berdasarkan jumlah data yang digunakan. Setiap spesifikasi kluster memiliki kapasitas penyimpanan maksimum. Untuk meningkatkan batas penyimpanan, tingkatkan spesifikasi kluster, , atau .
T: Bagaimana cara menghentikan biaya untuk kluster pay-as-you-go?
J: Jika Anda tidak lagi memerlukan kluster tersebut, Anda dapat melepaskannya. Melepas kluster akan menghentikan semua biaya di masa depan.
T: Bisakah saya mengubah spesifikasi kluster selama peningkatan sementara?
J: Selama peningkatan sementara, selama status kluster Berjalan, Anda dapat meningkatkan spesifikasi secara manual. Namun, Anda tidak dapat menurunkan spesifikasi secara manual, mengaktifkan auto-scaling, atau menambah atau menghapus node.
T: Berapa bandwidth publik PolarDB, dan apakah ada biaya terkait?
J: PolarDB sendiri tidak memiliki batas bandwidth publik. Bandwidth terutama bergantung pada layanan Server Load Balancer (SLB) yang Anda gunakan. PolarDB tidak membebankan biaya untuk koneksi publik.
T: Mengapa saya masih melihat biaya harian untuk kluster langganan?
J: Item yang dapat ditagih untuk PolarDB mencakup node komputasi (node utama dan node read-only), storage space, backup data (dikenai biaya hanya jika melebihi kuota gratis), SQL Explorer (opsional), dan Global Database Network (GDN) (opsional). Untuk informasi lebih lanjut, lihat Item yang dapat ditagih. Metode penagihan langganan mengharuskan Anda membayar di muka untuk node komputasi saat membuat kluster, tetapi tidak mencakup biaya storage space, backup data, dan SQL Explorer. Biaya untuk item-item pay-as-you-go ini dipotong dari akun Anda setiap jam. Oleh karena itu, meskipun menggunakan langganan, Anda tetap akan menerima tagihan pay-as-you-go.
T: Apakah ada biaya tambahan untuk migrasi satu klik dari ApsaraDB RDS for MySQL ke PolarDB?
J: Proses migrasi satu klik tidak dikenai biaya. Anda hanya dikenai biaya untuk instans ApsaraDB RDS for MySQL dan kluster PolarDB itu sendiri.
T: Mengapa saya masih dikenai biaya untuk storage space setelah menghapus data dari tabel PolarDB menggunakan perintah DELETE?
J: Perintah DELETE hanya menandai baris untuk dihapus. Perintah ini tidak melepaskan ruang tabel.

Akses kluster dan pemisahan baca/tulis

T: Bagaimana cara menerapkan read/write splitting di PolarDB?
J: Anda hanya perlu menggunakan titik akhir kluster di aplikasi Anda. Pemisahan baca/tulis kemudian diterapkan berdasarkan mode baca/tulis yang dikonfigurasi. Untuk informasi lebih lanjut, lihat Konfigurasikan proksi database, , atau .
T: Berapa jumlah maksimum node read-only yang didukung dalam kluster PolarDB?
J: PolarDB menggunakan arsitektur kluster terdistribusi. Sebuah kluster berisi satu node utama dan hingga 15 node read-only. Setidaknya satu node read-only diperlukan untuk memastikan ketersediaan tinggi.
T: Mengapa beban kerja tidak seimbang di antara beberapa node read-only?
J: Ketidakseimbangan beban kerja di antara node read-only dapat disebabkan oleh jumlah koneksi yang rendah ke node tersebut atau oleh titik akhir kluster kustom yang tidak menyertakan semua node read-only dalam konfigurasinya.
T: Apa penyebab beban pada node utama tinggi atau rendah?
J: Beban tinggi pada node utama dapat disebabkan oleh beberapa faktor: koneksi langsung ke titik akhir utama, node utama menerima permintaan baca, sejumlah besar permintaan transaksi, latensi replikasi tinggi yang menyebabkan permintaan dialihkan ke node utama, atau kegagalan node read-only yang menyebabkan permintaan baca dialihkan ke node utama.
Beban rendah pada node utama dapat terjadi jika opsi untuk menerima permintaan baca pada node utama dinonaktifkan.
T: Bagaimana cara mengurangi beban pada node utama?
J: Anda dapat menggunakan metode berikut untuk mengurangi beban pada node utama:
- Terhubung ke kluster PolarDB menggunakan titik akhir kluster. Untuk informasi lebih lanjut, lihat Konfigurasikan proksi database, , atau .
- Jika sejumlah besar transaksi menyebabkan tekanan tinggi pada node utama, Anda dapat mengaktifkan fitur transaction splitting di konsol untuk mengarahkan beberapa kueri dalam transaksi ke node read-only. Untuk informasi lebih lanjut, lihat Pemisahan transaksi, , atau .
- Jika latensi replikasi tinggi menyebabkan permintaan dialihkan ke node utama, Anda dapat mempertimbangkan untuk menurunkan tingkat konsistensi, misalnya dengan menggunakan konsistensi akhir. Untuk informasi lebih lanjut, lihat Tingkat konsistensi, , atau .
- Jika node utama menerima permintaan baca, hal ini juga dapat menyebabkan beban tinggi. Anda dapat menonaktifkan permintaan baca pada node utama dari konsol untuk mengurangi jumlah permintaan baca yang dialihkan ke node tersebut. Untuk informasi lebih lanjut, lihat Node Utama Menerima Permintaan Baca.
T: Mengapa saya tidak dapat membaca data segera setelah data tersebut dimasukkan?
J: Masalah ini mungkin disebabkan oleh konfigurasi tingkat konsistensi. Titik akhir kluster kluster PolarDB mendukung tingkat konsistensi berikut:
- Konsistensi akhir: Tingkat ini tidak menjamin bahwa Anda dapat segera membaca data yang baru dimasukkan, baik dari sesi (koneksi) yang sama maupun berbeda.
- Konsistensi sesi: Tingkat ini menjamin bahwa Anda dapat membaca data yang dimasukkan dalam sesi yang sama.
- Konsistensi global: Tingkat ini menjamin bahwa Anda dapat membaca data terbaru baik dari sesi yang sama maupun sesi yang berbeda.
Catatan
Tingkat konsistensi yang lebih tinggi mengakibatkan kinerja yang lebih rendah dan tekanan yang lebih besar pada node utama. Pilih tingkat konsistensi dengan hati-hati. Untuk sebagian besar skenario aplikasi, konsistensi sesi sudah cukup untuk memastikan operasi bisnis berjalan normal. Untuk beberapa pernyataan yang memerlukan konsistensi kuat, Anda dapat menggunakan petunjuk /*FORCE_MASTER*/. Untuk informasi lebih lanjut, lihat Tingkat konsistensi, , atau .
T: Bagaimana cara memaksa pernyataan SQL dijalankan di node utama?
J: Saat menggunakan titik akhir kluster, Anda dapat menambahkan awalan /*FORCE_MASTER*/ atau /*FORCE_SLAVE*/ pada pernyataan SQL untuk menentukan arah routing-nya. Untuk informasi lebih lanjut, lihat Sintaks HINT, , atau .
- Petunjuk /*FORCE_MASTER*/ memaksa permintaan diarahkan ke node utama. Ini dapat digunakan untuk permintaan baca yang memerlukan tingkat konsistensi lebih tinggi.
- Petunjuk /*FORCE_SLAVE*/ memaksa permintaan diarahkan ke node read-only. Ini dapat digunakan dalam skenario di mana proksi PolarDB secara default mengarahkan sintaks khusus ke node utama untuk memastikan kebenaran, seperti panggilan ke prosedur tersimpan atau penggunaan multi-pernyataan.
Catatan
- Hints memiliki prioritas routing tertinggi dan tidak dibatasi oleh tingkat konsistensi atau pemisahan transaksi. Evaluasi dampak potensial sebelum menggunakannya.
- Jangan menyertakan pernyataan yang memodifikasi parameter GUC dalam hint, seperti /FORCE_SLAVE/ SET enable_hashjoin = off;. Pernyataan semacam ini dapat menyebabkan hasil kueri yang tidak terduga.
T: Bisakah saya menetapkan titik akhir yang berbeda untuk layanan yang berbeda? Apakah titik akhir ini menyediakan isolasi antar layanan?
J: Ya, Anda dapat membuat beberapa titik akhir kustom untuk layanan yang berbeda. Jika titik akhir ini menggunakan node dasar yang berbeda, mereka menyediakan isolasi dan tidak saling memengaruhi. Untuk informasi tentang cara membuat titik akhir kustom, lihat Buat titik akhir kluster kustom, , atau .
T: Jika saya memiliki beberapa node read-only, bagaimana cara membuat titik akhir node tunggal khusus untuk salah satunya?
J: Anda dapat membuat titik akhir node tunggal hanya jika mode baca/tulis titik akhir kluster diatur ke Read Only dan kluster memiliki tiga node atau lebih. Untuk langkah-langkah detail, lihat Konfigurasikan titik akhir kluster, , atau .
Peringatan
Setelah membuat titik akhir node tunggal, jika node tersebut gagal, titik akhir mungkin tidak tersedia hingga satu jam. Jangan gunakan titik akhir node tunggal di lingkungan produksi.
T: Berapa jumlah maksimum titik akhir node tunggal yang dapat saya buat dalam satu kluster?
J: Jika kluster Anda memiliki tiga node, Anda dapat membuat titik akhir node tunggal hanya untuk satu node read-only. Jika kluster Anda memiliki empat node, Anda dapat membuat titik akhir node tunggal terpisah untuk dua node read-only tersebut. Pola ini berlanjut seiring peningkatan jumlah node.
T: Saya hanya menggunakan titik akhir utama, tetapi saya melihat beban pada node read-only. Apakah titik akhir utama juga mendukung pemisahan baca/tulis?
J: Tidak, titik akhir utama tidak mendukung pemisahan baca/tulis. Titik akhir ini selalu hanya terhubung ke node utama. Beberapa QPS kecil pada node read-only adalah hal yang normal dan tidak terkait dengan titik akhir utama.

Manajemen dan pemeliharaan

T: Bagaimana cara menambahkan field dan indeks secara online?
J: Anda dapat menggunakan online DDL native atau alat seperti pt-online-schema-change dan gh-ost. Kami menyarankan agar Anda menggunakan operasi online DDL native.
Catatan
Saat menggunakan pt-online-schema-change, jangan gunakan parameter yang terkait dengan deteksi master-slave, seperti parameter recursion-method. Hal ini karena alat tersebut melakukan deteksi master-slave berdasarkan replikasi binlog. Namun, PolarDB menggunakan replikasi fisik dan tidak memiliki informasi replikasi berbasis binlog.
T: Apakah fitur bulk insert didukung?
J: Ya.
T: Apakah bulk insert didukung jika saya hanya menulis data ke node utama? Berapa jumlah maksimum nilai yang dapat saya masukkan sekaligus?
J: Ya, didukung. Jumlah maksimum nilai yang dapat Anda masukkan sekaligus ditentukan oleh nilai parameter max_allowed_packet. Untuk informasi lebih lanjut, lihat Replikasi dan max_allowed_packet.
T: Bisakah saya melakukan operasi bulk insert melalui titik akhir kluster?
J: Ya.
T: Apakah ada latensi replikasi antara node utama dan node read-only?
J: Ya, terdapat jeda dalam satuan milidetik di antaranya.
T: Apa yang dapat menyebabkan peningkatan latensi replikasi?
J: Latensi replikasi dapat meningkat dalam situasi berikut:
- Beban tulis tinggi pada node utama menghasilkan jumlah redo log yang berlebihan, yang tidak dapat diterapkan tepat waktu oleh node read-only.
- Beban tinggi pada node read-only mengonsumsi sumber daya yang diperlukan untuk menerapkan redo log.
- Bottleneck I/O memperlambat proses membaca dan menulis redo log.
T: Jika terjadi latensi replikasi, bagaimana cara memastikan konsistensi kueri?
J: Anda dapat menggunakan titik akhir kluster dan memilih tingkat konsistensi yang sesuai. Tingkat konsistensi yang tersedia, dari tertinggi ke terendah, adalah konsistensi global (konsistensi kuat), konsistensi sesi, dan konsistensi akhir. Untuk informasi lebih lanjut, lihat Tingkat konsistensi, , atau .
T: Apakah recovery point objective (RPO) 0 dapat dijamin jika terjadi kegagalan satu node?
J: Ya.
T: Bagaimana peningkatan spesifikasi (misalnya, dari 2 core dan 8 GB memori menjadi 4 core dan 16 GB) diimplementasikan di backend? Apa dampaknya terhadap layanan?
J: PolarDB melakukan peningkatan bergilir (rolling upgrade) pada node proxy dan database untuk meminimalkan dampak terhadap layanan. Peningkatan biasanya membutuhkan waktu 10 hingga 15 menit untuk diselesaikan, dengan dampak layanan tidak lebih dari 30 detik. Selama periode ini, dapat terjadi satu hingga tiga error koneksi sementara. Untuk informasi lebih lanjut, lihat Penskalaan manual, , atau .
T: Berapa lama waktu yang dibutuhkan untuk menambahkan node? Apakah hal ini memengaruhi layanan saya?
J: Menambahkan node membutuhkan waktu sekitar lima menit dan tidak memengaruhi layanan Anda. Untuk informasi tentang cara menambahkan node, lihat Tambahkan node, , atau .
Catatan
Setelah menambahkan node read-only, koneksi pemisahan baca/tulis baru akan meneruskan permintaan ke node tersebut. Koneksi pemisahan baca/tulis yang dibuat sebelum penambahan node tidak akan meneruskan permintaan ke node baru. Anda harus memutus dan menghubungkan ulang koneksi tersebut, misalnya dengan me-restart aplikasi Anda.
T: Berapa lama waktu yang dibutuhkan untuk meningkatkan ke versi revisi terbaru? Apakah hal ini memengaruhi layanan saya?
J: PolarDB menggunakan metode peningkatan bergilir (rolling upgrade) di beberapa node untuk meminimalkan dampak terhadap layanan Anda. Peningkatan versi biasanya membutuhkan waktu kurang dari 30 menit. Selama peningkatan, proxy database atau engine kernel DB di-restart, yang dapat menyebabkan error koneksi sementara. Kami menyarankan agar Anda melakukan peningkatan selama jam sepi dan memastikan aplikasi Anda memiliki mekanisme koneksi ulang otomatis. Untuk informasi lebih lanjut, lihat Manajemen versi minor, , atau .
T: Bagaimana cara kerja failover otomatis?
J: PolarDB menggunakan arsitektur kluster ketersediaan tinggi Active-Active. Failover otomatis terjadi antara node utama baca-tulis dan node read-only. Sistem secara otomatis memilih node utama baru. Setiap node dalam kluster PolarDB memiliki prioritas failover, yang menentukan probabilitasnya terpilih sebagai node utama baru selama failover. Jika beberapa node memiliki prioritas yang sama, probabilitas terpilihnya juga sama. Untuk informasi lebih lanjut, lihat Alih bencana otomatis dan manual node utama/cadangan, , atau .
T: Izin apa yang diperlukan untuk menghentikan koneksi di kluster PolarDB for MySQL?
J: Di MySQL, Anda memerlukan izin tertentu untuk menghentikan koneksi menggunakan perintah KILL. Secara khusus, untuk menghentikan koneksi pengguna reguler lain, Anda harus memiliki izin PROCESS.
Catatan
- Menghentikan koneksi Anda sendiri: Setiap pengguna dapat menghentikan koneksi sendiri tanpa izin tambahan.
- Menghentikan sesi lain dari pengguna yang sama: Anda harus memiliki izin PROCESS.
- Menghentikan koneksi pengguna reguler lain: Di PolarDB for MySQL, akun hak istimewa tinggi harus menggunakan perintah KILL dengan hati-hati.
T: Log running saya menunjukkan error [ERROR] InnoDB: fil_space_extend space_name:xxx. Apakah ini memengaruhi layanan saya saat ini?
J: Tidak, ini tidak memengaruhi layanan Anda. Entri log ini menunjukkan bahwa setelah ukuran file diperluas di node baca-tulis kluster PolarDB, node read-only menyinkronkan informasi ukuran file tersebut di memorinya. Di kluster yang menjalankan MySQL 5.7, tingkat log untuk pesan ini tidak disesuaikan dan tetap pada ERROR. Di node read-only, Anda dapat menganggap ini sebagai pesan tingkat INFO. Hal ini tidak memengaruhi layanan Anda.
T: Apa arsitektur proksi database? Apakah memiliki mekanisme failover? Bagaimana ketersediaan tingginya dipastikan?
J: Proksi database menggunakan arsitektur ketersediaan tinggi dua node, mendistribusikan trafik secara merata di antara kedua node proksi tersebut. Sistem terus-menerus memeriksa status kesehatan node proksi. Jika terdeteksi kegagalan node, sistem secara proaktif memutus koneksi pada node tersebut, dan node sehat yang tersisa secara otomatis mengambil alih seluruh trafik untuk memastikan layanan tidak terganggu. Pada saat yang sama, sistem secara otomatis membangun kembali dan memulihkan node proksi yang gagal. Proses ini biasanya selesai dalam waktu sekitar 2 menit. Selama waktu ini, kluster database tetap dapat diakses.
Dalam kasus langka, koneksi ke node yang gagal mungkin tidak diputus tepat waktu dan menjadi tidak responsif. Untuk menangani situasi seperti ini, konfigurasikan kebijakan timeout yang sesuai di sisi klien, seperti socketTimeout dan connectTimeout JDBC. Hal ini memungkinkan lapisan aplikasi untuk segera mendeteksi dan menghentikan koneksi yang tertunda, sehingga meningkatkan toleransi kesalahan dan efisiensi respons sistem.
T: Bagaimana cara melihat log error untuk kluster PolarDB for MySQL?
J: Buka Konsol PolarDB. Di halaman detail kluster, buka Diagnostics and Optimization > Log Management di panel navigasi sebelah kiri. Di tab Running Logs, Anda dapat melihat log error.

T: Apakah PolarDB for MySQL secara otomatis membuat primary key tersembunyi untuk tabel tanpa primary key?

J: Ya. Secara default, PolarDB for MySQL membuat primary key implisit untuk setiap tabel tanpa primary key.

Lihat primary key implisit

Anda dapat login ke kluster dan menjalankan SET show_ipk_info = 1. Kemudian, Anda dapat melihat kunci tersebut dengan menjalankan perintah SHOW CREATE TABLE.

-- Atur parameter untuk menampilkan primary key implisit.
SET show_ipk_info = 1;
-- Lihat skema tabel.
SHOW CREATE TABLE t;

Lihat skema tabel. 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 |
+-------+------------------------------------------------------------------------------------------------------------+

T: Mengapa saya melihat error Lock wait timeout exceeded dan menemukan transaksi dengan trx_mysql_thread_id bernilai 0?
J: Jika aplikasi Anda mengalami gangguan layanan akibat kontensi kunci saat berinteraksi dengan PolarDB for MySQL, dan Anda mengamati thread dengan thread_id bernilai 0 di database, biasanya berarti ada transaksi XA yang belum lengkap sedang memegang kunci. Bagian ini memandu Anda cara mengatasi masalah ini.
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 jangka panjang dalam output di mana nilai field trx_mysql_thread_id adalah 0. Transaksi ini memblokir transaksi lain.
```
MySQL xxx > select * from information_schema.innodb_trx\G
*************************** 1. row ***************************
                    trx_id: 3317965
                 trx_state: RUNNING
               trx_started: 2025-12-23 11:29:17
      trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 3
       trx_mysql_thread_id: 0
                 trx_query: NULL
```
Penyebab
Di mesin penyimpanan InnoDB, trx_mysql_thread_id bernilai 0 merupakan indikator transaksi XA. Masalah ini biasanya terjadi selama proses commit dua fase transaksi XA. Setelah transaksi berhasil menjalankan XA PREPARE dan memasuki status prepared, jika manajer transaksi eksternal gagal mengeluarkan perintah XA COMMIT atau XA ROLLBACK karena masalah jaringan, pengecualian aplikasi, atau alasan lain, transaksi tersebut terjebak dalam status prepared. Transaksi yang terjebak ini terus memegang kunci, memblokir transaksi lain, dan akhirnya menyebabkan timeout tunggu kunci.
Solusi
Anda perlu melakukan intervensi manual untuk melakukan commit atau rollback transaksi XA yang prepared berdasarkan kebutuhan bisnis Anda.
1. Temukan transaksi XA yang belum dikomit: Jalankan perintah XA RECOVER; untuk mencari transaksi XA yang belum dikomit. Catat nilai field formatID, gtrid_length, bqual_length, dan data untuk transaksi target. Informasi ini sangat penting untuk langkah berikutnya.
```
MySQL [xxx]> xa recover;
+----------+---------------+--------------+----------------------------+
| formatID | gtrid_length  | bqual_length | data                       |
+----------+---------------+--------------+----------------------------+
|    10000 |            11 |           14 | 192.168.1.2_app_name_test  |
+----------+---------------+--------------+----------------------------+
```
2. Lakukan commit atau rollback transaksi XA secara manual: Setelah menemukan transaksi XA, Anda dapat memilih untuk melakukan commit atau rollback berdasarkan kebutuhan bisnis Anda.
  1. Dapatkan identifier unik (xid) transaksi XA: xid terdiri dari tiga bagian: gtrid, bqual, dan formatID. Anda perlu menyusun xid berdasarkan informasi yang diperoleh pada langkah sebelumnya.
    gtrid: String dengan panjang yang ditentukan oleh gtrid_length, diambil dari awal field data.
    bqual: String dengan panjang yang ditentukan oleh bqual_length, diambil dari akhir field data.
    formatID: Nilai field formatID.
    Berdasarkan contoh pada langkah sebelumnya, Anda dapat menyusun tiga bagian xid. Anda dapat menggunakan 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 menghasilkan status akhir yang berbeda dari niat asli koordinator transaksi, yang dapat menyebabkan inkonsistensi data. Sebelum menjalankan perintah berikut, pastikan Anda sepenuhnya memahami konteks bisnis transaksi tersebut dan memastikan aman untuk dilanjutkan.
    Commit: Jika Anda menentukan bahwa transaksi harus dikomit, jalankan perintah berikut:
    XA COMMIT '192.168.1.2', '_app_name_test', 10000;
    Rollback: Jika Anda menentukan bahwa transaksi harus di-rollback, jalankan perintah berikut:
    XA ROLLBACK '192.168.1.2', '_app_name_test', 10000;
3. Setelah perintah berhasil dijalankan, 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 resmi MySQL tentang Transaksi 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 masalah: Kluster PolarDB for MySQL 8.0 tersedia dalam dua versi, MySQL 8.0.1 dan MySQL 8.0.2, yang sepenuhnya kompatibel dengan MySQL 8.0.13 dan MySQL 8.0.18, masing-masing. Namun, kedua versi ini menangani tipe tanggal dan waktu yang tidak valid secara tidak konsisten.
  Secara khusus, saat literal string dibandingkan dengan nilai bertipe waktu, sistem mencoba mengonversi string tersebut ke tipe waktu. Jika string tersebut merupakan tanggal yang tidak valid, konversi gagal. Perilaku saat kegagalan konversi berbeda antara kedua versi tersebut. Versi yang kompatibel dengan 8.0.13 hanya mengeluarkan WARNING, sedangkan versi yang kompatibel dengan 8.0.18 mengembalikan error ER_WRONG_VALUE. Akibatnya, saat membandingkan tanggal tidak valid dan field waktu, kedua versi kluster PolarDB for MySQL ini menunjukkan perilaku pelaporan error yang tidak konsisten.
- Solusi: Untuk memastikan hasil eksekusi SQL yang konsisten (semua berhasil atau semua gagal), beberapa kluster PolarDB for MySQL harus menggunakan versi kernel utama yang sama, baik semuanya MySQL 8.0.1 atau semuanya MySQL 8.0.2.

Cadangan dan pemulihan

T: Bagaimana PolarDB melakukan backup data?
J: PolarDB menggunakan snapshot untuk melakukan backup data. Untuk informasi lebih lanjut, lihat Metode backup 1: Backup otomatis dan Metode backup 2: Backup manual, , atau .
T: Seberapa cepat database dapat dipulihkan?
J: Memulihkan database dari set cadangan (snapshot) atau mengkloning database membutuhkan waktu sekitar 40 menit per TB. Jika Anda memulihkan data ke titik waktu tertentu, waktu yang diperlukan untuk menerapkan redo log juga termasuk. Menerapkan redo log membutuhkan waktu sekitar 20 hingga 70 detik per GB. Waktu pemulihan total adalah jumlah dari kedua bagian tersebut.

Kinerja dan kapasitas

T: Mengapa kinerja PolarDB for MySQL tidak jauh lebih baik daripada ApsaraDB RDS for MySQL?
J: Untuk mendapatkan perbandingan kinerja yang akurat antara PolarDB for MySQL dan ApsaraDB RDS for MySQL, pertimbangkan poin-poin berikut.
- Gunakan kluster PolarDB for MySQL dan instans ApsaraDB RDS for MySQL dengan spesifikasi yang sama.
- Gunakan kluster PolarDB for MySQL dan instans ApsaraDB RDS for MySQL yang menjalankan versi MySQL yang sama.
  Mekanisme implementasi bervariasi berdasarkan versi. Misalnya, MySQL 8.0 dioptimalkan untuk CPU multi-core dengan thread abstrak seperti Log_writer, log_fluser, log_checkpoint, dan log_write_notifier. Namun, kinerjanya pada sistem dengan core CPU lebih sedikit lebih rendah daripada MySQL 5.6 atau 5.7. Kami tidak menyarankan membandingkan PolarDB for MySQL 5.6 dengan ApsaraDB RDS for MySQL 5.7 atau 8.0 karena pengoptimal di MySQL 5.6 lebih lama dan kurang efisien dibandingkan versi yang lebih baru.
- Simulasikan skenario tekanan online untuk perbandingan kinerja yang realistis atau gunakan sysbench untuk pengujian. Data yang diperoleh dari metode ini lebih mendekati skenario online dunia nyata.
- Saat membandingkan kinerja baca, kami tidak menyarankan menggunakan pernyataan SQL tunggal.
  Karena PolarDB memiliki arsitektur komputasi dan penyimpanan yang terpisah, pernyataan tunggal dipengaruhi oleh latensi jaringan, yang dapat mengakibatkan kinerja baca lebih rendah dibandingkan ApsaraDB RDS for MySQL. Di database online, tingkat hit cache biasanya di atas 99%. Hanya operasi baca pertama yang melibatkan panggilan I/O, yang mengurangi kinerja baca. Data selanjutnya diambil dari buffer pool, yang tidak memerlukan panggilan I/O. Oleh karena itu, kinerjanya sama.
- Saat membandingkan kinerja tulis, kami juga tidak menyarankan menggunakan pernyataan SQL tunggal. Kami menyarankan agar Anda mensimulasikan lingkungan online untuk uji stres.
  Untuk membandingkan kinerja dengan ApsaraDB RDS for MySQL, gunakan kluster PolarDB dengan node utama dan node read-only, dan bandingkan dengan instans ApsaraDB RDS for MySQL yang memiliki instans utama dan instans read-only semi-sinkron. Hal ini karena arsitektur PolarDB secara default menggunakan mekanisme kuorum untuk penulisan data. Artinya, operasi tulis dianggap berhasil jika ditulis ke mayoritas dari tiga replika (dua atau lebih). PolarDB menyediakan redundansi data di lapisan penyimpanan dan memastikan konsistensi kuat serta keandalan tinggi dengan tiga replika. Oleh karena itu, perbandingan yang lebih masuk akal adalah menggunakan replikasi semi-sinkron di ApsaraDB RDS for MySQL, bukan replikasi asinkron.
Untuk perbandingan kinerja antara PolarDB for MySQL dan ApsaraDB RDS for MySQL, lihat Perbandingan kinerja: PolarDB for MySQL vs. ApsaraDB RDS for MySQL.
T: Berapa jumlah maksimum tabel? Pada titik mana kinerja mungkin menurun?
J: Jumlah maksimum tabel dibatasi oleh jumlah file. Untuk informasi lebih lanjut, lihat Batas, , atau .
T: Apakah partisi tabel dapat meningkatkan kinerja kueri PolarDB?
J: Umumnya, ya. Jika kueri dapat dibatasi pada partisi tertentu, kinerja dapat ditingkatkan.
T: Bisakah saya membuat 10.000 database dalam kluster PolarDB? Berapa jumlah maksimum database?
J: Ya, Anda dapat membuat 10.000 database dalam kluster PolarDB. Jumlah maksimum database dibatasi oleh jumlah file. Untuk informasi lebih lanjut, lihat Batas, , atau .
T: Apakah jumlah maksimum koneksi terkait dengan jumlah node read-only? Bisakah saya meningkatkan jumlah maksimum koneksi dengan menambahkan node read-only?
J: Tidak, jumlah node read-only tidak terkait dengan jumlah maksimum koneksi. Jumlah maksimum koneksi di PolarDB ditentukan oleh spesifikasi node. Untuk informasi lebih lanjut, lihat Batas. Jika Anda memerlukan lebih banyak koneksi, Anda harus meningkatkan spesifikasi.
T: Bagaimana IOPS dibatasi dan diisolasi? Bisakah terjadi kontensi I/O antara beberapa node kluster PolarDB?
J: Di kluster PolarDB, setiap node memiliki batas IOPS berdasarkan spesifikasinya. IOPS setiap node diisolasi dan tidak memengaruhi node lain.
T: Bisakah kinerja node read-only yang lambat memengaruhi node utama?
J: Ya. Jika node read-only memiliki beban tinggi atau latensi replikasi meningkat, hal ini mungkin sedikit meningkatkan konsumsi memori node utama.
T: Apa dampak kinerja dari mengaktifkan binlog?
J: Mengaktifkan binlog tidak memengaruhi kinerja kueri (SELECT), tetapi memengaruhi operasi tulis (INSERT, UPDATE, DELETE). Di database dengan beban baca-tulis seimbang, mengaktifkan binlog biasanya berdampak kurang dari 10% pada kinerja.
T: Apa dampak kinerja dari mengaktifkan SQL Explorer?
J: Tidak ada dampak pada kinerja.
T: Protokol jaringan berkecepatan tinggi apa yang digunakan PolarDB?
J: PolarDB menggunakan teknologi RDMA dual 25 Gbps untuk komunikasi antara node komputasi dan penyimpanan, serta antara replika data penyimpanan. Hal ini memberikan kinerja I/O yang kuat dengan latensi rendah dan throughput tinggi.
T: Berapa bandwidth maksimum untuk koneksi eksternal ke PolarDB?
J: Bandwidth maksimum untuk koneksi eksternal ke PolarDB adalah 10 Gbit/s.

Tabel besar

T: Apa keuntungan menyimpan tabel besar di PolarDB for MySQL dibandingkan database tradisional yang menggunakan disk lokal?
J: Di PolarDB for MySQL, satu tabel secara fisik dibagi dan disimpan di beberapa server penyimpanan. Akibatnya, operasi I/O pada tabel tersebut didistribusikan di beberapa disk penyimpanan. Throughput baca I/O keseluruhan, meskipun bukan latensi I/O-nya, jauh lebih baik daripada database terpusat yang menggunakan disk lokal.
T: Bagaimana cara mengoptimalkan tabel besar?
J: Kami menyarankan agar Anda menggunakan tabel partisi.
T: Kapan sebaiknya menggunakan tabel partisi?
J: Tabel partisi cocok untuk skenario di mana Anda perlu memangkas tabel besar untuk mengontrol jumlah data yang diakses oleh kueri, dan Anda ingin pemangkasan ini transparan bagi kode bisnis Anda tanpa memerlukan modifikasi. Misalnya, Anda dapat menggunakan tabel partisi untuk membersihkan data bisnis historis secara berkala, seperti dengan menghapus partisi bulan terlama dan membuat partisi baru untuk bulan berikutnya guna menyimpan hanya data enam bulan terakhir.
T: Apa cara terbaik untuk menyalin tabel yang sangat besar (misalnya, menyalin tabel A ke tabel B) dalam database PolarDB for MySQL yang sama?
J: Anda dapat menggunakan pernyataan SQL berikut untuk menyalin tabel secara langsung:
```
CREATE TABLE B AS SELECT * FROM A;
```

Stabilitas

T: Bisakah saya mengoptimalkan koneksi singkat PHP dalam skenario konkurensi tinggi?
J: Ya. Anda dapat mengoptimalkannya dengan mengaktifkan pool koneksi tingkat sesi di pengaturan titik akhir kluster. Untuk informasi lebih lanjut, lihat Konfigurasikan titik akhir kluster, , atau .
T: Bagaimana cara mencegah beberapa kueri SQL yang tidak efisien menurunkan seluruh database?
J: Jika kluster PolarDB for MySQL Anda versi 5.6 atau 8.0, Anda dapat menggunakan fitur Kontrol konkurensi untuk menerapkan pembatasan laju pada pernyataan tertentu.
T: Apakah PolarDB mendukung timeout sesi idle?
J: Ya. Anda dapat menyesuaikan timeout untuk sesi idle dengan memodifikasi parameter wait_timeout. Untuk langkah-langkah detail, lihat Tentukan parameter kluster dan node.

T: Bagaimana cara menemukan kueri SQL lambat?

J: Anda dapat menemukan kueri SQL lambat dengan dua cara berikut:

Kueri langsung log SQL lambat di konsol. Untuk informasi lebih lanjut, lihat Kueri SQL lambat.

Terhubung ke kluster database dan jalankan SHOW PROCESSLIST; untuk mengidentifikasi kueri yang membutuhkan waktu lama untuk dieksekusi. Untuk informasi lebih lanjut tentang cara terhubung ke kluster database, lihat Terhubung ke kluster database. Jalankan perintah SHOW PROCESSLIST untuk melihat daftar proses saat ini. Dalam contoh, kueri SELECT SLEEP(600) dengan Id 33554499 telah berjalan selama 250 detik, yang merupakan kueri SQL lambat.

mysql> show processlist;
+----------+------+-------------------------------+------+---------+------+------------+--------------------+
| Id       | User | Host                          | db   | Command | Time | State      | Info               |
+----------+------+-------------------------------+------+---------+------+------------+--------------------+
| 33554490 | acc  | xxx:19358                     | NULL | Query   |    0 | starting   | show processlist   |
| 33554499 | acc  | xxx                           | NULL | Query   |  250 | User sleep | select sleep(600)  |
| 33554499 | acc  | xxx                           | NULL | Sleep   |  253 |            | NULL               |
+----------+------+-------------------------------+------+---------+------+------------+--------------------+
3 rows in set, 13312 warnings (0.00 sec)

T: Bagaimana cara menghentikan kueri SQL lambat?
J: Setelah mengidentifikasi kueri SQL lambat, Anda dapat menemukan ID-nya lalu menjalankan KILL <Id> untuk menghentikannya.
```
mysql> KILL 33554499;
Query OK, 0 rows affected (0.01 sec)
```

Manajemen siklus hidup data

T: Bagaimana kluster PolarDB for MySQL mengarsipkan data hot dan warm sebagai data dingin?
J: Kluster PolarDB for MySQL dapat mengarsipkan data hot dari engine InnoDB dan data warm dari X-Engine di PolarStore ke Object Storage Service (OSS) sebagai data dingin dalam format CSV atau ORC menggunakan kebijakan DDL. Pengarsipan ini secara efektif melepaskan ruang penyimpanan di PolarStore dan mengurangi biaya penyimpanan database secara keseluruhan. Untuk informasi lebih lanjut, lihat Arsipkan data dingin secara manual.
T: Apakah kluster PolarDB for MySQL mendukung pemisahan dan pengarsipan otomatis data hot, warm, dan dingin? Bagaimana implementasinya?
J: PolarDB for MySQL mendukung pemisahan dan pengarsipan otomatis data hot, warm, dan dingin. Dengan menentukan kebijakan DLM, Anda dapat secara otomatis mengarsipkan data dari PolarStore ke penyimpanan OSS berbiaya rendah untuk mengurangi dan mengoptimalkan biaya penyimpanan database. Untuk informasi lebih lanjut, lihat Arsipkan data dingin secara otomatis.