Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Impor data ke dalam instans DB MySQL
Anda dapat menggunakan beberapa teknik yang berbeda untuk mengimpor data ke dalam instans DB RDS for MySQL. Pendekatan terbaik bergantung pada sumber data, jumlah data, dan apakah impor dilakukan satu kali atau berkelanjutan. Jika Anda memigrasikan aplikasi bersama dengan data, pertimbangkan juga jumlah waktu henti yang Anda alami.
Ikhtisar
Temukan teknik untuk mengimpor data ke instans DB RDS for MySQL dalam tabel berikut.
| Sumber | Jumlah data | Satu kali atau berkelanjutan | Waktu henti aplikasi | Teknik | Informasi lain |
|---|---|---|---|---|---|
|
Basis data MySQL yang sudah ada di on-premise atau di Amazon EC2 |
Setiap |
Satu kali |
Beberapa |
Buat cadangan dari basis data on-premise Anda, simpan di Amazon S3, lalu pulihkan file cadangan ke instans DB Amazon RDS baru yang menjalankan MySQL. |
|
|
Setiap basis data yang sudah ada |
Setiap |
Satu kali atau berkelanjutan |
Minimal |
Gunakan AWS Database Migration Service untuk memigrasikan database dengan downtime minimal dan, untuk banyak mesin DB database, lanjutkan replikasi yang sedang berlangsung. |
Apa itu AWS Database Migration Service dan Panduan Pengguna Menggunakan basis data yang kompatibel dengan MySQL sebagai target untuk AWS DMS dalam AWS Database Migration Service |
|
Instans DB MySQL yang sudah ada |
Setiap |
Satu kali atau berkelanjutan |
Minimal |
Buat replika baca untuk replikasi berkelanjutan. Dorong replika baca untuk pembuatan satu kali instans DB baru. |
|
|
Basis data MariaDB atau MySQL yang sudah ada |
Kecil |
Satu kali |
Beberapa |
Salin data secara langsung ke instans DB MySQL Anda dengan menggunakan utilitas baris perintah. | |
|
Data tidak disimpan dalam basis data yang sudah ada |
Sedang |
Satu kali |
Beberapa |
Buat file datar dan impor mereka menggunakan pernyataan MySQLLOAD DATA LOCAL
INFILE. |
Mengimpor data dari sumber mana pun ke instans DB MySQL atau MariaDB |
|
Basis data MySQL atau MariaDB yang sudah ada di on-premise atau di Amazon EC2 |
Setiap |
Berkelanjutan |
Minimal |
Konfigurasikan replikasi dengan basis data MariaDB atau MySQL yang sudah ada sebagai sumber replikasi. |
Mengonfigurasi replikasi posisi file log biner dengan instans sumber eksternal Mengimpor data ke basis data Amazon RDS MariaDB atau MySQL dengan lebih sedikit waktu henti |
catatan
Basis data sistem 'mysql' berisi informasi autentikasi dan otorisasi yang dibutuhkan untuk masuk ke instans DB Anda dan mengakses data Anda. Penurunan, pengubahan, penamaan ulang, atau penyingkatan tabel, data, atau konten lain dari basis data 'mysql' dalam instans DB Anda dapat mengakibatkan kesalahan dan dapat menyebabkan instans DB dan data Anda tidak dapat diakses. Jika ini terjadi, Anda dapat mengembalikan instance DB dari snapshot menggunakan AWS CLI
restore-db-instance-from-db-snapshot perintah. Anda dapat memulihkan instans DB menggunakan AWS CLI restore-db-instance-to-point-in-time perintah.
Impor pertimbangan data
Di bawah ini Anda dapat menemukan informasi teknis tambahan terkait pemuatan data ke dalam MySQL. Informasi ini ditujukan bagi pengguna tingkat lanjut yang sudah memahami arsitektur server MySQL.
Log biner
Beban data menimbulkan penalti performa dan memerlukan ruang disk kosong tambahan (hingga empat kali lebih banyak) jika log biner diaktifkan dibandingkan jika pemuatan data yang sama dengan log biner yang tidak diaktifkan. Keparahan penalti performa dan jumlah ruang disk kosong yang dibutuhkan berbanding lurus dengan ukuran transaksi yang digunakan untuk memuat data.
Ukuran transaksi
Ukuran transaksi memainkan peran yang penting dalam pemuatan data MySQL. Ukuran ini memiliki pengaruh besar pada konsumsi sumber daya, pemanfaatan ruang disk, kelanjutan proses, waktu untuk pemulihan, dan format input (file rata atau SQL). Bagian ini menjelaskan bagaimana ukuran transaksi dapat memengaruhi log biner dan mengakibatkan kasus penonaktifan log biner selama pemuatan data yang besar. Sebagaimana disebutkan sebelumnya, log biner diaktifkan dan dinonaktifkan dengan mengatur periode retensi cadangan otomatis Amazon RDS. Nilai non-nol mengaktifkan log biner, dan nilai nol menonaktifkannya. Kami juga akan menjelaskan dampak transaksi yang besar pada InnoDB dan mengapa menjaga ukuran transaksi tetap kecil itu penting.
Transaksi kecil
Untuk transaksi kecil, log biner menggandakan jumlah tulis disk yang dibutuhkan untuk memuat data. Efek ini dapat secara ekstrem menurunkan performa untuk sesi basis data lain dan meningkatkan waktu yang dibutuhkan untuk memuat data. Degradasi yang dialami sebagian bergantung pada tingkat pengunggahan, aktivitas basis data lainnya yang terjadi selama pemuatan, dan kapasitas dari instans DB Amazon RDS Anda.
Log biner juga mengonsumsi ruang disk kira-kira setara dengan jumlah data yang dimuat sampai log dicadangkan dan dihapus. Untungnya, Amazon RDS meminimalkan hal ini dengan mencadangkan dan menghapus log biner secara rutin.
Transaksi besar
Transaksi besar menimbulkan penalti 3X untuk IOPS dan konsumsi disk dengan log biner diaktifkan. Tindakan ini dilakukan karena cache log biner tumpah ke disk, sehingga mengonsumsi ruang disk dan menimbulkan IO tambahan untuk setiap penulisan. Cache tidak dapat ditulis ke binlog hingga transaksi dipindahkan atau di-rollback, sehingga mengonsumsi ruang disk sebanding dengan jumlah data yang dimuat. Saat transaksi dipindahkan, cache harus disalin ke binlog, sehingga menciptakan salinan ketiga dari data pada disk.
Karenanya, harus ada ruang disk kosong setidaknya tiga kali ukuran data untuk memuat data dibandingkan jika memuat dengan log biner dinonaktifkan. Misalnya, 10 GiB data yang dimuat sebagai transaksi tunggal mengonsumsi setidaknya 30 GiB ruang disk selama pemuatan. Data akan mengonsumsi 10 GiB untuk tabel + 10 GiB untuk cache log biner + 10 GiB untuk log biner itu sendiri. File cache akan tetap berada pada disk hingga sesi yang menciptakannya berakhir atau sesi mengisi cache log biner lagi pada transaksi lain. Log biner harus tetap berada pada disk hingga pencadangan selesai, sehingga mungkin perlu waktu beberapa saat sebelum 20 GiB ekstra tersebut dibebaskan.
Jika data dimuat menggunakan LOAD DATA LOCAL INFILE, salinan data lain akan diciptakan jika basis data harus dipulihkan dari sebuah cadangan yang dibuat sebelum pemuatan. Selama pemulihan, MySQL mengekstrak data dari log biner ke dalam sebuah file rata. MySQL kemudian menjalankan LOAD DATA LOCAL INFILE, sama seperti dalam transaksi asli. Akan tetapi, saat ini file input bersifat lokal bagi server basis data. Melanjutkan contoh sebelumnya, pemulihan gagal kecuali jika ada setidaknya 40 GiB ruang disk kosong yang tersedia.
Penonaktifan log biner
Jika memungkinkan, nonaktifkan log biner selama pemuatan data besar untuk menghindari kebutuhan overhead sumber daya dan ruang disk tambahan. Dalam Amazon RDS, penonaktifan log biner sesederhana mengatur periode retensi cadangan menjadi nol. Jika Anda melakukan ini, kami menyarankan agar Anda mengambil snapshot DB dari instans basis data sesaat sebelum pemuatan. Dengan melakukan ini, Anda dapat dengan cepat dan mudah membatalkan perubahan yang dibuat selama pemuatan jika Anda membutuhkannya.
Setelah pemuatan, atur periode retensi cadangan kembali ke nilai yang sesuai (bukan nol).
Anda tidak dapat mengatur periode retensi cadangan ke nol jika instans DB adalah instans DB sumber untuk replika baca.
InnoDB
Informasi dalam bagian ini menyediakan alasan yang kuat untuk menjaga ukuran transaksi tetap kecil saat menggunakan InnoDB.
Urungkan
InnoDB menghasilkan pembatalan untuk mendukung fitur seperti rollback dan MVCC transaksi. Pembatalan disimpan dalam tablespace sistem InnoDB (biasanya ibdata1) dan dipertahankan hingga dibuang oleh utas pembersihan. Utas pembersihan tidak dapat melangkahi pembatalan transaksi aktif terlama, sehingga secara efektif diblokir hingga transaksi dipindahkan atau menyelesaikan rollback. Jika basis data sedang memproses transaksi lain selama pemuatan, pembatalan juga terakumulasi dalam tablespace sistem dan tidak dapat dibuang meskipun transaksi dipindahkan dan tidak ada transaksi lain yang harus dibatalkan untuk MVCC. Dalam situasi ini, semua transaksi (termasuk transaksi hanya baca) yang mengakses baris mana pun yang diubah oleh transaksi apa pun (bukan hanya transaksi pemuatan) akan melambat. Pelambatan terjadi karena transaksi memindai melalui pembatalan yang seharusnya telah dibersihkan jika bukan karena transaksi pemuatan yang berjalan lama.
Pembatalan disimpan dalam tablespace sistem, dan tablespace sistem tidak pernah menyusut ukurannya. Karenanya, transaksi pemuatan data yang besar dapat menyebabkan tablespace sistem menjadi cukup besar, yang mengonsumsi ruang disk yang tidak dapat Anda klaim ulang tanpa menciptakan ulang basis data dari awal.
Rollback
InnoDB dioptimalkan untuk dipindahkan. Pelaksanaan rollback pada transaksi yang besar dapat memakan waktu yang sangat lama. Dalam beberapa kasus, mungkin lebih cepat untuk melakukan point-in-time pemulihan atau mengembalikan snapshot DB.
Format data input
MySQL dapat menerima data yang masuk dalam salah satu dari dua bentuk: file rata dan SQL. Bagian ini menjelaskan beberapa keuntungan dan kerugian utama dari masing-masing faktor.
File rata
Pemuatan file rata dengan LOAD DATA LOCAL INFILE dapat menjadi metode pemuatan data yang paling cepat dan paling murah selama transaksi dijaga tetap relatif kecil. Dibandingkan dengan pemuatan data yang sama dengan SQL, file rata biasanya membutuhkan lebih sedikit lalu lintas jaringan, yang mengurangi biaya transmisi, dan memuat lebih cepat karena pengurangan overhead dalam basis data.
Satu transaksi besar
LOAD DATA LOCAL INFILE memuat keseluruhan file rata sebagai satu transaksi. Ini bukan hal yang buruk. Jika ukuran masing-masing file dapat dijaga tetap kecil, ada sejumlah keuntungan:
Kemampuan melanjutkan – Pelacakan atas file mana yang telah dimuat menjadi mudah. Jika masalah muncul selama pemuatan, Anda dapat melanjutkan dari bagian terakhir yang tidak bermasalah dengan mudah. Beberapa data mungkin harus ditransmisikan ulang ke Amazon RDS, tetapi dengan ukuran file yang kecil, jumlah yang ditransmisikan ulang minimal.
Pemuatan data secara paralel – Jika Anda memiliki sisa IOPS dan bandwidth jaringan untuk pemuatan file tunggal, pemuatan secara paralel dapat menghemat waktu.
Throttling tingkat beban – Pemuatan data memiliki dampak negatif pada proses lain? Lakukan throttling beban dengan meningkatkan interval antar file.
Berhati-hatilah
Keuntungan dari LOAD DATA LOCAL INFILE berkurang dengan cepat seiring meningkatnya ukuran transaksi. Jika membagi sejumlah data yang besar menjadi data yang lebih kecil bukanlah opsi yang tepat, SQL dapat menjadi pilihan yang lebih baik.
SQL
SQL memiliki satu keuntungan utama dibandingkan file rata: kemudahannya untuk menjaga ukuran transaksi tetap kecil. Akan tetapi, SQL dapat memakan waktu yang jauh lebih lama untuk memuat dibandingkan file rata dan sulit untuk menentukan di mana pemuatan dapat dilanjutkan setelah sebuah kegagalan. Misalnya, file mysqldump tidak dapat dimulai ulang. Jika sebuah kegagalan terjadi saat memuat file mysqldump, maka file membutuhkan modifikasi atau penggantian sebelum pemuatan dapat dilanjutkan. Alternatifnya adalah pemulihan pada titik waktu sebelum pemuatan dan pemutaran ulang file setelah penyebab kegagalan diperbaiki.
Pengambilan titik pemeriksaan menggunakan snapshot Amazon RDS
Jika Anda memiliki pemuatan yang akan memakan waktu berjam-jam atau bahkan berhari-hari, pemuatan tanpa log biner bukanlah sebuah prospek yang sangat menarik kecuali Anda dapat melakukan titik pemeriksaan secara berkala. Di sinilah fitur snapshot DB Amazon RDS menjadi sangat berguna. Snapshot DB membuat salinan point-in-time konsisten dari instance database Anda yang dapat digunakan mengembalikan database ke titik waktu itu setelah crash atau kecelakaan lainnya.
Untuk menciptakan sebuah titik pemeriksaan, ambil sebuah snapshot DB saja. Snapshot DB sebelumnya yang diambil untuk titik pemeriksaan dapat dibuang tanpa memengaruhi durabilitas atau waktu pemulihan.
Snapshot juga cepat, sehingga titik pemeriksaan yang sering tidak menambah waktu pemuatan secara signifikan.
Pengurangan waktu pemuatan
Berikut ini adalah beberapa tips tambahan untuk mengurangi waktu pemuatan:
Ciptakan semua indeks sekunder sebelum memuat. Kontra-intuitif ini untuk yang familier dengan basis data lainnya. Penambahan atau pemodifikasian sebuah indeks sekunder menyebabkan MySQL membuat tabel baru dengan perubahan indeks, menyalin data dari tabel yang sudah ada ke tabel baru, dan menghapus tabel asli.
Muat data dalam urutan PK. Tindakan ini sangat membantu khususnya untuk tabel InnoDB, ketika waktu pemuatan dapat berkurang 75–80 persen dan ukuran file data menjadi setengahnya.
Nonaktifkan batasan kunci asing foreign_key_checks=0. Untuk file rata yang dimuat dengan LOAD DATA LOCAL INFILE, tindakan ini dibutuhkan dalam banyak kasus. Untuk pemuatan apa pun, penonaktifan pemeriksaan FK menyediakan peningkatan performa yang signifikan. Pastikan untuk mengaktifkan batasan dan memverifikasi data setelah pemuatan.
Muat secara paralel kecuali sudah mendekati batas sumber daya. Gunakan tabel berpartisi jika perlu.
Gunakan sisipan multi-nilai saat memuat dengan SQL untuk meminimalkan overhead saat menjalankan pernyataan. Saat menggunakan mysqldump, tindakan ini akan dilakukan secara otomatis.
Kurangi IO log InnoDB innodb_flush_log_at_trx_commit=0
Jika Anda memuat data ke dalam sebuah instans DB yang tidak memiliki replika baca, atur parameter sync_binlog ke 0 saat memuat data. Saat pemuatan data selesai, atur parameter sync_binlog kembali ke 1.
Muat data sebelum mengonversi instans DB menjadi deployment Multi-AZ. Akan tetapi, jika instans DB sudah menggunakan deployment Multi-AZ, pengalihan ke deployment Satu AZ untuk pemuatan data tidak direkomendasikan, karena hanya memberikan peningkatan marginal.
catatan
Penggunaan innodb_flush_log_at_trx_commit=0 menyebabkan InnoDB mengalirkan log-nya setiap detik dan bukan pada setiap pemindahan. Tindakan ini memberikan keuntungan kecepatan yang signifikan, tetapi dapat menyebabkan kehilangan data selama crash. Berhati-hatilah saat menggunakannya.
Topik
- Memulihkan cadangan ke instans My SQL DB
- Mengimpor data dari MariaDB eksternal atau database MySQL ke RDS untuk MariaDB atau RDS untuk MySQL DB instance
- Mengimpor data ke basis data Amazon RDS MariaDB atau MySQL dengan lebih sedikit waktu henti
- Mengimpor data dari sumber mana pun ke instans DB MySQL atau MariaDB
