logoChat01.ai

image.png am 2 servre 10.0.0.10 principal si 10.0...

Creato il: 9 dicembre 2025

Risposto usando GPT-5.1 Thinking da Chat01

Domanda

image.png

am 2 servre 10.0.0.10 principal si 10.0.0.11 unde vreau sa fac replica la serverul ERP cu sql 2022

Pensiero

Providing SQL replication setup in Romanian

User wants guidance on replicating an ERP server with SQL 2022. I’ll respond in Romanian, offering a concise and structured explanation for replication using Always On, or log shipping if no domain or cluster exists. I'll briefly mention prerequisites, such as both servers needing to be in the same domain.

Structuring the answer for ERP SQL Server replication

I’ll start with a brief greeting and then provide two main approaches for SQL Server 2022 replication: Always On Availability Groups (for HA with failover) or Log Shipping (for DR with manual failover). Since they mentioned "replica," I’ll focus on Always On, offering clear steps assuming they use Windows Server and AD domain. I'll mention prerequisites like patch levels, collation, and the Windows Server Failover Cluster.

Providing setup steps for Always On Availability Groups

First, configure the Windows Server Failover Cluster (WSFC) with both servers. Shared storage isn’t required for Always On AG. Next, enable Always On feature using SQL Server Configuration Manager, then prepare the ERP database by setting up the recovery model and backing up on the primary server before restoring the backups on the secondary.

Setting up Always On AG and log shipping alternative

To set up an Availability Group (AG), use SQL Server Management Studio (SSMS) to connect to the primary server, create a new AG, and configure replicas. If needed, also set up a listener. Test failover to verify AG health, but avoid doing so in production hours. Alternatively, if cluster setup isn’t feasible, log shipping could be an option, requiring a full recovery model, shared folder, and SQL Agent.

Explaining AG vs. Log Shipping for ERP replication

For ERP replication, if you're using SQL Server Standard/Enterprise and Active Directory, Always On AG is the best choice for high availability. If not, opt for log shipping, though it involves manual failover. Ensure both firewalls allow SQL port 1433 for replication. Guides are available inline in the sources used.

Thought for 3m 19s

Risposta

Ai două variante principale ca să ai o „replică” a serverului ERP între
10.0.0.10 (principal) și 10.0.0.11 (secundar), cu SQL Server 2022:

  1. Always On Availability Groups – recomandat pentru ERP, cu failover aproape automat. (Microsoft Learn)
  2. Log Shipping – mai simplu, fără cluster, dar failover manual. (Microsoft Learn)

Mai jos îți arăt pașii pentru ambele. Alege ce se potrivește mediului tău (domeniu AD vs. workgroup, Standard/Enterprise etc.).

1. Variantă recomandată: Always On Availability Group (HA pentru ERP)

1.1. Prerechizite

Pe ambele servere (10.0.0.10 și 10.0.0.11):

  • Windows Server în același domeniu AD.
  • SQL Server 2022 aceeași versiune/patch pe ambele. (Microsoft Learn)
  • Baza de date ERP în FULL recovery model. (Microsoft Learn)
  • Configurat Windows Server Failover Cluster (WSFC) cu cei doi noduri (nu ai nevoie de storage partajat pentru AG). (ComputingForGeeks)

1.2. Activezi Always On pe instanțele SQL

Pe fiecare server:

  1. Deschizi SQL Server Configuration Manager.
  2. Mergi la SQL Server Services → click dreapta pe instanța ta → Properties.
  3. Tab Always On High Availability → bifezi Enable Always On availability groups.
  4. Dai OK și restart la serviciul SQL Server. (Microsoft Learn)

1.3. Pregătești baza de date ERP pe 10.0.0.10

În SSMS, conectat la 10.0.0.10:

  1. ERP → Properties → Options → Recovery model = FULL.
  2. Faci un FULL backup al bazei de date ERP.
  3. Faci și un Transaction Log backup după full. (Microsoft Learn)
  4. Copiezi aceste backup-uri pe serverul 10.0.0.11 (într-un share accesibil).

1.4. Restore pe serverul secundar 10.0.0.11

Pe 10.0.0.11 în SSMS:

  1. Restore Database din backupul FULL, cu opțiunea NORECOVERY.
  2. Restore Log (transaction log) tot cu NORECOVERY.

Baza de date ERP pe secundar trebuie să rămână în starea Restoring… – exact așa trebuie pentru AG.

1.5. Creezi Availability Group în SSMS

Pe 10.0.0.10:

  1. În SSMS: Always On High Availability → click dreapta pe Availability Groups →
    New Availability Group Wizard. (Microsoft Learn)
  2. Dai un nume, de ex. AG_ERP.
  3. Bifezi baza de date ERP.
  4. La Replicas:
    • Primary: instanța de pe 10.0.0.10.
    • Adaugi replica secundară: serverul 10.0.0.11.
    • Setezi:
      • Synchronous commit (pentru HA).
      • Automatic failover (dacă folosești ediția care permite, de obicei Standard/Enterprise). (Microsoft Learn)
  5. La Initial Data Synchronization:
    • fie alegi Join only (dacă ai restaurat deja manual backup-urile),
    • fie lași wizard-ul să facă backup & restore automat prin share.
  6. Finalizezi wizard-ul.

1.6. Listener (opțional, dar foarte util pentru ERP)

Ca ERP-ul să nu știe care server e activ, creezi un Availability Group Listener:

  1. În SSMS, la Availability Group → Add Listener.
  2. Nume de ex. ERP-SQL-LSTN.
  3. Setezi portul (de obicei 1433) și IP-ul din subnet-ul tău. (Microsoft Learn)

Apoi, în aplicația ERP, pui în connection string numele listener-ului, nu IP-ul serverului. La failover, aplicația se reconectează automat.

1.7. Test rapid

  1. Verifici Availability Group Dashboard (SSMS) – totul trebuie să fie „Healthy”. (Microsoft Learn)
  2. Faci un manual failover (în afara orelor de producție):
    • click dreapta pe AG → Failover → alegi 10.0.0.11.
  3. Verifici că ERP se conectează prin listener și funcționează pe secundar.

2. Variantă mai simplă: Log Shipping (dacă nu ai cluster/AD)

Dacă nu poți/nu vrei WSFC, poți face Log Shipping între 10.0.0.10 (primary) și 10.0.0.11 (secondary).

2.1. Prerechizite

  • Baza ERP în FULL sau BULK_LOGGED recovery model. (Microsoft Learn)
  • Un share de fișiere accesibil din ambele servere (ex: \\10.0.0.10\LSBackups).
  • SQL Server Agent pornit pe ambele servere. (Microsoft Learn)

2.2. Configurezi Log Shipping din SSMS

Pe 10.0.0.10:

  1. Click dreapta pe baza ERP → Properties → pagina Transaction Log Shipping.
  2. Bifezi Enable this as a primary database in a log shipping configuration.
  3. La Backup Settings:
    • alegi folderul de backup (ex: \\10.0.0.10\LSBackups).
    • setezi frecvența (ex: la 5 minute). (Microsoft Learn)
  4. La Secondary → Add:
    • alegi serverul 10.0.0.11.
    • setezi Copy job (de unde copie logurile și unde le pune local).
    • setezi Restore job:
      • mod NoRecovery (dacă vrei strict DR, fără acces la baza de date),
      • sau Standby / read-only (dacă vrei rapoarte în secundar). (SQL Shack)
  5. Activezi și jobul de monitorizare, dacă vrei alertare.

Log shipping nu face failover automat – dacă moare 10.0.0.10, trebuie să aduci manual baza ERP online pe 10.0.0.11 cu RESTORE DATABASE ... WITH RECOVERY și să schimbi connection string/DNS în ERP. (GitHub)

Concluzie (ce ți-aș recomanda)

  • Dacă ai domeniu AD, ediție Standard/Enterprise și poți face WSFC →
    mergi pe Always On Availability Group între 10.0.0.10 și 10.0.0.11. E cel mai potrivit pentru un ERP.

  • Dacă infrastructura e mai simplă (workgroup, fără cluster) →
    Log Shipping e varianta practică pentru a avea o replică pe 10.0.0.11 și posibilitate de DR.

Dacă îmi spui ce ediție de SQL Server ai (Standard/Enterprise) și dacă serverele sunt în domeniu sau nu, pot să îți detaliez exact varianta ideală pentru setup-ul tău actual (scripturi T-SQL, setări la firewall, etc.).

Condividi questa Q&A