FAQ tentang mesin PolarDB - PolarDB

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

Pertanyaan dasar

T: Apa itu PolarDB?
J: PolarDB adalah layanan database relasional cloud yang diimplementasikan di pusat data di lebih dari 10 wilayah di seluruh dunia. Layanan ini menyediakan database online siap pakai. PolarDB mendukung tiga mesin independen, sehingga sepenuhnya kompatibel dengan MySQL dan PostgreSQL, serta sangat kompatibel dengan sintaks Oracle. Satu kluster PolarDB menyediakan kapasitas penyimpanan hingga 200 TB. Untuk informasi lebih lanjut, lihat Apa itu PolarDB for MySQL Enterprise Edition?.
T: Mengapa database cloud-native PolarDB memiliki kinerja lebih baik dibandingkan database tradisional?
J: Dibandingkan dengan database tradisional, database cloud-native PolarDB dapat menyimpan ratusan terabyte data dan menyediakan berbagai fitur seperti ketersediaan tinggi, keandalan tinggi, peningkatan dan penurunan spesifikasi elastis yang cepat, serta backup tanpa kunci. Untuk informasi lebih lanjut, lihat Manfaat.
T: Kapan PolarDB dirilis? Kapan tersedia untuk penggunaan komersial?
J: PolarDB dirilis dalam pratinjau publik pada September 2017 dan tersedia untuk penggunaan komersial pada Maret 2018.
T: Apa itu kluster dan node?
J: PolarDB Cluster Edition menggunakan arsitektur kluster multi-node. Sebuah kluster memiliki satu node utama dan beberapa node hanya baca. Satu kluster PolarDB dapat diterapkan lintas zona tetapi tidak lintas wilayah. Layanan PolarDB dikelola dan ditagih berdasarkan tingkat kluster. Untuk informasi lebih lanjut, lihat Glosarium.
T: Bahasa pemrograman apa saja yang didukung oleh PolarDB?
J: PolarDB mendukung bahasa pemrograman termasuk Java, Python, PHP, Go, C, C++, .NET, dan Node.js. Bahasa pemrograman yang dapat berinteraksi dengan MySQL native juga dapat berinteraksi dengan PolarDB for MySQL. Untuk informasi lebih lanjut, kunjungi situs resmi MySQL.
T: Mesin penyimpanan apa saja yang didukung oleh PolarDB?
J: PolarDB memiliki dua edisi. Mesin penyimpanan yang tersedia berbeda-beda tergantung edisinya.
PolarDB for MySQL Cluster Edition secara eksklusif 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 mesin InnoDB. Oleh karena itu, tabel data yang sebelumnya tidak menggunakan InnoDB tetap dapat dimigrasikan ke PolarDB for MySQL.
T: Apakah PolarDB merupakan database terdistribusi?
J: Ya, benar. PolarDB adalah kluster penyimpanan terdistribusi berbasis protokol konsensus Parallel Raft. Mesin komputasinya terdiri dari 1 hingga 16 node komputasi yang tersebar di server berbeda. Kluster ini menyediakan kapasitas penyimpanan maksimum hingga 200 TB serta maksimal 88 core CPU dan memori 710 GB. Kluster ini memungkinkan penskalaan dinamis daring untuk sumber daya penyimpanan dan komputasi, sehingga memastikan operasi bisnis normal tidak terganggu selama proses penskalaan.
T: Setelah saya membeli PolarDB, apakah saya perlu membeli middleware database PolarDB-X untuk menerapkan sharding?
J: Ya, benar.
T: Apakah PolarDB mendukung partisi tabel?
J: Ya, benar.
T: Setelah saya membeli kluster PolarDB, bisakah saya mengubah wilayahnya?
J: Tidak, tidak bisa. Anda tidak dapat mengubah wilayah kluster setelah membelinya.
T: Apakah PolarDB memiliki mekanisme partisi default?
J: PolarDB menerapkan partisi di lapisan penyimpanan, yang transparan bagi pengguna.
T: Bagaimana kluster single-node menjamin ketersediaan layanan dan keandalan data?
J: Kluster single-node dirancang untuk menjalankan satu node komputasi untuk tujuan tertentu. Meskipun hanya memiliki satu node, kluster single-node menggunakan teknologi seperti penjadwalan komputasi tingkat detik dan penyimpanan multi-replika terdistribusi untuk menjamin ketersediaan layanan dan keandalan data yang tinggi.
T: Bagaimana cara membeli kluster PolarDB single-node?
J: Kluster single-node tidak lagi dijual. Namun, Anda dapat membuat kluster PolarDB single-node dengan mengatur jumlah node hanya baca menjadi 0 pada bagian Number Of Nodes saat membeli kluster.

Kompatibilitas

T: Apakah PolarDB for MySQL kompatibel dengan MySQL Community Edition?
J: Ya, PolarDB for MySQL sepenuhnya kompatibel 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. Layanan ini tidak mendukung tingkat isolasi SERIALIZABLE.
T: Apakah hasil kueri pernyataan SHOW PROCESSLIST di PolarDB for MySQL sama dengan di MySQL Community Edition?
J: Jika Anda menggunakan titik akhir utama untuk mengeksekusi pernyataan SHOW PROCESSLIST, hasil kuerinya sama. Jika Anda menggunakan titik akhir kluster untuk mengeksekusi pernyataan SHOW PROCESSLIST, hasil kuerinya berbeda. Dalam hasil kueri pernyataan tersebut di kluster PolarDB for MySQL, Anda akan menemukan beberapa catatan yang memiliki ID thread yang sama. Setiap catatan tersebut berkorespondensi dengan satu node dalam kluster.
T: Apakah mekanisme metadata lock (MDL) pada PolarDB for MySQL sama dengan MySQL Community Edition?
J: Mekanisme metadata lock (MDL) pada PolarDB for MySQL sama dengan MySQL Community Edition. Namun, node database PolarDB for MySQL berbasis arsitektur penyimpanan bersama. Artinya, ketika operasi bahasa definisi data (DDL) dilakukan pada node utama, node hanya baca mungkin mengakses data antara dari operasi DDL tersebut, yang dapat menyebabkan inkonsistensi data. Untuk mencegah hal ini, PolarDB for MySQL menggunakan log redo untuk menyinkronkan MDL eksklusif yang terlibat dalam operasi DDL ke node hanya baca. Hal ini mencegah thread pengguna lain di node hanya baca mengakses data tabel selama operasi DDL berlangsung. Dalam skenario tertentu, hal ini dapat memblokir operasi DDL. Anda dapat mengeksekusi perintah show processlist untuk melihat status operasi DDL. Jika operasi DDL berada dalam status Wait for syncing with replicas, ini menunjukkan bahwa pemblokiran tersebut telah terjadi. Untuk informasi tentang cara mengatasi masalah ini, lihat Melihat status eksekusi DDL dan status MDL.
T: Apakah format binary logging PolarDB for MySQL sama dengan format binary logging native MySQL?
J: Tidak ada perbedaan.
T: Apakah PolarDB mendukung performance schema dan sys schema?
J: Ya, mendukung.
T: Apakah PolarDB for MySQL menggunakan mekanisme pengumpulan statistik tabel yang sama dengan MySQL Community Edition?
J: Statistik tabel pada node utama di PolarDB for MySQL konsisten dengan MySQL Community Edition. Untuk memastikan rencana eksekusi konsisten antara node utama dan node hanya baca, setiap pembaruan statistik tabel pada node utama disinkronkan ke node hanya baca. Anda juga dapat mengeksekusi operasi ANALYZE TABLE pada node hanya baca untuk memuat statistik terbaru dari disk secara proaktif.
T: Apakah PolarDB mendukung transaksi XA? Apakah berbeda dengan MySQL resmi?
J: Ya, mendukung. Tidak ada perbedaan.
T: Apakah PolarDB mendukung indeks teks penuh?
J: Ya, mendukung.
Catatan
Saat ini, saat Anda menggunakan indeks teks penuh, terdapat latensi data pada cache indeks di node hanya baca. Kami merekomendasikan Anda menggunakan titik akhir utama untuk operasi baca dan tulis yang melibatkan indeks teks penuh agar membaca data terbaru.
T: Apakah Percona Toolkit didukung?
J: Ya, didukung, tetapi kami merekomendasikan Anda menggunakan DDL online.
T: Apakah gh-ost didukung?
J: Ya, didukung, tetapi kami merekomendasikan Anda menggunakan DDL online.

Penagihan

T: Apa saja item yang dapat ditagih dari kluster PolarDB?
J: Item yang dapat ditagih mencakup ruang penyimpanan, node komputasi, backup (dengan kuota gratis), dan SQL Explorer (opsional). Untuk informasi lebih lanjut, lihat Item yang dapat ditagih.
T: File apa saja yang disimpan dalam ruang penyimpanan yang dapat ditagih?
J: Ruang penyimpanan yang dapat ditagih menyimpan file tabel database, file indeks, file undo log, file redo log, file log biner, file log lambat, dan sejumlah kecil file sistem. Untuk informasi lebih lanjut, lihat Ikhtisar.
T: Bagaimana cara menggunakan paket penyimpanan untuk PolarDB?
J: Anda dapat menggunakan paket penyimpanan untuk mengimbangi biaya penyimpanan kluster langganan atau bayar sesuai pemakaian. Misalnya, jika Anda memiliki tiga kluster dengan kapasitas penyimpanan masing-masing 40 GB, total kapasitasnya adalah 120 GB. Anda dapat menggunakan paket penyimpanan 100 GB untuk ketiga kluster tersebut. Selanjutnya, Anda dikenai biaya untuk kelebihan 20 GB penyimpanan berdasarkan tarif bayar sesuai pemakaian. Untuk informasi lebih lanjut, lihat Membeli paket penyimpanan.
T: Bagaimana saya dikenai biaya jika menambahkan node hanya baca ke kluster?
J: Harga node hanya baca sama dengan harga node utama. Untuk informasi lebih lanjut, lihat Rincian harga untuk node komputasi.
T: Apakah kapasitas penyimpanan menjadi dua kali lipat setelah saya menambahkan node hanya baca?
J: Tidak, tidak menjadi dua kali lipat. PolarDB menggunakan arsitektur komputasi-penyimpanan terpisah. Node hanya baca yang Anda beli adalah sumber daya komputasi. Oleh karena itu, kapasitas penyimpanan tidak bertambah.
Ruang penyimpanan bersifat serverless. Anda tidak perlu memilih kapasitas saat membeli kluster. Kapasitas penyimpanan secara otomatis diskalakan seiring pertumbuhan data Anda. Anda hanya dikenai biaya berdasarkan jumlah data aktual yang digunakan. Setiap spesifikasi kluster memiliki batas kapasitas penyimpanan maksimum yang sesuai. Untuk meningkatkan batas kapasitas penyimpanan, Anda dapat meningkatkan spesifikasi kluster.
T: Bagaimana cara menghentikan penagihan untuk kluster bayar sesuai pemakaian?
J: Jika Anda tidak lagi memerlukan kluster tersebut, Anda dapat melepaskan kluster. Setelah kluster dilepaskan, tidak akan ada biaya tambahan yang dibebankan.
T: Bisakah saya mengubah spesifikasi kluster selama peningkatan sementara?
J: Selama peningkatan sementara (saat kluster dalam keadaan berjalan), Anda dapat meningkatkan spesifikasi secara manual. Namun, Anda tidak dapat menurunkan spesifikasi secara manual, mengaktifkan perubahan spesifikasi otomatis, atau menambah atau menghapus node.
T: Berapa bandwidth publik PolarDB? Apakah ada biaya?
J: PolarDB sendiri tidak memiliki batas bandwidth publik. Batas tersebut bergantung pada bandwidth layanan SLB yang Anda gunakan. Anda tidak dikenai biaya untuk koneksi publik PolarDB.
T: Mengapa biaya masih dibebankan setiap hari untuk kluster langganan?
J: Item yang dapat ditagih dari PolarDB terutama mencakup node komputasi (node utama dan node hanya baca), ruang penyimpanan, 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 berarti Anda membayar di muka biaya untuk node komputasi kluster saat membuatnya. Biaya untuk ruang penyimpanan, backup data, dan SQL Explorer tidak termasuk. Selama penggunaan database aktual, sejumlah biaya penyimpanan tertentu dipotong dari akun Anda setiap jam berdasarkan ruang penyimpanan yang digunakan oleh kluster. Oleh karena itu, tagihan bayar sesuai pemakaian tetap dihasilkan untuk kluster langganan.
T: Apakah saya dikenai biaya tambahan untuk migrasi instans RDS ke PolarDB dengan sekali klik?
J: Proses migrasi sekali klik gratis. Anda hanya dikenai biaya untuk instans RDS dan kluster PolarDB itu sendiri.
T: Mengapa saya masih dikenai biaya untuk ruang penyimpanan setelah menghapus data tabel di PolarDB menggunakan perintah delete?
J: Perintah delete hanya menandai tabel sebagai dihapus. Perintah ini tidak melepaskan ruang tabel.

Akses Kluster (pemisahan baca/tulis)

T: Bagaimana cara menerapkan pemisahan baca/tulis di PolarDB?
J: Anda cukup menggunakan titik akhir kluster di aplikasi Anda. Pemisahan baca/tulis kemudian diterapkan berdasarkan mode baca/tulis yang dikonfigurasi. Untuk informasi lebih lanjut, lihat Mengonfigurasi proksi database.
T: Berapa banyak node hanya baca yang dapat didukung oleh kluster PolarDB?
J: PolarDB menggunakan arsitektur kluster terdistribusi. Sebuah kluster berisi satu node utama dan hingga 15 node hanya baca. Diperlukan minimal satu node hanya baca untuk memastikan ketersediaan tinggi.
T: Mengapa beban tidak seimbang di antara node hanya baca?
J: Beban mungkin tidak seimbang di antara node hanya baca karena jumlah koneksi ke node hanya baca sedikit atau node hanya baca tidak termasuk saat titik akhir kluster kustom dialokasikan.
T: Apa penyebab beban tinggi atau rendah pada node utama?
J: Beban tinggi pada node utama dapat disebabkan oleh beberapa faktor: koneksi langsung ke titik akhir utama, node utama menerima permintaan baca, banyak permintaan transaksi, latensi replikasi primer/sekunder tinggi yang menyebabkan permintaan diarahkan ke node utama, atau pengecualian node hanya baca yang menyebabkan permintaan baca diarahkan ke node utama.
Beban rendah pada node utama dapat terjadi karena opsi mengalihkan bacaan dari node utama diaktifkan.
T: Bagaimana cara mengurangi beban pada node utama?
J: Anda dapat menggunakan metode berikut untuk mengurangi beban pada node utama:
- Gunakan titik akhir kluster untuk menghubungkan ke kluster PolarDB. Untuk informasi lebih lanjut, lihat Mengonfigurasi proksi database.
- Jika banyak transaksi menyebabkan tekanan tinggi pada node utama, Anda dapat mengaktifkan fitur pemisahan transaksi di konsol. Fitur ini mengarahkan beberapa kueri dalam transaksi ke node hanya baca. Untuk informasi lebih lanjut, lihat Pemisahan transaksi.
- Jika permintaan diarahkan ke node utama karena latensi replikasi, Anda dapat mempertimbangkan untuk menurunkan tingkat konsistensi. Misalnya, Anda dapat menggunakan konsistensi akhir. Untuk informasi lebih lanjut, lihat Tingkat konsistensi.
- Jika node utama menerima permintaan baca, beban pada node utama mungkin tinggi. 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.
T: Mengapa saya tidak dapat membaca data yang baru saja saya masukkan?
J: Masalah ini mungkin disebabkan oleh konfigurasi tingkat konsistensi. Titik akhir kluster PolarDB mendukung tingkat konsistensi berikut:
- Konsistensi akhir: Terlepas dari apakah sesi (koneksi) tersebut sama atau berbeda, konsistensi akhir tidak menjamin bahwa Anda dapat langsung membaca data yang baru dimasukkan.
- Konsistensi sesi: Anda selalu dapat membaca data yang dimasukkan dalam sesi yang sama.
- Konsistensi global: Anda selalu dapat membaca data terbaru baik dalam sesi yang sama maupun sesi berbeda.
Catatan
Semakin tinggi tingkat konsistensi, semakin buruk kinerjanya dan semakin besar tekanan pada node utama. Pilih tingkat konsistensi dengan hati-hati. Untuk sebagian besar skenario aplikasi, konsistensi sesi dapat memastikan bisnis Anda berjalan sesuai harapan. Untuk beberapa pernyataan yang memiliki persyaratan konsistensi kuat, Anda dapat menggunakan petunjuk /* FORCE_MASTER */. Untuk informasi lebih lanjut, lihat Tingkat konsistensi.
T: Bagaimana cara memaksa pernyataan SQL dieksekusi di node utama?
J: Saat Anda menggunakan titik akhir kluster, Anda dapat menambahkan /* FORCE_MASTER */ atau /* FORCE_SLAVE */ sebelum pernyataan SQL untuk memaksa arah peruteannya. Untuk informasi lebih lanjut, lihat Sintaks Hint.
- /* FORCE_MASTER */ memaksa permintaan diarahkan ke node utama. Ini dapat digunakan untuk menangani beberapa permintaan baca yang memiliki persyaratan konsistensi tinggi.
- /* FORCE_SLAVE */ memaksa permintaan diarahkan ke node hanya baca. Ini dapat digunakan untuk menangani beberapa skenario di mana proksi PolarDB memerlukan sintaks khusus untuk diarahkan ke node hanya baca guna memastikan kebenaran. Misalnya, pernyataan yang memanggil prosedur tersimpan dan menggunakan multistatement secara default diarahkan ke node utama.
Catatan
- Hint memiliki prioritas perutean tertinggi dan tidak tunduk pada batasan tingkat konsistensi dan pemisahan transaksi. Evaluasi dampaknya sebelum menggunakan hint.
- Jangan menyertakan pernyataan yang memodifikasi parameter GUC dalam hint, seperti /*FORCE_SLAVE*/ set enable_hashjoin = off;. Pernyataan semacam itu dapat menyebabkan hasil kueri yang tidak terduga.
T: Bisakah saya menetapkan titik akhir berbeda untuk layanan berbeda? Bisakah layanan diisolasi menggunakan titik akhir berbeda?
J: Anda dapat membuat beberapa titik akhir kustom untuk layanan berbeda. Jika node dasarnya berbeda, titik akhir kustom tersebut juga dapat memberikan efek isolasi dan tidak saling memengaruhi. Untuk informasi lebih lanjut tentang cara membuat titik akhir kustom, lihat Menambahkan titik akhir kluster kustom.
T: Jika terdapat beberapa node hanya baca, bagaimana cara membuat titik akhir node tunggal terpisah untuk salah satunya?
J: Anda hanya dapat membuat titik akhir node tunggal ketika mode baca/tulis titik akhir kluster adalah Hanya baca dan kluster memiliki tiga node atau lebih. Untuk informasi lebih lanjut, lihat Mengatur titik akhir kluster.
Peringatan
Setelah Anda membuat titik akhir node tunggal, jika node tersebut gagal, titik akhir mungkin tidak tersedia hingga 1 jam. Jangan menggunakannya di lingkungan produksi.
T: Berapa jumlah maksimum titik akhir node tunggal yang dapat dibuat dalam sebuah kluster?
J: Jika kluster Anda memiliki 3 node, Anda hanya dapat membuat titik akhir node tunggal untuk 1 node hanya baca. Jika kluster Anda memiliki 4 node, Anda dapat membuat titik akhir node tunggal untuk 2 node hanya baca. Aturan yang sama berlaku untuk jumlah node lainnya.
T: Saya hanya menggunakan titik akhir utama, tetapi saya menemukan bahwa node hanya baca juga memiliki beban. Apakah titik akhir utama juga mendukung pemisahan baca/tulis?
J: Titik akhir utama tidak mendukung pemisahan baca/tulis. Titik akhir ini selalu hanya terhubung ke node utama. Normal jika node hanya baca memiliki sejumlah kecil permintaan per detik (QPS). Hal ini tidak terkait dengan titik akhir utama.

Manajemen dan pemeliharaan

T: Bagaimana cara menambahkan kolom dan indeks secara online?
J: Anda dapat menggunakan alat seperti DDL online native, pt-osc, dan gh-ost. Kami merekomendasikan Anda menggunakan operasi DDL online native.
Catatan
Saat menggunakan alat pt-osc, jangan gunakan parameter untuk pengaturan deteksi primer/sekunder, seperti parameter recursion-method. Hal ini karena alat pt-osc melakukan deteksi primer/sekunder berdasarkan replikasi binary logging. Namun, PolarDB menggunakan replikasi fisik secara internal dan tidak memiliki informasi replikasi berdasarkan binary logging.
T: Apakah fitur bulk insert didukung?
J: Ya, benar.
T: Jika saya hanya menulis data ke node hanya tulis, apakah bulk insert didukung? Berapa jumlah maksimum nilai yang dapat dimasukkan sekaligus?
J: Ya, didukung. Jumlah maksimum nilai yang dapat dimasukkan 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 menggunakan titik akhir kluster?
J: Ya, bisa.
T: Apakah ada latensi replikasi antara node utama dan node hanya baca?
J: Ya, terdapat latensi tingkat milidetik di antara keduanya.
T: Dalam situasi apa latensi replikasi meningkat?
J: Latensi replikasi meningkat dalam situasi berikut:
- Beban tulis pada node utama tinggi, yang menghasilkan lebih banyak log redo daripada yang dapat diterapkan oleh node hanya baca tepat waktu.
- Beban pada node hanya baca terlalu tinggi, yang merebut sumber daya yang awalnya digunakan untuk menerapkan log redo.
- Terjadi bottleneck I/O, yang memperlambat pembacaan dan penulisan log redo.
T: Jika terdapat latensi replikasi, bagaimana cara memastikan konsistensi kueri?
J: Anda dapat menggunakan titik akhir kluster dan memilih tingkat konsistensi yang sesuai. Tingkat konsistensi saat ini dari tertinggi ke terendah adalah konsistensi global (konsistensi kuat), konsistensi sesi, dan konsistensi akhir. Untuk informasi lebih lanjut, lihat Tingkat konsistensi.
T: Apakah tujuan titik pemulihan (RPO) 0 dapat dijamin jika terjadi kegagalan satu node?
J: Ya, dapat dijamin.
T: Bagaimana peningkatan spesifikasi, seperti dari 2 core CPU dan memori 8 GB menjadi 4 core CPU dan memori 16 GB, diimplementasikan di backend? Apa dampaknya terhadap bisnis saya?
J: Proksi dan node database PolarDB ditingkatkan ke spesifikasi baru. Peningkatan bergulir pada beberapa node digunakan untuk meminimalkan dampak terhadap bisnis Anda. Saat ini, setiap peningkatan memakan waktu sekitar 10 hingga 15 menit, dan dampak terhadap bisnis Anda berlangsung tidak lebih dari 30 detik. Selama periode ini, terjadi satu hingga tiga koneksi transient. Untuk informasi lebih lanjut, lihat Mengubah spesifikasi secara manual.
T: Berapa lama waktu yang dibutuhkan untuk menambahkan node? Apakah memengaruhi bisnis saya?
J: Diperlukan waktu 5 menit untuk menambahkan node. Hal ini tidak memengaruhi bisnis Anda. Untuk informasi lebih lanjut tentang cara menambahkan node, lihat Menambahkan node hanya baca.
Catatan
Setelah node hanya baca baru ditambahkan, koneksi pemisahan baca/tulis baru meneruskan permintaan ke node hanya baca tersebut. Koneksi pemisahan baca/tulis yang sudah dibuat sebelum penambahan node hanya baca baru tidak meneruskan permintaan ke node hanya baca baru tersebut. Anda harus memutus dan membuat ulang koneksi. Misalnya, Anda dapat me-restart aplikasi.
T: Berapa lama waktu yang dibutuhkan untuk meningkatkan ke versi revisi terbaru? Apakah memengaruhi bisnis saya?
J: PolarDB menggunakan peningkatan bergulir pada beberapa node untuk meminimalkan dampak terhadap bisnis Anda. Peningkatan versi biasanya memakan waktu tidak lebih dari 30 menit. Selama peningkatan, proksi database atau mesin kernel DB direstart, yang dapat menyebabkan koneksi database transient. Kami merekomendasikan Anda melakukan peningkatan selama jam-jam tidak sibuk dan memastikan aplikasi Anda memiliki mekanisme koneksi ulang otomatis. Untuk informasi lebih lanjut, lihat Manajemen versi minor.
T: Bagaimana failover otomatis dilakukan?
J: PolarDB menggunakan arsitektur kluster ketersediaan tinggi aktif-aktif. Failover otomatis dilakukan antara node utama baca/tulis dan node hanya baca, di mana sistem secara otomatis memilih node utama baru. Setiap node di PolarDB memiliki prioritas failover, yang menentukan probabilitas terpilih sebagai node utama selama failover. Ketika beberapa node memiliki prioritas yang sama, mereka memiliki probabilitas yang sama untuk terpilih sebagai node utama. Untuk informasi lebih lanjut, lihat Failover primer/sekunder otomatis/manual.
T: Izin apa saja yang diperlukan untuk menghentikan koneksi di PolarDB for MySQL?
J: Di MySQL, Anda harus memiliki izin yang diperlukan 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 mereka sendiri. Tidak diperlukan izin tambahan.
- Menghentikan sesi lain dari pengguna yang sama: Diperlukan izin PROCESS.
- Menghentikan koneksi pengguna reguler lain: Di PolarDB for MySQL, akun istimewa harus menggunakan perintah KILL dengan hati-hati.
T: Pesan error [ERROR] InnoDB: fil_space_extend space_name:xxx muncul di log berjalan. Apakah ini memengaruhi bisnis saya?
J: Tidak, ini tidak memengaruhi bisnis Anda. Log ini menunjukkan bahwa setelah node baca/tulis kluster PolarDB memperluas ukuran file, node hanya baca menyinkronkan informasi ukuran file tersebut di memorinya. Untuk kluster yang menjalankan MySQL 5.7, tingkat log tidak disesuaikan dari ERROR. Oleh karena itu, ini dapat dianggap sebagai log tingkat INFO di node hanya baca dan tidak memengaruhi bisnis Anda.

Cadangan dan pemulihan

T: Metode pencadangan apa yang digunakan oleh PolarDB?
J: PolarDB menggunakan snapshot untuk mencadangkan data. Untuk informasi lebih lanjut, lihat Metode pencadangan 1: Pencadangan otomatis dan Metode pencadangan 2: Pencadangan manual.
T: Seberapa cepat database dapat dipulihkan?
J: Saat ini, diperlukan waktu 40 menit per TB untuk memulihkan (mengkloning) data dari set cadangan (snapshot). Jika Anda memulihkan data ke titik waktu tertentu, waktu yang diperlukan untuk menerapkan log redo juga termasuk. Bagian pemulihan ini memakan waktu sekitar 20 hingga 70 detik per GB. Waktu pemulihan total adalah jumlah kedua bagian tersebut.

Kinerja dan kapasitas

T: Mengapa kluster PolarDB for MySQL gagal menunjukkan peningkatan kinerja signifikan dibandingkan instans RDS for MySQL?
J: Sebelum membandingkan kinerja kluster PolarDB for MySQL dengan instans RDS for MySQL, perhatikan hal berikut untuk mendapatkan hasil perbandingan kinerja yang akurat dan masuk akal:
- Gunakan kluster PolarDB for MySQL dan instans RDS for MySQL dengan spesifikasi yang sama untuk perbandingan kinerja.
- Gunakan kluster PolarDB for MySQL dan instans RDS for MySQL dengan versi yang sama untuk perbandingan kinerja.
  Hal ini karena mekanisme implementasi berbeda-beda tergantung versinya. Misalnya, MySQL 8.0 dioptimalkan untuk CPU multi-core dengan mengabstraksi thread secara terpisah, seperti Log_writer, log_flusher, log_checkpoint, dan log_write_notifier. Namun, jika hanya menggunakan beberapa core CPU, kinerja MySQL 8.0 lebih rendah dibandingkan MySQL 5.6 atau 5.7. Kami tidak merekomendasikan Anda membandingkan PolarDB for MySQL 5.6 dengan RDS for MySQL 5.7 atau 8.0 karena pengoptimal MySQL 5.6 lebih lama dan tidak sebaik versi-versi berikutnya.
- Kami merekomendasikan Anda mensimulasikan beban di lingkungan online aktual atau menggunakan sysbench untuk membandingkan kinerja. Hal ini membuat data kinerja yang diperoleh lebih mendekati skenario online aktual.
- Saat membandingkan kinerja baca, kami tidak merekomendasikan Anda menggunakan satu pernyataan SQL.
  Hal ini karena PolarDB menggunakan arsitektur komputasi-penyimpanan terpisah. Satu pernyataan dipengaruhi oleh latensi jaringan, yang dapat menyebabkan kinerja baca lebih rendah dibandingkan RDS. Rasio hit cache untuk database online biasanya di atas 99%. Hanya pembacaan pertama yang memanggil I/O, yang mengurangi kinerja baca. Data selanjutnya berada di kolam buffer dan tidak memerlukan panggilan I/O. Oleh karena itu, kinerjanya sama.
- Saat membandingkan kinerja tulis, kami juga tidak merekomendasikan Anda menggunakan satu pernyataan SQL. Kami merekomendasikan Anda mensimulasikan lingkungan produksi dan melakukan uji stres.
  Untuk membandingkan dengan kinerja RDS, gunakan PolarDB (node utama + node hanya baca) dan RDS (instans utama + instans hanya baca semi-sinkron). Hal ini karena arsitektur PolarDB secara default menggunakan mekanisme Quorum untuk penulisan data. Artinya, saat data ditulis, data tersebut ditulis ke mayoritas dari tiga replika secara default. Jika data ditulis ke dua atau lebih dari tiga replika, operasi tulis dianggap berhasil. PolarDB sudah menyediakan redundansi data di lapisan penyimpanan dan memastikan sinkronisasi kuat serta keandalan tinggi dari tiga replika. Oleh karena itu, lebih masuk akal menggunakan replikasi semi-sinkron (bukan replikasi asinkron) RDS for MySQL untuk perbandingan.
Untuk informasi lebih lanjut tentang hasil perbandingan kinerja antara PolarDB for MySQL dan RDS for MySQL, lihat Perbandingan kinerja antara PolarDB for MySQL dan RDS for MySQL.
T: Berapa jumlah maksimum tabel? Pada jumlah berapa kinerja mulai menurun?
J: Jumlah maksimum tabel dibatasi oleh jumlah file. Untuk informasi lebih lanjut, lihat Batasan.
T: Apakah partisi tabel dapat meningkatkan kinerja kueri PolarDB?
J: Secara umum, jika kueri SQL dapat berada dalam partisi tertentu, kinerja dapat ditingkatkan.
T: Bisakah saya membuat 10.000 database dalam kluster PolarDB? Berapa jumlah maksimum database?
J: Anda dapat membuat 10.000 database dalam kluster PolarDB. Jumlah maksimum database dibatasi oleh jumlah file. Untuk informasi lebih lanjut, lihat Batasan.
T: Apakah jumlah node hanya baca terkait dengan jumlah maksimum koneksi? Bisakah saya meningkatkan jumlah maksimum koneksi dengan menambahkan node hanya baca?
J: Jumlah node hanya baca tidak terkait dengan jumlah maksimum koneksi. Jumlah maksimum koneksi untuk PolarDB ditentukan oleh spesifikasi node. Untuk informasi lebih lanjut, lihat Batasan. Untuk meningkatkan jumlah koneksi, Anda dapat meningkatkan spesifikasi.
T: Bagaimana IOPS dibatasi dan diisolasi? Apakah beberapa node kluster PolarDB bersaing untuk I/O?
J: IOPS untuk setiap node kluster PolarDB diatur berdasarkan spesifikasinya. IOPS setiap node diisolasi dan tidak memengaruhi node lain.
T: Apakah kinerja node hanya baca memengaruhi node utama jika melambat?
J: Jika beban pada node hanya baca terlalu tinggi dan latensi replikasi meningkat, konsumsi memori node utama mungkin sedikit meningkat.
T: Apa dampak terhadap kinerja setelah saya mengaktifkan binary logging?
J: Mengaktifkan binary logging tidak memengaruhi kinerja kueri (SELECT). Hanya memengaruhi kinerja tulis dan pembaruan (INSERT, UPDATE, dan DELETE). Secara umum, dalam database dengan baca dan tulis seimbang, mengaktifkan binary logging memengaruhi kinerja tidak lebih dari 10%.
T: Apa dampak terhadap kinerja setelah saya mengaktifkan SQL Explorer (audit log SQL lengkap)?
J: Tidak ada dampak.
T: Protokol jaringan berkecepatan tinggi apa yang digunakan oleh PolarDB?
J: PolarDB menggunakan teknologi RDMA ganda 25 Gbps antara node komputasi database dan node penyimpanan, serta antara replika data penyimpanan. Hal ini memberikan kinerja I/O yang kuat dengan latensi rendah dan throughput tinggi.
T: Berapa batas bandwidth untuk koneksi Internet ke PolarDB?
J: Batas bandwidth untuk koneksi Internet ke PolarDB adalah 10 Gbit/s.

Tabel besar

T: Dibandingkan dengan database tradisional yang menggunakan disk lokal, apa keuntungan menyimpan tabel besar di PolarDB for MySQL?
J: Sebuah tabel di PolarDB for MySQL secara fisik dibagi dan disimpan di N server penyimpanan. Oleh karena itu, I/O untuk sebuah tabel didistribusikan ke beberapa disk penyimpanan. Throughput baca I/O keseluruhan (bukan latensi I/O) jauh lebih baik dibandingkan database terpusat yang menggunakan disk lokal.
T: Bagaimana cara mengoptimalkan tabel besar?
J: Kami merekomendasikan Anda menggunakan tabel partisi.
T: Dalam situasi apa penggunaan tabel partisi cocok?
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 tersebut transparan terhadap kode bisnis tanpa memerlukan modifikasi apa pun. Misalnya, Anda dapat menggunakan tabel partisi untuk membersihkan data historis bisnis secara berkala. Anda dapat menghapus partisi untuk bulan paling awal dan membuat partisi baru untuk bulan berikutnya untuk menyimpan hanya data enam bulan terakhir.
T: Dalam database PolarDB for MySQL yang sama, cara apa yang cocok untuk menyalin tabel yang sangat besar, misalnya menyalin seluruh isi tabel A ke tabel B?
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 di bawah konkurensi tinggi?
J: Ya, bisa. Di pengaturan titik akhir kluster, Anda dapat mengaktifkan pool koneksi tingkat sesi untuk optimasi. Untuk informasi lebih lanjut, lihat Mengatur titik akhir kluster.
T: Bagaimana cara mencegah beberapa pernyataan SQL tidak efisien membanjiri seluruh database?
J: Jika kluster PolarDB for MySQL Anda menjalankan versi 5.6 atau 8.0, Anda dapat menggunakan fitur Concurrency Control untuk membatasi aliran pernyataan tertentu.
T: Apakah PolarDB mendukung timeout sesi idle?
J: Ya, mendukung. Anda dapat memodifikasi parameter wait_timeout untuk menyesuaikan periode timeout untuk sesi idle. Untuk informasi lebih lanjut, lihat Mengatur parameter kluster dan node.
T: Bagaimana cara menemukan pernyataan SQL lambat?
J: Anda dapat menemukan pernyataan SQL lambat dengan dua cara berikut:
- Kueri langsung pernyataan SQL lambat di konsol. Untuk informasi lebih lanjut, lihat Pernyataan SQL lambat.
- Hubungkan ke kluster database dan eksekusi show processlist; untuk menemukan pernyataan SQL yang memerlukan waktu lama untuk dijalankan. Untuk informasi lebih lanjut tentang cara menghubungkan ke kluster database, lihat Menghubungkan ke kluster database.
T: Bagaimana cara menghentikan pernyataan SQL lambat?
J: Setelah menemukan pernyataan SQL lambat, Anda dapat melihat ID-nya lalu eksekusi kill <Id> untuk menghentikannya.

Siklus hidup data

T: Bagaimana kluster PolarDB for MySQL mengarsipkan data panas dan hangat sebagai data dingin?
J: Kluster PolarDB for MySQL mendukung pengarsipan data panas dari mesin InnoDB dan data hangat dari X-Engine di PolarStore ke media penyimpanan dingin di OSS dalam format CSV atau ORC dengan menentukan kebijakan DDL. Setelah diarsipkan, ruang penyimpanan di PolarStore dilepaskan, dan biaya penyimpanan database secara keseluruhan berkurang. Untuk informasi lebih lanjut, lihat Mengarsipkan data dingin secara manual.
T: Apakah kluster PolarDB for MySQL mendukung pemisahan dan penyimpanan otomatis data panas, hangat, dan dingin? Bagaimana cara kerjanya?
J: Kluster PolarDB for MySQL mendukung pemisahan dan pengarsipan otomatis data panas, hangat, dan dingin. Dengan menentukan kebijakan DLM, Anda dapat mengarsipkan data dari PolarStore ke media penyimpanan OSS berbiaya rendah secara otomatis. Hal ini mengurangi biaya penyimpanan database dan mengoptimalkan efeknya. Untuk informasi lebih lanjut, lihat Mengarsipkan data dingin secara otomatis.