Catatan: Artikel ini adalah panduan dan bukan proses langkah demi langkah. Ini mengasumsikan Anda sudah familiar dengan administrasi sistem Linux® dan rsync utilitas. Jangan jalankan perintah dalam artikel ini jika Anda tidak sepenuhnya memahaminya. Dalam semua kasus, pastikan Anda telah mencadangkan data sebelum mengikuti langkah-langkah dalam panduan ini. Berlaku biaya bandwidth standar.
Panduan ini membantu Anda mempersingkat waktu migrasi server. Jika aplikasi server Anda cocok dengan salah satu karakteristik yang disorot dalam artikel ini, baca terus—artikel ini mungkin membuat waktu rsync lebih pendek dan lebih dapat diprediksi untuk Anda. Ini juga menunjukkan untuk memotong waktu migrasi dengan mengambil tindakan pencegahan sebelum melakukannya.
Mempercepat proses rsync
Volume ruang disk yang digunakan pada server menentukan waktu rsync. Artinya, semakin banyak data untuk disalin, semakin lama pekerjaan itu berlangsung. Biasanya, rsync OS kosong membutuhkan waktu 10-15 menit untuk diselesaikan. Kasus penggunaan server berikut dapat secara dramatis memperpanjang waktu rsync:
- Server yang berisi banyak file kecil, seperti file sesi Ruby, file cache, file pesan server email, atau thumbnail gambar server web . Migrasi data tersebut dengan menggunakan rsync membutuhkan waktu lebih lama untuk diselesaikan daripada yang Anda harapkan. Ini berarti sinkronisasi awal membutuhkan waktu lebih lama, tetapi lintasan kedua dalam mode penyelamatan—dengan waktu henti terkait—lebih singkat.
- Server yang berisi banyak file diperbarui selama rsync langsung . Biasanya, ini adalah file tabel MySQL® MyISAM atau server web yang menghosting banyak domain, masing-masing dikonfigurasi untuk masuk ke file terpisah. Kebutuhan untuk memperbarui file yang ditulis secara aktif ini setelah salinan rsync first-pass memperpanjang waktu henti dari reboot untuk menyelesaikan proses rsync yang kedua.
- Server yang berisi satu atau beberapa file besar diperbarui selama migrasi . Contohnya termasuk database MySQL menggunakan format InnoDB, server email dengan log email besar, dan server web yang masuk ke satu file besar. Memperbarui file yang ditulis secara aktif ini dengan rsync kedua setelah salinan rsync first-pass dapat sangat memperpanjang waktu henti terkait.
Rahasia untuk memotong waktu rsync adalah dengan mengelola data di server Anda dan mengidentifikasi aplikasi apa pun yang menulis ke disk selama migrasi langsung.
Masalah:Overhead file kecil
Meskipun tidak memakan banyak ruang disk individu, server yang menampung banyak file kecil memaksa proses rsync untuk melakukan banyak file-open , file-copy , danfile-check proses.
Misalnya, file data satu gigabyte memerlukan satu set file yang dibuka, disalin, dan proses pemeriksaan. Bandingkan dengan potongan data satu gigabyte yang tersebar di 10.000 file individual yang membutuhkan 10.000 kumpulan proses file individual. Itu lebih banyak sistem dan overhead jaringan.
Daftar berikut menunjukkan aplikasi yang membuat banyak file kecil dan memiliki waktu persiapan migrasi yang lebih lama:
- Server web yang menyajikan banyak thumbnail kecil atau file gambar
- Menyimpan cache server yang menyimpan di disk dengan file kecil
- Server email dengan arsip besar email yang tidak terhapus
- Server Ruby atau Rails, yang cenderung membuat beberapa file sesi kecil dan tidak menghapusnya
- repositori git
- Server aplikasi khusus yang membuat tetapi tidak menghapus file sesi untuk setiap pengunjung
Masalah file kecil membuat rsync kurang dapat diprediksi dan membutuhkan waktu lebih lama.
Cara bermigrasi
Periksa aplikasi server Anda terhadap daftar sebelumnya. Jika aplikasi Anda ada dalam daftar, lakukan apa yang Anda bisa untuk memangkas file kecil yang tidak diinginkan sebelum menjalankan rsync yang sebenarnya memerintah. Jika Anda menjalankan Ruby atau Rails, anggap yang terburuk dan cari forum komunitas untuk sesi biasa dan lokasi file cache, serta cara mengidentifikasi mana yang dapat Anda hapus dengan aman. Pertimbangkan untuk menyimpan data sesi di MySQL dengan perintah berikut:
rake db:sessions:create
Potong file log di log/ ke nol byte dengan perintah berikut:
rake log:clear
Jika Anda menjalankan server caching yang menyimpan cache ke disk alih-alih RAM, identifikasi direktori penyimpanan filenya dan pangkas secara agresif. Periksa sistem file Anda untuk sesi kecil dan file cache yang dibuat oleh aplikasi khusus. Sekali lagi, pangkas dengan semangat. Jika memigrasi server email dengan Mail DeliveryAgent (MDA) seperti Dovecot terinstal, minta pengguna email Anda membersihkan arsip email mereka dari email lama terlebih dahulu.
Masalah:Terus-menerus mengubah file
Anda harus menyalin lagi file yang berubah antara awal dan akhir rsync dengan rsync tindak lanjut untuk migrasi server menyeluruh. Proses ini memperpanjang waktu penyelesaian migrasi.
Server basis data adalah penyebab paling sering yang memperbarui file data besar antara awal dan akhir migrasi. Perubahan ini memaksa sistem untuk menyalin seluruh file database lagi dalam proses rsync kedua yang mungkin Anda lakukan dalam migrasi.
Beberapa kombinasi struktur dan tipe database cenderung memperburuk masalah seperti ini. Misalnya, Anda memiliki database MyISAM multi-tabel MySQL dengan banyak file tabel yang diperbarui dalam setiap transaksi SQL. Dalam hal ini, banyak, jika tidak semua, file tabel mungkin perlu disalin lagi selama operasi rsync mode penyelamatan kedua.
Mengingat bahwa file database bisa berukuran besar, implikasi pembaruan ini untuk waktu migrasi menjadi jelas. Sulit untuk memprediksi secara akurat berapa lama waktu yang dibutuhkan rsync migrasi. Lagi pula, bagaimana kita bisa memprediksi apa dan berapa banyak pembaruan SQL yang akan terjadi antara migrasi mulai dan selesai?
Cara bermigrasi
Jika database Anda berisi banyak data usang, pertimbangkan untuk mengarsipkan data tersebut dan kemudian memangkasnya dari database langsung sebelum memigrasikan server Anda. MySQL, misalnya, memungkinkan Anda untuk mengarsipkan data dengan menggunakan mysqldump skrip, setelah itu Anda dapat menghapus data usang di livedatabase. mysqldump yang besar file keluaran yang berisi data usang tidak diperpanjang rsync kedua karena tidak akan berubah sejak lintasan pertama.
Opsi lain jika Anda memiliki aplikasi yang menulis ke banyak file selama pengubahan ukuran adalah menyetel aplikasi ke mode hanya-baca segera sebelum menjalankan rsync memerintah. Anda biasanya dapat mengatur database ke mode read-only sementara. Dengan aplikasi lain, jarak tempuh Anda mungkin berbeda. Anda juga dapat mencegah penulisan ke beberapa file dengan menonaktifkan aplikasi, tetapi menyetel aplikasi ke mode hanya baca biasanya merupakan opsi yang lebih disukai.
Masalah:File besar yang terus diperbarui
File yang sangat besar (10 GB atau lebih) diperbarui selama rsync menimbulkan masalah yang sama untuk waktu migrasi seperti file yang lebih kecil dan terus diperbarui tetapi pada steroid. Jika file host server Anda yang sering ditulisi, bagian ini cocok untuk Anda.
Rsync kedua perlu sepenuhnya menyalin ulang file besar yang terus diperbarui ini untuk menangkap pembaruan apa pun yang dibuat setelah proses migrasi atau pengubahan ukuran dimulai. Ini memperpanjang waktu migrasi karena ukuran salinan rsync kedua itu.
Server database MySQL yang menggunakan format file data InnoDB menulis data ke satu file yang memang tumbuh sangat besar. Demikian pula, MySQL dalam mode InnoDB mencatat ke satu file log besar.
Pembaruan untuk data atau file log MySQL InnoDB besar, seperti /var/lib/mysql/ibdata1 , memaksa proses rsync untuk menyalin ulang seluruh file dalam gerakan kedua. Jika file ini berukuran besar, penyalinan ulang dapat memakan waktu lama, sehingga database tetap offline.
Sumber file besar lainnya adalah log aplikasi, termasuk log yang dihasilkan oleh server email dan beberapa server web. Apache® dapat menghasilkan file log berukuran 16 Gb atau lebih besar, jadi tidak aman untuk berasumsi bahwa logging default Apache membantu Anda menghindari masalah file besar ini.
Log transaksi MySQL juga dapat bertambah besar jika Anda telah mengaktifkan pencatatan transaksi. Orang jarang melakukannya, dan bahkan lebih jarang mereka mengaktifkan pencatatan transaksi tanpa kehabisan ruang disk sesudahnya. Namun, sebaiknya tetap waspada terhadap kemungkinan ini.
Cara bermigrasi
Seperti dijelaskan sebelumnya, memangkas basis data cruft mungkin membantu mengurangi total waktu rsync. Arsipkan dan hapus basis data lama atau usang sebelum mencoba migrasi.
Sekali lagi, mematikan penulisan basis data, jika memungkinkan, akan mengurangi waktu migrasi. Menonaktifkan logging juga dapat membantu database InnoDB.
Jika Anda telah mengaktifkan pencatatan log transaksi MySQL dan file log transaksi berukuran besar, sebaiknya nonaktifkan, arsipkan, lalu hapus pada irisan sebelum memulai rsyncmigration.
Di server email, periksa ukuran /var/log/mail.log atau /var/log/maillog sebelum migrasi. Pertimbangkan untuk menonaktifkan server email sebelum migrasi, terutama jika Anda memiliki server email cadangan untuk mengambil muatan.
Demikian pula, periksa bagaimana Apache masuk. Jika itu mencatat semua permintaan ke satu file, periksa ukuran file itu dan pertimbangkan untuk mengarsipkan dan menghapusnya atau mematikan Apache sebelum memulai proses migrasi. Saran yang sama berlaku untuk aplikasi lain yang Anda tahu sedang menulis ke file log besar.
Untuk aplikasi ini dan aplikasi lainnya, tinjau logrotate . Anda kebijakan (jika Anda memilikinya) untuk memeriksa apakah itu memeriksa ukuran file log Anda. Ini menghemat waktu henti selama migrasi dan membuat hidup dengan server Linux menjadi lebih mudah.
Kemasi tas peralatan Anda
Tentu saja, sulit untuk melacak file yang dibuat setelah Anda menyiapkan server. Itu berlaku untuk aplikasi yang membuat file sesi. Membayar untuk menemukan dan memusnahkan koleksi besar file kecil ini.
Anda dapat mengidentifikasi sepuluh direktori dan file terbesar dengan mengeluarkan perintah berikut sebagai root :
du -a / | sort -n -r | head -n 10
Ubah 10 terakhir itu ke nomor lain untuk mengubah berapa banyak file dan direktori yang dikembalikan oleh pencarian. Perintah ini adalah alat tengah yang baik untuk mengidentifikasi direktori besar dari file kecil dan file besar. Jika Anda hanya ingin mencari file besar, coba pencari file besar ini (sebagai root ):
find ~/ -mount -type f -ls|sort -rnk7 |head -30|awk '{printf "%10d MB\t%s\n",($7/1024)/1024,$NF}'
Jika Anda hanya ingin menemukan direktori besar, coba pencari direktori besar ini (sebagai root ):
du -x --max-depth=4 ~/|sort -rn|head -n30|awk '{printf "%10d MB\t%s\n",$1/1024,$2}'
Detail teknis
Misalkan server Anda tidak cocok dengan salah satu jenis umum yang telah kami periksa di atas. Dalam hal ini, Anda dapat menilai bagaimana tampilan waktu migrasinya jika Anda mempertimbangkan aplikasi Anda dengan pemahaman tentang cara kerja proses migrasi (rsync).
Tahap pertama khas dari migrasi adalah rsync langsung, yang pada dasarnya adalah salinan dari seluruh sistem file server. Semua aplikasi dibiarkan berjalan selama tahap ini.
Di sinilah memprediksi waktu migrasi mengalami ketidakpastian pertama. Tanpa pengetahuan terperinci tentang penggunaan sistem file server Anda, Anda tidak dapat secara akurat memprediksi berapa lama file-copy tahap rsync akan selesai.
Ketidakpastian ini berlaku untuk direktori final pada sistem file Linux:/var/ direktori. Ini disebut var karena ukuran data yang dimilikinya adalah variabel dan berubah saat aplikasi server sedang berjalan.
Ketidakpastian kedua adalah bahwa fase terakhir dari migrasi mencakup komponen mode penyelamatan (waktu henti). Selama fase ini, proses menyalin kembali semua file yang diperbarui setelah fase pertama rsync langsung dimulai. Lamanya waktu henti tergantung pada ukuran dan jumlah file yang diperbarui. Sekali lagi, proses rsync tidak dapat mengetahui sebelumnya berapa banyak pembaruan aplikasi seperti MySQL yang menulis ke file data, jadi sulit untuk memprediksi durasi dari penyelamatan akhir ini. mode rsync salin.
Informasi sebelumnya berlaku untuk proses migrasi manual biasa. Cloud kami mengubah proses pengubahan ukuran untuk menurunkan server untuk satu sinkronisasi, meningkatkan waktu henti, dan meningkatkan keandalan sinkronisasi.
Ringkasan
Jika Anda mengetahui bagaimana aplikasi Anda menggunakan ruang disk dan menulis ke file, Anda mungkin dapat menilai apakah migrasi akan memakan waktu lebih lama dari yang Anda inginkan dan membuat persiapan yang sesuai. Paling tidak, Anda dapat menggunakan pengetahuan migrasi yang baru Anda temukan untuk menjadwalkan migrasi dengan lebih baik agar sesuai dengan persyaratan waktu Anda.
Gunakan tab Umpan Balik untuk memberikan komentar atau mengajukan pertanyaan. Anda juga dapat memulai percakapan dengan kami.