pengenalan

Beberapa waktu lalu saya diberi tugas untuk mengembangkan failover cluster untuk PostgreSQL, beroperasi di beberapa pusat data yang dihubungkan melalui serat optik dalam satu kota, dan mampu menahan kegagalan (misalnya pemadaman listrik) pada satu pusat data. Sebagai perangkat lunak yang bertanggung jawab atas toleransi kesalahan, saya memilih Pacemakerkarena ini adalah solusi resmi dari RedHat untuk membuat failover cluster. Hal ini baik karena RedHat memberikan dukungan untuk itu, dan karena solusi ini bersifat universal (modular). Dengan bantuannya, dimungkinkan untuk memastikan toleransi kesalahan tidak hanya pada PostgreSQL, tetapi juga layanan lain, baik menggunakan modul standar atau membuatnya untuk kebutuhan spesifik.

Keputusan ini menimbulkan pertanyaan yang masuk akal: seberapa toleran terhadap kesalahan cluster failover? Untuk menyelidiki hal ini, saya mengembangkan bangku pengujian yang mensimulasikan berbagai kegagalan pada node cluster, menunggu layanan dipulihkan, memulihkan node yang gagal, dan melanjutkan pengujian dalam satu lingkaran. Proyek ini awalnya bernama hapgsql, namun lama kelamaan saya bosan dengan namanya yang hanya memiliki satu huruf vokal. Oleh karena itu, saya mulai menyebut database yang toleran terhadap kesalahan (dan IP mengambang yang menunjuk ke sana) krogan (karakter dari permainan komputer di mana semua organ penting diduplikasi), dan node, cluster, dan proyek itu sendiri tuchanka (planet tempat tinggal para krogan).

Sekarang pihak manajemen sudah mengizinkan buka proyek ke komunitas open source di bawah lisensi MIT. README akan segera diterjemahkan ke dalam bahasa Inggris (karena diharapkan konsumen utamanya adalah pengembang Pacemaker dan PostgreSQL), dan saya memutuskan untuk menyajikan README versi Rusia lama (sebagian) dalam bentuk artikel ini.

Cluster disebarkan pada mesin virtual VirtualBox. Sebanyak 12 mesin virtual (total 36GiB) akan dikerahkan, yang membentuk 4 cluster toleransi kesalahan (opsi berbeda). Dua cluster pertama terdiri dari dua server PostgreSQL, yang terletak di pusat data berbeda, dan satu server umum menyaksikan c perangkat kuorum (dihosting di mesin virtual murah di pusat data ketiga), yang mengatasi ketidakpastian 50% / 50%, memberikan suara Anda kepada salah satu pihak. Cluster ketiga di tiga pusat data: satu master, dua budak, no perangkat kuorum. Cluster keempat terdiri dari empat server PostgreSQL, dua per pusat data: satu master, sisanya replika, dan juga menggunakan menyaksikan c perangkat kuorum. Yang keempat tahan terhadap kegagalan dua server atau satu pusat data. Solusi ini dapat ditingkatkan ke jumlah replika yang lebih besar jika diperlukan.

Layanan waktu yang akurat ntpd juga dikonfigurasi ulang untuk toleransi kesalahan, tetapi menggunakan metode itu sendiri ntpd (modus yatim piatu). Server bersama menyaksikan bertindak sebagai server NTP pusat, mendistribusikan waktunya ke semua cluster, sehingga menyinkronkan semua server satu sama lain. Jika menyaksikan gagal atau terisolasi, maka salah satu server cluster (di dalam cluster) akan mulai mendistribusikan waktunya. Cache tambahan HTTP proxy juga diangkat menjadi menyaksikan, dengan bantuannya, mesin virtual lain memiliki akses ke repositori Yum. Pada kenyataannya, layanan seperti waktu akurat dan proxy kemungkinan besar akan dihosting di server khusus, namun di stan layanan tersebut dihosting. menyaksikan hanya untuk menghemat jumlah mesin virtual dan ruang.

Versi

v0. Bekerja dengan CentOS 7 dan PostgreSQL 11 di VirtualBox 6.1.

Struktur cluster

Semua cluster dirancang untuk ditempatkan di beberapa pusat data, digabungkan menjadi satu jaringan datar dan harus tahan terhadap kegagalan atau isolasi jaringan dari satu pusat data. Itu sebabnya tidak mungkin digunakan untuk perlindungan terhadap otak terbelah teknologi Alat Pacu Jantung standar yang disebut STONIT (Tembak Node Lain Di Kepala) atau pagar. Esensinya: jika node dalam cluster mulai mencurigai ada sesuatu yang salah dengan beberapa node, tidak merespons atau berperilaku tidak benar, maka mereka mematikannya secara paksa melalui perangkat "eksternal", misalnya kartu kendali IPMI atau UPS . Namun ini hanya akan berfungsi jika, jika terjadi kegagalan tunggal, server IPMI atau UPS terus bekerja. Di sini kami berencana untuk melindungi terhadap kegagalan yang lebih dahsyat, ketika seluruh pusat data gagal (misalnya, kehilangan daya). Dan dengan penolakan seperti itu, semuanya bodoh-perangkat (IPMI, UPS, dll.) juga tidak akan berfungsi.

Sebaliknya, sistemnya didasarkan pada gagasan kuorum. Semua node memiliki suara, dan hanya node yang dapat melihat lebih dari separuh node yang dapat berfungsi. Besaran “setengah + 1” ini disebut jumlah anggota minimum. Jika kuorum tidak tercapai, maka node memutuskan bahwa ia berada dalam isolasi jaringan dan harus mematikan sumber dayanya, mis. ini adalah apa itu perlindungan otak terbelah. Jika perangkat lunak yang bertanggung jawab atas perilaku ini tidak berfungsi, maka pengawas, misalnya, berdasarkan IPMI, harus bekerja.

Jika jumlah node genap (cluster di dua pusat data), maka ketidakpastian dapat muncul 50% / 50% (lima puluh lima puluh) ketika isolasi jaringan membagi cluster menjadi dua. Oleh karena itu, untuk jumlah node genap, kami menambahkan perangkat kuorum adalah daemon ringan yang dapat diluncurkan pada mesin virtual termurah di pusat data ketiga. Dia memberikan suaranya pada salah satu segmen (yang dia lihat), dan dengan demikian menyelesaikan ketidakpastian 50%/50%. Saya memberi nama server tempat perangkat kuorum akan diluncurkan menyaksikan (terminologi dari repmgr, saya menyukainya).

Sumber daya dapat dipindahkan dari satu tempat ke tempat lain, misalnya, dari server yang rusak ke server yang sehat, atau atas perintah administrator sistem. Agar klien mengetahui di mana sumber daya yang mereka butuhkan berada (di mana harus terhubung?), IP mengambang (IP mengambang). Ini adalah IP yang dapat dipindahkan oleh Pacemaker di sekitar node (semuanya ada di jaringan datar). Masing-masing melambangkan sumber daya (layanan) dan akan ditempatkan di tempat Anda perlu terhubung untuk mendapatkan akses ke layanan ini (dalam kasus kami, database).

Tuchanka1 (sirkuit dengan pemadatan)

Struktur

Idenya adalah bahwa kami memiliki banyak database kecil dengan beban rendah, sehingga tidak menguntungkan untuk memelihara server budak khusus dalam mode siaga panas untuk transaksi hanya baca (tidak perlu membuang-buang sumber daya).

Setiap pusat data memiliki satu server. Setiap server memiliki dua instance PostgreSQL (dalam terminologi PostgreSQL mereka disebut cluster, tetapi untuk menghindari kebingungan saya akan menyebutnya instance (dengan analogi dengan database lain), dan saya hanya akan menyebut cluster Pacemaker sebagai cluster). Satu instance beroperasi dalam mode master, dan hanya instance tersebut yang menyediakan layanan (hanya IP float yang mengarah ke sana). Contoh kedua berfungsi sebagai budak untuk pusat data kedua, dan akan menyediakan layanan hanya jika masternya gagal. Karena seringkali hanya satu dari dua instance (master) yang akan menyediakan layanan (melakukan permintaan), semua sumber daya server dioptimalkan untuk master (memori dialokasikan untuk cache shared_buffers, dll.), tetapi agar instance kedua juga memiliki sumber daya yang cukup (walaupun untuk operasi suboptimal melalui cache sistem file) jika terjadi kegagalan salah satu pusat data. Budak tidak menyediakan layanan (tidak melakukan permintaan hanya baca) selama operasi normal cluster, sehingga tidak ada perang sumber daya dengan master di mesin yang sama.

Dalam kasus dua node, toleransi kesalahan hanya dimungkinkan dengan replikasi asinkron, karena dengan replikasi sinkron, kegagalan seorang budak akan menyebabkan penghentian master.

Kegagalan untuk menjadi saksi

Kegagalan untuk menyaksikan (perangkat kuorum) Saya akan mempertimbangkan hanya untuk cluster Tuchanka1, dengan cluster lainnya akan memiliki cerita yang sama. Jika saksi gagal, tidak ada yang berubah dalam struktur cluster, semuanya akan terus bekerja seperti semula. Namun kuorumnya akan menjadi 2 dari 3, dan oleh karena itu kegagalan berikutnya akan berakibat fatal bagi cluster. Ini masih harus segera diperbaiki.

Penolakan Tuchanka1

Kegagalan salah satu pusat data untuk Tuchanka1. Pada kasus ini menyaksikan memberikan suaranya ke node kedua di pusat data kedua. Di sana, mantan budak berubah menjadi master, sebagai hasilnya, kedua master bekerja di server yang sama dan kedua IP floatnya mengarah ke mereka.

Tuchanka2 (klasik)

Struktur

Skema klasik dua node. Tuan mengerjakan yang satu, dan budak yang kedua. Keduanya dapat menjalankan permintaan (budak hanya bisa dibaca), jadi keduanya ditunjuk oleh IP float: krogan2 adalah masternya, krogan2s1 adalah budaknya. Baik master maupun slave akan memiliki toleransi kesalahan.

Dalam kasus dua node, toleransi kesalahan hanya mungkin dilakukan dengan replikasi asinkron, karena dengan replikasi sinkron, kegagalan budak akan menyebabkan penghentian master.

Penolakan Tuchanka2

Jika salah satu pusat data gagal menyaksikan suara untuk yang kedua. Pada satu-satunya pusat data yang berfungsi, master akan dimunculkan, dan kedua IP float akan menunjuk ke sana: master dan budak. Tentu saja, instance harus dikonfigurasi sedemikian rupa sehingga memiliki sumber daya yang cukup (batas koneksi, dll.) untuk secara bersamaan menerima semua koneksi dan permintaan dari IP float master dan slave. Artinya, pada saat pengoperasian normal harus mempunyai batas persediaan yang cukup.

Tuchanka4 (banyak budak)

Struktur

Sudah ekstrem lainnya. Ada database yang menerima banyak permintaan read-only (kasus umum dari situs dengan beban tinggi). Tuchanka4 adalah situasi di mana mungkin ada tiga atau lebih budak untuk menangani permintaan tersebut, namun tetap tidak terlalu banyak. Dengan jumlah budak yang sangat besar, maka perlu diciptakan sistem replikasi hierarki. Dalam kasus minimum (dalam gambar), masing-masing dari dua pusat data memiliki dua server, masing-masing dengan instance PostgreSQL.

Fitur lain dari skema ini adalah dimungkinkannya untuk mengatur satu replikasi sinkron. Ini dikonfigurasi untuk mereplikasi, jika memungkinkan, ke pusat data lain, bukan ke replika di pusat data yang sama dengan master. Master dan masing-masing budak ditunjuk oleh IP float. Untungnya, antar budak perlu menyeimbangkan permintaan proksi sql, misalnya, di sisi klien. Jenis klien yang berbeda mungkin memerlukan jenis yang berbeda proksi sql, dan hanya pengembang klien yang mengetahui siapa yang membutuhkan yang mana. Fungsionalitas ini dapat diimplementasikan baik oleh daemon eksternal atau oleh perpustakaan klien (kumpulan koneksi), dll. Semua ini melampaui topik cluster database failover (failover proksi SQL dapat diimplementasikan secara mandiri, bersama dengan toleransi kesalahan klien).

Penolakan Tuchanka4

Jika satu pusat data (yaitu, dua server) gagal, saksikan pemungutan suara untuk pusat data kedua. Hasilnya, ada dua server yang berjalan di pusat data kedua: satu menjalankan master, dan IP float master menunjuk ke sana (untuk menerima permintaan baca-tulis); dan di server kedua ada budak yang berjalan dengan replikasi sinkron, dan salah satu IP float budak menunjuk ke sana (untuk permintaan hanya baca).

Hal pertama yang perlu diperhatikan adalah tidak semua IP float budak akan menjadi pekerja, tetapi hanya satu. Dan untuk bekerja dengannya dengan benar, diperlukan hal itu proksi sql mengalihkan semua permintaan ke satu-satunya IP float yang tersisa; dan jika proksi sql tidak, maka Anda dapat mencantumkan semua budak IP mengambang yang dipisahkan dengan koma di URL koneksi. Dalam hal ini, dengan libpq koneksi akan ke IP pertama yang berfungsi, ini dilakukan dalam sistem pengujian otomatis. Mungkin di perpustakaan lain, misalnya JDBC, ini tidak akan berfungsi dan diperlukan proksi sql. Hal ini dilakukan karena IP float untuk slave dilarang dimunculkan secara bersamaan di satu server, agar merata di antara server slave jika ada beberapa yang berjalan.

Kedua: bahkan jika terjadi kegagalan pusat data, replikasi sinkron akan tetap terjaga. Dan bahkan jika terjadi kegagalan sekunder, yaitu salah satu dari dua server di pusat data yang tersisa gagal, cluster, meskipun akan berhenti menyediakan layanan, akan tetap menyimpan informasi tentang semua transaksi yang dilakukan yang telah memberikan konfirmasi penerapannya. (tidak akan ada informasi kerugian jika terjadi kegagalan sekunder).

Tuchanka3 (3 pusat data)

Struktur

Ini adalah cluster untuk situasi dimana terdapat tiga pusat data yang berfungsi penuh, masing-masing memiliki server database yang berfungsi penuh. Pada kasus ini perangkat kuorum tidak dibutuhkan. Satu pusat data dikelola oleh seorang master, dua lainnya dikelola oleh budak. Replikasi bersifat sinkron, ketik APAPUN (slave1, slave2), yaitu klien akan menerima konfirmasi komit ketika salah satu budak adalah yang pertama merespons bahwa ia telah menerima komit. Sumber daya ditunjukkan dengan satu IP float untuk master dan dua untuk budak. Tidak seperti Tuchanka4, ketiga IP float ini toleran terhadap kesalahan. Untuk menyeimbangkan kueri SQL read-only yang dapat Anda gunakan proksi sql (dengan toleransi kesalahan terpisah), atau tetapkan satu IP float budak ke separuh klien, dan separuh lainnya ke klien kedua.

Penolakan Tuchanka3

Jika salah satu pusat data rusak, tersisa dua lagi. Dalam satu, IP master dan float dari master dinaikkan, yang kedua - IP float slave dan kedua slave (instance harus memiliki cadangan sumber daya ganda untuk menerima semua koneksi dari kedua IP float slave). Replikasi sinkron antara master dan slave. Selain itu, cluster akan menyimpan informasi tentang transaksi yang dilakukan dan dikonfirmasi (tidak akan ada informasi yang hilang) jika terjadi penghancuran dua pusat data (jika tidak dimusnahkan secara bersamaan).

Saya memutuskan untuk tidak menyertakan penjelasan rinci tentang struktur file dan penerapannya. Siapapun yang ingin bermain-main bisa membaca semuanya di README. Saya hanya memberikan penjelasan tentang pengujian otomatis.

Sistem pengujian otomatis

Untuk menguji toleransi kesalahan cluster dengan mensimulasikan berbagai kesalahan, sistem pengujian otomatis telah dibuat. Diluncurkan dengan skrip test/failure. Skrip dapat mengambil parameter jumlah cluster yang ingin Anda uji. Misalnya perintah ini:

test/failure 2 3

hanya akan menguji cluster kedua dan ketiga. Jika parameter tidak ditentukan, maka semua cluster akan diuji. Semua cluster diuji secara paralel, dan hasilnya ditampilkan di panel tmux. Tmux menggunakan server tmux khusus, sehingga skrip dapat dijalankan dari bawah tmux default, menghasilkan tmux bersarang. Saya sarankan menggunakan terminal di jendela besar dan dengan font kecil. Sebelum pengujian dimulai, semua mesin virtual dikembalikan ke snapshot pada saat skrip selesai setup.

Terminal dibagi menjadi beberapa kolom sesuai dengan jumlah cluster yang diuji; secara default (di tangkapan layar) ada empat. Saya akan menjelaskan isi kolom menggunakan contoh Tuchanka2. Panel di tangkapan layar diberi nomor:

1. Statistik pengujian ditampilkan di sini. Kolom:
   • kegagalan — nama pengujian (fungsi dalam skrip) yang mengemulasi kesalahan.
   • reaksi — waktu rata-rata aritmatika dalam hitungan detik selama klaster memulihkan fungsinya. Hal ini diukur dari awal skrip yang meniru kesalahan hingga saat cluster memulihkan fungsinya dan dapat terus menyediakan layanan. Jika waktunya sangat singkat, misalnya enam detik (ini terjadi dalam cluster dengan beberapa budak (Tuchanka3 dan Tuchanka4)), ini berarti kesalahan ada pada budak asinkron dan tidak mempengaruhi kinerja dengan cara apa pun; tidak ada saklar status cluster.
   • penyimpangan — menunjukkan penyebaran (akurasi) nilai reaksi menggunakan metode deviasi standar.
   • menghitung — berapa kali tes ini dilakukan.
2. Log singkat memungkinkan Anda mengevaluasi apa yang sedang dilakukan klaster. Nomor iterasi (pengujian), stempel waktu, dan nama operasi ditampilkan. Berjalan terlalu lama (> 5 menit) menunjukkan adanya masalah.
3. jantung (hati) - waktu saat ini. Untuk penilaian visual kinerja master Waktu saat ini terus-menerus ditulis ke tabelnya menggunakan master IP float. Jika berhasil, hasilnya akan ditampilkan di panel ini.
4. mengalahkan (pulsa) - "waktu saat ini", yang sebelumnya direkam oleh skrip jantung untuk dikuasai, sekarang bacalah budak melalui IP float-nya. Memungkinkan Anda menilai kinerja budak dan replikasi secara visual. Di Tuchanka1 tidak ada budak dengan IP float (tidak ada budak yang menyediakan layanan), tetapi ada dua instance (DB), jadi tidak akan ditampilkan di sini mengalahkanDan jantung contoh kedua.
5. Memantau kesehatan cluster menggunakan utilitas pcs mon. Menunjukkan struktur, distribusi sumber daya di seluruh node, dan informasi berguna lainnya.
6. Pemantauan sistem dari setiap mesin virtual di cluster ditampilkan di sini. Mungkin terdapat lebih banyak panel seperti itu bergantung pada berapa banyak mesin virtual yang dimiliki cluster. Dua grafik Beban CPU (mesin virtual memiliki dua prosesor), nama mesin virtual, Beban Sistem (dinamakan Load Average karena dirata-ratakan selama 5, 10 dan 15 menit), memproses data dan alokasi memori.
7. Jejak skrip yang melakukan pengujian. Jika terjadi malfungsi - gangguan pengoperasian secara tiba-tiba atau siklus menunggu tanpa akhir - di sini Anda dapat melihat alasan perilaku ini.

Pengujian dilakukan dalam dua tahap. Pertama, skrip melewati semua jenis pengujian, secara acak memilih mesin virtual untuk menerapkan pengujian ini. Kemudian siklus pengujian tanpa akhir dilakukan, mesin virtual dan kesalahannya dipilih secara acak setiap saat. Penghentian skrip pengujian secara tiba-tiba (panel bawah) atau pengulangan menunggu sesuatu yang tiada henti (> 5 menit waktu eksekusi untuk satu operasi, hal ini dapat dilihat di jejak) menunjukkan bahwa beberapa pengujian pada cluster ini telah gagal.

Setiap tes terdiri dari operasi berikut:

1. Luncurkan fungsi yang mengemulasi kesalahan.
2. Siap? — menunggu cluster dipulihkan (ketika semua layanan disediakan).
3. Menampilkan batas waktu pemulihan klaster (reaksi).
4. Memperbaiki — cluster sedang “diperbaiki.” Setelah itu, ia akan kembali ke kondisi operasional penuh dan siap menghadapi malfungsi berikutnya.

Berikut adalah daftar tes dengan penjelasan tentang fungsinya:

• Bom Garpu: Membuat "Kehabisan memori" menggunakan bom garpu.
• Di Luar Angkasa: Harddisk penuh. Namun pengujian ini lebih bersifat simbolis; dengan sedikit beban yang dihasilkan selama pengujian, PostgreSQL biasanya tidak gagal ketika hard drive penuh.
• Postgres-BUNUH: membunuh PostgreSQL dengan perintah killall -KILL postgres.
• Postgres-BERHENTI: hang perintah PostgreSQL killall -STOP postgres.
• Matikan: “mematikan energi” mesin virtual dengan perintah VBoxManage controlvm "виртуалка" poweroff.
• ulang: membebani mesin virtual dengan perintah VBoxManage controlvm "виртуалка" reset.
• SBD-BERHENTI: menangguhkan setan SBD dengan perintah killall -STOP sbd.
• Matikan: mengirimkan perintah ke mesin virtual melalui SSH systemctl poweroff, sistem dimatikan dengan baik.
• Putuskan Tautan: isolasi jaringan, perintah VBoxManage controlvm "виртуалка" setlinkstate1 off.

Menyelesaikan pengujian menggunakan perintah tmux standar "kill-window" Ctrl-b &, atau perintah "detach-client". Ctrl-b d: pada titik ini pengujian berakhir, tmux ditutup, mesin virtual dimatikan.

Masalah yang diidentifikasi selama pengujian

• Saat ini setan pengawas sbd bekerja untuk menghentikan daemon yang diamati, tetapi tidak membekukannya. Dan akibatnya, kesalahan yang menyebabkan pembekuan saja Korosinkronisasi и Pacemaker, tapi tidak menggantung sbd. Untuk pemeriksaan Korosinkronisasi sudah punya PR # 83 (di GitHub di sbd), diterima di thread menguasai. Mereka berjanji (di PR#83) akan ada yang serupa untuk Alat Pacu Jantung, saya harap begitu topi merah 8 akan melakukan. Namun “kerusakan” tersebut bersifat spekulatif dan dapat dengan mudah disimulasikan secara artifisial dengan menggunakan, misalnya, killall -STOP corosync, tapi tidak pernah bertemu di kehidupan nyata.

• У Pacemaker dalam versi untuk 7 CentOS diatur secara tidak benar sinkronisasi_waktu habis у perangkat kuorum, hasil dari jika satu node gagal, dengan kemungkinan tertentu node kedua juga akan di-boot ulang, ke mana tuannya seharusnya pindah. Disembuhkan dengan pembesaran sinkronisasi_waktu habis у perangkat kuorum selama penerapan (dalam skrip setup/setup1). Amandemen ini tidak diterima oleh pengembang Pacemaker, sebaliknya mereka berjanji untuk mendesain ulang infrastruktur sedemikian rupa (di masa depan yang tidak ditentukan) sehingga batas waktu ini akan dihitung secara otomatis.

• Jika konfigurasi database menentukan itu LC_MESSAGES (pesan teks) Unicode dapat digunakan, mis. ru_RU.UTF-8, lalu saat startup postgres di lingkungan yang lokalnya bukan UTF-8, katakanlah di lingkungan kosong (di sini perintis+pgsqlms(paf) berlari postgres), kemudian log akan berisi tanda tanya, bukan huruf UTF-8. Pengembang PostgreSQL belum menyetujui apa yang harus dilakukan dalam kasus ini. Biayanya, Anda perlu menginstal LC_MESSAGES=en_US.UTF-8 saat mengonfigurasi (membuat) instance database.

• Jika wal_receiver_timeout disetel (secara default adalah 60 detik), maka selama pengujian PostgreSQL-STOP pada master di cluster tuchanka3 dan tuchanka4 replikasi tidak menyambung kembali ke master baru. Replikasi di sana sinkron, jadi tidak hanya slave yang berhenti, tapi juga master baru. Mengatasinya dengan mengatur wal_receiver_timeout=0 saat mengonfigurasi PostgreSQL.

• Kadang-kadang saya mengamati replikasi macet di PostgreSQL dalam pengujian ForkBomb (memori meluap). Setelah ForkBomb, terkadang budak tidak dapat terhubung kembali ke master baru. Saya hanya menemukan ini di cluster tuchanka3 dan tuchanka4, di mana master membeku karena replikasi sinkron. Masalahnya hilang dengan sendirinya setelah sekian lama (sekitar dua jam). Diperlukan lebih banyak penelitian untuk memperbaiki hal ini. Gejalanya mirip dengan bug sebelumnya, yaitu disebabkan oleh alasan yang berbeda, namun dengan akibat yang sama.

Gambar Krogan diambil dari Deviant Art dengan izin dari penulis:

Sumber: www.habr.com