Komplikasi apa yang ada jika saya mengganti Mysql ke MariaDB? Adakah masalah Drush?

Saya memiliki situs drupal 7 Mysql yang berat dan saya berpikir untuk mengalihkan Mysql ke Mariadb , tetapi saya tidak yakin masalah apa yang akan saya hadapi . Dari apa yang saya baca, Mariadb tampaknya hanya setetes pengganti untuk Mysql dan sepertinya tidak banyak yang bisa diutak-atik. Saya bertanya-tanya apakah Mariadb akan mempengaruhi perintah drush?

7 drush database

— Patoshi パトシ
sumber

ok saya punya teknisi server saya untuk beralih ke mariadb. sejauh ini belum melihat sesuatu yang besar, tetapi dari pengalaman kami, kami memiliki banyak masalah saat melakukan peningkatan. Karena kami menggunakan versi cpanel yang lebih lama, kami harus terlebih dahulu memutakhirkan cpanel ke versi terbaru, kemudian memperbarui PHP, kemudian memperbarui Mysql, kemudian beralih kembali ke versi PHP ke 5.2 untuk menjaga masalah kompatibilitas. Sekarang kita menginstal MariaDB. Butuh 13 jam untuk transisi ini! Saya harus mengatakan pelajaran mahal, berpikir itu hanya akan memakan waktu kurang dari satu jam. Tes pada pementasan pertama! semoga ini membantu seseorang, + perwakilan jika berhasil! Terima kasih!

— Patoshi パトシ

Ada beberapa masalah untuk dipikirkan. Salah satunya adalah Debian unix_socket. Saya ingin tahu bahwa masalah ini tidak banyak dibahas. Saya berasumsi banyak yang memiliki alur kerja mereka dan masih menggunakan MySQL, itu sebabnya tidak terdokumentasi dengan baik. Biarkan saya menautkan ke masalah baru yang diposting untuk mengumpulkan beberapa pemikiran tentang ini: drupal.stackexchange.com/questions/242634/…

— nilsun

@nilsun Justru sebaliknya, hampir semua orang menggunakan MariaDB hari ini. Inilah artikel kanonik Pantheon tentang mengapa mereka menggunakannya untuk ratusan ribu situs Drupal, misalnya: pantheon.io/blog/using-mariadb-mysql-pengganti . Masalah-masalah yang Anda bicarakan kelihatannya ceruk, mungkin itu sebabnya Anda tidak dapat menemukan banyak diskusi tentangnya

— Clive

@Clive Terima kasih. Saya sebagian setuju. Tetapi Anda menghitung pemain besar. Tim pengembang kecil adalah situasi lain. Jika tidak ada seorang pun di tim dengan keahlian untuk mengkorelasikan perilaku pengemasan Debian dan filosofi MariaDB, Anda BISA (tidak harus) menghadapi beberapa tantangan kecil dari perubahan. Dan terutama ketika Anda menggunakan perangkat lunak pihak ketiga, yang tidak memiliki pesan kesalahan disiapkan untuk skenario seperti itu.

— nilsun

Jawaban:

Hanya ingin mengikuti ini (walaupun terlambat beberapa bulan) ... Telah membuat banyak situs Drupal di masa lalu, memutuskan untuk melakukan hal-hal "lebih baik" kali ini dan memasang MariaDB.

Semuanya berfungsi dengan luar biasa (lebih cepat, lebih bersih, dll.) Dengan Drupal 7 KECUALI untuk cadangan / pengembalian: / Selalu harus langsung masuk ke db (baik melalui PHPMyAdmin, Heidi, atau baris perintah) dan menyalin / mengekspor semua tabel.

Selain itu, yang mungkin ada sejumlah alasan untuk terjadi, saya sangat merekomendasikan MariaDB. Lebih sedikit sumber daya server yang digunakan, D7 jauh lebih cepat, dll.

— baju hangat
sumber

Tapi utas ini bukan tentang pro dan kontra dari MariaDB dan seberapa baik itu. Ini adalah pertanyaan yang dipikirkan dengan matang mengenai perubahan alur kerja produksi untuk berdiskusi dengan Drush. Dan ada beberapa.

— nilsun

Seperti yang Anda katakan, Maria DB adalah pengganti MySQL yang drop-in dan benar-benar transparan. Rilisnya bersamaan dengan MySQL versi besar / kecil yang sama sehingga hampir selalu terkait dengan fitur. Bunyinya file data biner standar MySQL, menggunakan systen standar my.cnf, dan bahkan memiliki pengganti drop-in untuk InnoDB.

Idenya adalah bahwa sejauh menyangkut aplikasi Anda, ia berpikir itu terhubung ke server MySQL. Ia menggunakan driver MySQL, mengeluarkan pernyataan MySQL penuh, dan menerima respons persis seperti yang akan dikirim oleh server MySQL. Aplikasi Anda tidak akan tahu bedanya.

Saya telah menggunakan Maria untuk sementara waktu sekarang untuk situs Drupal (juga menggunakan Drush secara luas) dan belum memiliki satu masalah hingga saat ini. Jika Anda menjalankan peningkatan * nix hanya pekerjaan dua menit.

— Clive
sumber

luar biasa. hanya apa yang perlu saya ketahui. Terima kasih!

— Patoshi パトシ

satu hal lain adalah saya kadang-kadang melakukan query sql melalui terminal. apa yang akan setara dengan melakukan msyqldump? atau drush sql-query 'select * from users'

— Patoshi パトシ

Saya pikir mysqldump menggunakan / usr / bin / mysql (atau yang setara) secara internal, dan karena Maria menyinkronkan path ke implementasinya sendiri, Anda tidak perlu melakukan perubahan, terus gunakan mysqldump seperti biasa. Saya membayangkan hal yang sama berlaku untuk Drush. Mungkin perlu memeriksa itu untuk memastikan

— Clive

Google untuk "MariaDB Debian unix_socket masalah akses" ... Masih ada beberapa hal untuk didiskusikan dan didokumentasikan.

— nilsun

@nilsun Saya belum pernah mengalami masalah itu - saya telah menjalankan Drupal 7 pada lusinan (mungkin ratusan) server yang didukung MariaDB selama bertahun-tahun tanpa masalah. Pantheon menjalankan seluruh infrastruktur Drupal / drush pada MariaDB, dan saya pikir Acquia juga melakukannya. Anda mungkin hanya menggunakan versi / konfigurasi yang salah, atau memiliki persyaratan khusus yang menghasilkan perilaku aneh. Semua pengembang agensi yang saya kenal juga menggunakan MariaDB, tidak akan bermimpi menggunakan MySQL lama, jadi sepertinya tidak akan menjadi masalah umum (setidaknya dalam pengalaman saya)

— Clive

Ada beberapa masalah yang perlu dikhawatirkan. Masalah unix_socket akses root Debian hanya salah satunya. Saya ingin tahu bahwa masalah ini tidak banyak dibahas. Saya berasumsi banyak yang memiliki aliran pekerjaan mereka dan masih menggunakan MySQL . Itu sebabnya banyak dari masalah ini tidak terdokumentasi dengan baik.

Terkait: MariaDB unix_socket menyebabkan masalah akses di bawah Debian - Drush tidak bisa masuk (Posting baru mulai mengumpulkan pemikiran tentang ini.)

— nilsun
sumber