Puncte:1

Este posibilă migrarea între două discuri fizice fără (mult) timp de nefuncționare?

drapel de

Am un server cu o bază de date de dimensiuni medii pe un disc care se umple. Nu există LVM sau RAID sau ceva asemănător în joc în acest moment. Am deja noul disc instalat pe server.

Este posibilă migrarea datelor pe noul disc fizic cu un timp de nefuncționare minim sau deloc? Am efectuat un test de viteză de copiere de pe vechea unitate pe cea nouă și va dura câteva ore. Nu strict vorbind un deal-breaker, dar aș dori să fac mai bine dacă este posibil.

Am câteva idei și aș dori să știu care ar putea fi fezabilitatea fiecăreia.

  1. Migrați la LVM. Dacă este posibil să migrați o partiție goală la una LVM (este!?), atunci este o partiție simplă. pvmove pentru a trece pe noul disc fără niciun timp de nefuncționare. Mă bat cu piciorul pentru că nu am folosit LVM la momentul respectiv. :/

  2. Utilizați dm-raid pentru a oglindi de pe discul existent pe noul disc, așteptați sincronizarea, apoi întrerupeți raid-ul și aruncați discul vechi. Acest lucru necesită suficient timp de nefuncționare pentru a remonta sistemul de fișiere de pe dispozitivul fizic pe dispozitivul de cartografiere a dispozitivului. „Problema” aici, atunci, este că aș avea un strat RAID pe care nu îl foloseam după ce am spus și s-a făcut totul. De asemenea, nu obțin flexibilitatea LVM folosind această configurare.

O altă opțiune este configurarea unui nou server (sau chiar doar un serviciu nou pe același server) și utilizarea capacităților de replicare ale bazei de date (PostgreSQL în acest caz), dar asta pare a fi mult mai mult decât este necesar.

Mat avatar
drapel cn
Mat
Alternativa la replicare ar fi configurarea de noi tablespace și mutarea obiectelor de la vechi la nou. (Dar nu cunosc suficient Postgres - ar putea suferi multă blocare.)
djdomi avatar
drapel za
bazele de date nu ar trebui să fie copiate direct atâta timp cât sunt utilizate, aș sugera un timp de nefuncționare într-un weekend și să dd harddisk-ul complet și să-l extind ulterior. Amintiți-vă că, în caz de raid și backup, sunteți cu adevărat prost și aveți un impact mai mare ca acesta
drapel de
@djdomi Nu sugeram să copiem datele de sub o bază de date care rulează. Caut în mod special opțiuni pentru subsistemul de fișiere, aici. Testul meu inițial de citire/scriere a folosit doar `cp -r` pentru a vedea cât timp va dura.Ne-am gândit să folosim `rsync` de două ori (o dată online, o dată după), dar am decis că viteza de citire a vechii unități este blocajul și ar trebui să citim 100% atât din sursă, cât și din țintă pentru a realiza o rsync „diferențial” în timpul nefuncționării, deci nu există niciun beneficiu real.
drapel de
@Mat Mutarea obiectelor dintr-un spațiu de masă în altul ar putea funcționa, dar aplicația de deasupra db-ului nu acceptă așa ceva și nu cunosc PostgreSQL suficient de bine pentru a migra astfel de date în uz.
A.B avatar
drapel cl
A.B
Voi pune înapoi acest link pe care am ezitat să îl pun, pentru că necesită multă unsoare de cot pentru a-l face bine: https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm -clone.html . avertisment: [Actualizarea metadatelor de pe disc](https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-clone.html#updating-on-disk-metadata). Ar necesita doar un timp scurt de nefuncționare pentru a comuta dispozitivul de bază al FS. Cu mai multă unsoare de cot, ținta ar putea fi un LVM PV/LV pregătit în avans. Apoi, odată ce totul este migrat, al doilea mic timp de nefuncționare pentru a se ajusta din nou.
drapel de
@A.B `dm-clone` arată ca ceea ce caut.Îmi puteți confirma că (1) opresc serviciul/db-ul, remontează fs-ul existent numai în citire, creez clona dm de pe dispozitivul vechi->nou, remontez astfel încât lucrurile să arate ca înainte, apoi (2) repornesc serviciile și lăsați hidratarea să se finalizeze, apoi (3) în orice moment după finalizarea hidratării, pot elimina vechiul dispozitiv și dm-clone fs și pot trece doar la utilizarea celui nou?
A.B avatar
drapel cl
A.B
nu ai remonta fs-ul doar în citire. Veți pregăti noul bloc la țintă cu un link (folosind caracteristici de clonare) către vechiul dispozitiv de bloc și apoi veți monta direct fs-ul în noul loc. hidratarea poate funcționa în timpul operațiunilor de bază de date. Probabil că puteți reuși ca ținta să folosească blocurile exacte ale unui LV pregătit în avans, astfel încât mai târziu să aveți disponibile funcții LVM
drapel de
@A.B Am întrebat despre doar citire pentru că nu aș vrea ca sistemul de fișiere sursă să fie modificat în timpul operației de copiere activă. Presupun că ar putea fi complet demontat, de fapt, deoarece dm-clone va funcționa oricum la nivel de bloc.
drapel de
Pentru o țintă LVM, pot specifica blocarea țintei pentru a evita suprascrierea antetului LVM pe dispozitivul țintă? Sună interesant într-adevăr. Teoretic, totuși, aș putea, de asemenea, să clonez sursa către țintă, unde ținta este deja un volum logic LVM, deoarece dispozitivul sursă în sine nu conține altceva decât sistemul de fișiere și volumul logic ar fi similar.
A.B avatar
drapel cl
A.B
Da, asta a fost implicat: sursa este doar pentru citire odată ce nimic nu o folosește. Pentru a evita erorile de manipulare, puteți forța un dispozitiv de blocare să fie doar citit cu `blockdev --setro`. Și da, puteți alege LV-ul în sine să fie partea de destinație a clonei dm.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.