Memigrasikan database Anda ke pusat data baru dapat menjadi proses yang berisiko tinggi dan memakan waktu. Basis data berisi status, dan bisa jauh lebih sulit untuk dimigrasikan dibandingkan dengan server web, antrean, atau server cache.
Dalam posting blog ini, kami akan memberi Anda beberapa tips tentang cara memigrasikan data Anda dari satu penyedia layanan ke penyedia layanan lainnya. Prosesnya agak mirip dengan posting kami sebelumnya tentang cara memutakhirkan MySQL, tetapi ada beberapa perbedaan penting.
Replikasi MySQL atau Cluster Galera?
Beralih ke penyedia layanan lain (mis., pindah dari AWS ke Rackspace atau dari server colocated ke cloud) sangat sering berarti seseorang akan membangun infrastruktur baru secara paralel, menyinkronkannya dengan infrastruktur lama, lalu beralih ke infrastruktur tersebut. Untuk menghubungkan dan menyinkronkannya, Anda mungkin ingin memanfaatkan replikasi MySQL.
Jika Anda menggunakan Galera Cluster, mungkin lebih mudah untuk memindahkan node Galera Anda ke pusat data yang berbeda. Namun, perhatikan bahwa seluruh cluster masih harus diperlakukan sebagai database tunggal. Ini berarti bahwa situs produksi Anda mungkin mengalami latensi tambahan yang diperkenalkan saat merentangkan Galera Cluster melalui WAN. Dimungkinkan untuk meminimalkan dampak dengan menyetel pengaturan jaringan di Galera dan sistem operasi, tetapi dampaknya tidak dapat sepenuhnya dihilangkan. Dimungkinkan juga untuk menyiapkan Replikasi MySQL asinkron antara cluster lama dan baru, jika dampak latensi tidak dapat diterima.
Menyiapkan Konektivitas Aman
Replikasi MySQL tidak terenkripsi, dan karenanya tidak aman untuk digunakan melalui WAN. Ada banyak cara untuk memastikan bahwa data Anda akan ditransfer dengan aman. Anda harus menyelidiki apakah mungkin untuk membuat koneksi VPN antara infrastruktur Anda saat ini dan penyedia layanan baru Anda. Sebagian besar penyedia (misalnya Rackspace dan AWS) menyediakan layanan seperti itu - Anda dapat menghubungkan bagian "berawan" ke pusat data yang ada melalui jaringan pribadi virtual.
Jika, karena alasan tertentu, solusi ini tidak bekerja untuk Anda (mungkin memerlukan perangkat keras yang tidak dapat Anda akses), Anda dapat menggunakan perangkat lunak untuk membangun VPN - salah satunya adalah OpenVPN. Alat ini akan bekerja dengan baik untuk menyiapkan koneksi terenkripsi antara pusat data Anda.
Jika OpenVPN bukan pilihan, ada lebih banyak cara untuk memastikan replikasi akan dienkripsi. Misalnya, Anda dapat menggunakan SSH untuk membuat terowongan antara pusat data lama dan baru, dan meneruskan port 3306 dari budak (atau master) MySQL saat ini ke node baru. Ini dapat dilakukan dengan cara yang sangat sederhana selama Anda memiliki konektivitas SSH antara host:
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &Misalnya:
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &Sekarang, Anda dapat terhubung ke server jauh dengan menggunakan 127.0.0.1:3307
$ mysql -P3307 -h 127.0.0.1Ini akan bekerja sama untuk replikasi, ingatlah untuk menggunakan 127.0.0.1 untuk master_host dan 3307 untuk master_port
Last but not least, Anda dapat mengenkripsi replikasi Anda menggunakan SSL. Postingan blog sebelumnya ini menjelaskan bagaimana hal itu dapat dilakukan dan apa dampaknya terhadap kinerja replikasi.
Jika Anda memutuskan untuk menggunakan replikasi Galera di kedua pusat data, saran di atas juga berlaku di sini. Ketika datang ke SSL, kami sebelumnya membuat blog tentang cara mengenkripsi lalu lintas replikasi Galera. Untuk solusi yang lebih lengkap, Anda mungkin ingin mengenkripsi semua koneksi database dari aplikasi klien dan infrastruktur manajemen/pemantauan.
Menyiapkan Infrastruktur Baru
Setelah Anda memiliki konektivitas, Anda harus mulai membangun infrastruktur baru. Untuk itu, Anda mungkin akan menggunakan xtrabackup atau mariabackup. Mungkin tergoda untuk menggabungkan migrasi dengan peningkatan MySQL, setelah semua Anda menyiapkan lingkungan baru di lokasi baru. Kami tidak akan merekomendasikan untuk melakukan itu. Bermigrasi ke infrastruktur baru cukup signifikan dengan sendirinya sehingga menggabungkannya dengan perubahan besar lainnya meningkatkan kompleksitas dan risiko. Itu juga berlaku untuk hal-hal lain - Anda ingin mengambil pendekatan selangkah demi selangkah terhadap perubahan. Hanya dengan mengubah hal-hal satu per satu, Anda dapat memahami hasil dari perubahan tersebut, dan bagaimana pengaruhnya terhadap beban kerja Anda - jika Anda membuat lebih dari satu perubahan pada waktu tertentu, Anda tidak dapat memastikan mana yang bertanggung jawab atas suatu perubahan (baru ) perilaku yang Anda amati.
Saat Anda memiliki instans MySQL baru dan berjalan di pusat data baru, Anda perlu melepaskannya dari simpul di pusat data lama - untuk memastikan bahwa data di kedua pusat data akan tetap sinkron. Ini akan berguna saat Anda mempersiapkan diri untuk cutover terakhir. Ini juga merupakan cara yang bagus untuk memastikan bahwa lingkungan baru dapat menangani beban tulis Anda.
Langkah selanjutnya adalah membangun infrastruktur pementasan lengkap di lokasi baru dan melakukan tes dan benchmark. Ini adalah langkah yang sangat penting yang tidak boleh dilewati - masalahnya di sini adalah Anda, sebagai DBA, harus memahami kapasitas infrastruktur Anda. Ketika Anda mengubah penyedia, banyak hal juga berubah. Perangkat keras/vm baru lebih cepat atau lebih lambat. Ada lebih banyak atau lebih sedikit memori per instance. Anda perlu memahami kembali bagaimana beban kerja Anda akan sesuai dengan perangkat keras yang akan Anda gunakan. Untuk itu Anda mungkin akan menggunakan Percona Playback atau pt-log-player untuk memutar ulang beberapa kueri kehidupan nyata pada sistem staging. Anda akan ingin menguji kinerja dan memastikan bahwa itu pada tingkat yang dapat diterima untuk Anda. Anda juga ingin melakukan semua tes penerimaan standar yang Anda jalankan pada rilis baru Anda - hanya untuk mengonfirmasi bahwa semuanya sudah aktif dan berjalan. Secara umum, semua aplikasi harus dibangun dengan cara yang tidak bergantung pada konfigurasi perangkat keras dan pengaturan saat ini. Namun ada sesuatu yang mungkin terlewatkan dan aplikasi Anda mungkin bergantung pada beberapa penyesuaian konfigurasi atau solusi perangkat keras yang tidak Anda miliki di lingkungan baru.
Terakhir, setelah Anda puas dengan pengujian Anda, Anda pasti ingin membangun infrastruktur siap produksi. Setelah ini selesai, Anda mungkin ingin menjalankan beberapa tes baca-saja untuk verifikasi akhir. Ini akan menjadi langkah terakhir sebelum peralihan.
Cutover
Setelah semua pengujian tersebut dilakukan dan setelah infrastruktur dianggap siap produksi, langkah terakhir adalah memotong lalu lintas dari infrastruktur lama.
Secara global, ini adalah proses yang kompleks tetapi ketika kita melihat tingkat basis data, ini kurang lebih sama dengan failover standar - sesuatu yang mungkin telah Anda lakukan beberapa kali di masa lalu. Kami membahasnya secara rinci di posting sebelumnya, singkatnya langkah-langkahnya adalah:hentikan lalu lintas, pastikan itu berhenti, tunggu sementara aplikasi dipindahkan ke pusat data baru (catatan DNS berubah atau tidak), lakukan beberapa tes asap untuk memastikan semua terlihat bagus, tayangkan, pantau dengan cermat untuk sementara waktu.
Peralihan ini akan membutuhkan waktu henti, seperti yang bisa kita lihat. Masalahnya adalah untuk memastikan kami memiliki status yang konsisten di seluruh situs lama dan yang baru. Jika kita ingin melakukannya tanpa downtime, maka kita perlu menyiapkan replikasi master-master. Alasannya adalah karena kami menyegarkan DNS dan memindahkan sesi dari situs lama ke situs baru, kedua sistem akan digunakan secara bersamaan - hingga semua sesi dialihkan ke situs baru. Sementara itu, setiap perubahan di situs baru harus tercermin di situs lama.
Menggunakan Galera Cluster, seperti yang dijelaskan dalam posting blog ini, juga dapat menjadi cara untuk menjaga agar data antara kedua situs tetap sinkron.
Kami menyadari bahwa ini adalah deskripsi yang sangat singkat tentang proses migrasi data. Semoga cukup untuk mengarahkan Anda ke arah yang baik dan membantu Anda mengidentifikasi informasi tambahan apa yang perlu Anda cari.
