Átállási kapcsolat – Azure SQL Managed Instance

A következőre vonatkozik: :Azure SQL Managed Instance

Ez a cikk bemutatja, hogyan lehet áthelyezést végrehajtani egy összekapcsolt adatbázison az SQL Server és az Azure SQL Managed Instance között, SQL Server Management Studio (SSMS) vagy PowerShell használatával, vészhelyreállítás vagy migrálás céljából.

Előfeltételek

Ha a hivatkozáson keresztül szeretné átváltani adatbázisait a másodlagos replikára, a következő előfeltételekre van szüksége:

• Aktív Azure előfizetés. Ha nem rendelkezik ilyen fiókkal, hozzon létre egy ingyenes fiókot.
• A SQL Server telepítve van a szükséges szolgáltatásfrissítés.
• Link konfigurálva az elsődleges és a másodlagos replika között.
• Az SQL Server 2022 CU13 (KB5036432) kiadástól kezdve Transact-SQL-lel átkapcsolhatja a kapcsolatot.

Feladat leállítása

Ha készen áll arra, hogy feladatátvételt végez az adatbázison a másodlagos replikán, először állítsa le az elsődleges replika összes alkalmazásterhelését a karbantartási órákban. Ez lehetővé teszi, hogy az adatbázis replikálás a másodlagos adatbázison utolérje magát, így adatvesztés nélkül átválthat a másodlagos adatbázisra. Győződjön meg róla, hogy az alkalmazásai nem véglegesítik a tranzakciókat az elsődleges kiszolgálóra a feladatátvétel előtt.

Replikáció késésének ellenőrzése

Fontos, hogy a másodlagos replika a tervezett feladatátvétel végrehajtása előtt utolérje az elsődleges replikát. A tervezett feladatátvétel időtúllépést és meghiúsulást okozhat, ha a másodlagos replika messze elmarad az elsődleges replika mögött.

A replikák közötti replikáció késésének figyeléséhez használja a következő T-SQL-lekérdezést SQL Server és SQL Managed Instance:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

Ha a replikáció késése magas, várja meg, amíg a szekunder példány felzárkózik a primer példánnyal. Előfordulhat, hogy további hibaelhárítási lépéseket kell végrehajtania, ha a késés továbbra is fennáll, például javítania kell a kapcsolati hálózati átviteli sebességet a két példány között, vagy növelnie kell az erőforrás-kapacitást a másodlagos replikán.

Adatbázis feladatátvétele

A csatolt adatbázisok feladatátvételét Transact-SQL (T-SQL), SQL Server Management Studio vagy PowerShell használatával végezheti el.

Transact-SQL

Az SQL Server 2022 CU13 (KB5036432) kiadástól kezdve Transact-SQL-lel átkapcsolhatja a kapcsolatot.

Egy kapcsolat tervezett átállásának végrehajtásához az elsődleges replikán használja a következő T-SQL parancsot:

ALTER AVAILABILITY GROUP [<DAGname>] FAILOVER

Kényszerített átállás végrehajtásához használja a következő T-SQL parancsot a másodlagos replikán:

ALTER AVAILABILITY GROUP [<DAGname>] FORCE_FAILOVER_ALLOW_DATA_LOSS

SQL Server Management Studio (SSMS)

Az SSMS SQL Server és a Managed Instance közötti átváltás varázslójával az adatbázisát átállíthatja az elsődleges replikáról a másodlagos replikára.

Tervezett feladatátvételt az elsődleges vagy a másodlagos replikánál is hajthat végre. Kényszerített átkapcsoláshoz csatlakozzon a másodlagos replikához.

Vigyázat!

• Átállás előtt állítsa le a terhelést a forrásadatbázison, hogy a replikált adatbázis teljes mértékben felzárkózhasson, és átállhasson adatvesztés nélkül. Ha kényszerített feladatátvételt hajt végre, előfordulhat adatvesztés.
• A 2019- SQL Server és a korábbi verziók adatbázisának feladatátvétele megszakad, és eltávolítja a két replika közötti kapcsolatot. Nem lehet visszalépni a kezdeti elsődlegesre.

Az adatbázis átkapcsolásához kövesse az alábbi lépéseket:

1. Nyissa meg az SSMS-t, és csatlakozzon bármelyik replikához.

2. A Object Explorer kattintson a jobb gombbal a replikált adatbázisra, mutasson a Azure SQL Managed Instance hivatkozásra, és válassza a Failover... a A SQL Server és a Managed Instance varázsló közötti kapcsolat megnyitásához. Ha ugyanabból az adatbázisból több hivatkozás is található, bontsa ki a A rendelkezésre állási csoportok elemet a Always On rendelkezésre állási csoportok területen Object Explorer és kattintson a jobb gombbal a feladatátvételre használni kívánt hivatkozás elosztott rendelkezésre állási csoportjára. Válassza a Failover... lehetőséget, hogy megnyissa az SQL Server és Managed Instance közötti failovert a varázslóhoz.

   

3. A Bevezetés lapon válassza a Következőlehetőséget.

4. A Feladatátvételi típus kiválasztása lapon megtekintheti az egyes replikák részleteit, a kiválasztott adatbázis szerepkörét és a támogatott feladatátvételi típusokat. A feladatátvételt bármelyik replikáról kezdeményezheti. Ha kényszerített feladatátvételt választ, jelölje be a jelölőnégyzetet annak jelzésére, hogy tisztában van az esetleges adatvesztés kockázatával. Válassza Következő.

   Jegyzet

   Ha az Azure SQL Managed Instance-re telepít át, válassza a Tervezett feladatátvétel lehetőséget.

5. A Bejelentkezés az Azure-ba és a távoli példányba oldal:

   1. Válassza a Sign-in lehetőséget a hitelesítő adatok megadásához és a Azure-fiókba való bejelentkezéshez.
   2. Az előző lapon kiválasztott feladatátvételi típus alapján a Bejelentkezés opció másképp működik. Tervezett átkapcsolás esetén az SQL Server vagy az SQL Managed Instance távoli példányába való bejelentkezés kötelező. kényszerített átállásesetén az aláírás nem kötelező, mert a következő két forgatókönyv támogatott:
      • Valódi katasztrófa utáni helyreállítás: Mivel az elsődleges példány általában nem érhető el egy valódi katasztrófa során, a bejelentkezés nem lehetséges, és a felhasználónak azonnal át kell váltania a másodlagos példányra, amely így az új elsődleges példány lesz. A kimaradás feloldása után a kapcsolat inkonzisztens állapotban van, mivel mindkét replika az elsődleges szerepkörben van (osztott agy forgatókönyv).
      • vészhelyreállítási próba: A vészhelyreállítási próbák kényszerített átállással való végrehajtása nem ajánlott, mivel adatvesztés lehetséges. Azonban egy gyakorlat során, mivel az elsődleges példány elérhető, a bejelentkezés támogatott, és lehetősége van a szerepkörök felcserélésére mindkét replikához, hogy elkerülje a hasadt agy helyzetet.

6. A Feladatátvétel utáni műveletek lapon a beállítások eltérnek a SQL Server 2022 és a korábbi verziók között, illetve hogy tudott-e csatlakozni az elsődleges példányhoz.

   • A SQL Server 2022 esetén leállíthatja a replikák közötti replikációt, amely a feladatátvétel befejezése után megszünteti a kapcsolatot és az elosztott rendelkezésre állási csoportot. Ha meg szeretné őrizni a kapcsolatot, és folytatni kívánja az adatok replikálását a replikák között, ne jelölje be a jelölőnégyzetet. Ha úgy dönt, hogy elveti a hivatkozást, akkor a jelölőnégyzet bejelölésével is elvetheti a rendelkezésre állási csoportot, ha csak azért hozta létre, hogy replikálja az adatbázist Azure, és már nincs rá szüksége. Válassza ki a forgatókönyvének megfelelő jelölőnégyzeteket, majd kattintson a Következőgombra.
   • A SQL Server 2019 és korábbi verziók esetén az A hivatkozás eltávolítása opció alapértelmezés szerint be van jelölve, és nem törölheti a jelölést, mivel az SQL Managed Instance-ra történő átállás leállítja a replikációt, megszakítja a hivatkozást, és elveti az elosztott rendelkezésre állási csoportot. Jelölje be a jelölőnégyzetet annak jelzésére, hogy tudomásul veszi, hogy a hivatkozás el lesz távolítva, majd válassza a Továbblehetőséget.
   • (Opcionálisan) Ha az előző oldalon be tudott jelentkezni a SQL Server példányba, lehetősége van törölni az SQL Server példány rendelkezésre állási csoportját is egy kényszerített feladatátvétel után a Lean-up szakaszban található jelölőnégyzet bejelölésével.

7. Az Összegzés lapon tekintse át a műveleteket. Opcionálisan válassza a szkript opciót szkript létrehozásához, hogy a jövőben könnyen átválthassa az adatbázist ugyanazon hivatkozás használatával. Válassza a Befejezés lehetőséget, ha készen áll az adatbázis átváltására.

8. Miután az összes lépés befejeződött, az Eredmények lapon pipák láthatók a sikeresen végrehajtott műveletek mellett. Most már bezárhatja az ablakot.

Ha úgy döntött, hogy fenntartja a SQL Server 2022 hivatkozását, a másodlagos válik az új elsődlegessé, a hivatkozás továbbra is aktív, és vissza lehet állítani a másodlagos státuszát.

Ha az SQL Server 2019 vagy korábbi verzióját használja, vagy ha úgy döntött, hogy elveti a hivatkozást az SQL Server 2022 esetében, akkor a hivatkozás a feladatátvétel befejeztével elvetésre kerül, és már nem fog létezni. Az egyes replikák forrásadatbázisa és céladatbázisa egyaránt képes olvasási/írási számítási feladat végrehajtására. Teljesen függetlenek.

Fontos

Miután sikeresen megtörtént az átállás az SQL Managed Instance-re, manuálisan állítsa be az alkalmazás(ok) connection string-jét az SQL Managed Instance teljes tartománynévre a migrálás vagy átállási folyamat befejezéséhez, majd futtassa tovább az Azure-ban.

PowerShell

A feladatátvételhez először át kell váltania a SQL Server példányának replikációs módját a Transact-SQL (T-SQL) használatával.

Ezután a PowerShell használatával feladatátvételt végezhet, és szerepköröket válthat.

Replikációs mód váltása (átirányítás SQL MI-re)

A SQL Server és SQL Managed Instance közötti replikáció alapértelmezés szerint aszinkron. Átváltás előtt a SQL Serverről az Azure SQL Managed Instance-re, kapcsolja át a hivatkozást szinkronizált módba az SQL Server Transact-SQL (T-SQL) segítségével.

Jegyzet

• Hagyja ki ezt a lépést, ha az SQL Managed Instance feladatátvételt hajt végre az SQL Server 2022-re.
• A nagy hálózati távolságok közötti szinkron replikáció lelassíthatja az elsődleges replika tranzakcióit.

Futtassa a következő T-SQL-szkriptet a SQL Server-en az elosztott rendelkezésre állási csoport replikációs módjának aszinkronról szinkronra való módosításához. Helyettesít:

• <DAGName> az elosztott rendelkezésre állási csoport nevével (a hivatkozás létrehozásához használatos).
• <AGName> a SQL Server(a hivatkozás létrehozásához használt) rendelkezésre állási csoport nevével.
• <ManagedInstanceName> a felügyelt instance nevével.

-- Run on SQL Server
-- Sets the distributed availability group to a synchronous commit.
-- ManagedInstanceName example: 'sqlmi1'
USE master
GO
ALTER AVAILABILITY GROUP [<DAGName>] 
MODIFY 
AVAILABILITY GROUP ON
    '<AGName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
    '<ManagedInstanceName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

A hivatkozás replikációs módjának sikeres módosításához használja az alábbi dinamikus felügyeleti nézetet. Az eredmények a SYNCHRONOUS_COMMIT állapotot jelzik.

-- Run on SQL Server
-- Verifies the state of the distributed availability group
SELECT
    ag.name, ag.is_distributed, ar.replica_server_name,
    ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc,
    ars.operational_state_desc, ars.synchronization_health_desc
FROM
    sys.availability_groups ag
    join sys.availability_replicas ar
    on ag.group_id=ar.group_id
    left join sys.dm_hadr_availability_replica_states ars
    on ars.replica_id=ar.replica_id
WHERE
    ag.is_distributed=1

Most, hogy a SQL Server szinkronizált véglegesítési módra váltott, a két példány közötti replikáció szinkron. Ha meg kell fordítania ezt az állapotot, kövesse ugyanazokat a lépéseket, és állítsa be a AVAILABILITY_MODE-t ASYNCHRONOUS_COMMIT-re.

Az LSN-értékek ellenőrzése az SQL Serveren és az SQL Managed Instance-on

A feladatátvétel vagy az áttelepítés befejezéséhez ellenőrizze, hogy a replikáció a másodlagos rendszerbe befejeződött-e. Ehhez győződjön meg arról, hogy az SQL Server és a SQL Managed Instance naplórekordjaiban szereplő naplóütemezési számok (LSN-ek) megegyeznek.

Kezdetben várható, hogy az elsődleges LSN magasabb, mint a másodlagos LSN. A hálózati késés azt okozhatja, hogy a replikáció némileg elmarad az elsődlegesétől. Mivel leállították a munkaterhelést az elsődleges rendszeren, az LSN-k egyezni fognak, és nem fognak változni egy idő után.

Használja a következő T-SQL lekérdezést a SQL Serveren az utolsó rögzített tranzakciónapló LSN-jének beolvasásához. Helyettesít:

• <DatabaseName> az adatbázis nevével, és keresse meg az utolsó rögzített LSN-számot.

-- Run on SQL Server
-- Obtain the last hardened LSN for the database on SQL Server.
SELECT
    ag.name AS [Replication group],
    db.name AS [Database name], 
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state], 
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN] 
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
    inner join sys.availability_groups ag on drs.group_id = ag.group_id
WHERE
    ag.is_distributed = 1 and db.name = '<DatabaseName>'

A következő T-SQL-lekérdezés használatával olvassa be az SQL Managed Instance adatbázisának utolsó rögzített LSN-ét. Cserélje le <DatabaseName> az adatbázis nevére.

Ez a lekérdezés általános célú SQL Managed Instance működik. Üzletileg kritikus SQL Managed Instance esetén törölje a megjegyzést a szkript végén található and drs.is_primary_replica = 1 előtt. Az üzletileg kritikus szolgáltatási szinten ez a szűrő biztosítja, hogy a részletek csak az elsődleges replikából legyenek beolvasva.

-- Run on SQL managed instance
-- Obtain the LSN for the database on SQL Managed Instance.
SELECT
    db.name AS [Database name],
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state],
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN]
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
WHERE
    db.name = '<DatabaseName>'
    -- for Business Critical, add the following as well
    -- AND drs.is_primary_replica = 1

Másik lehetőségként használhatja a Get-AzSqlInstanceLink PowerShell vagy az sql mi link show Azure CLI parancsot is a SQL Managed Instance hivatkozás LastHardenedLsn tulajdonságának lekéréséhez, hogy ugyanazokat az információkat adja meg, mint az előző T-SQL-lekérdezés.

Fontos

Ellenőrizze ismét, hogy a munkafolyamat le van-e állítva a fő rendszeren. Ellenőrizze, hogy az LSN-ek az SQL Server és az SQL Managed Instance között megegyeznek-e, és hogy megegyezve maradnak és egy ideig változatlanok maradnak. A stabil LSN-ek mindkét példányon azt jelzik, hogy a tail naplófájlt replikálták a másodlagos példányra, és a számítási feladatot hatékonyan leállították.

Adatbázis feladatátvétele

Ha 2022 SQL Server és SQL Managed Instance közötti adatbázis feladatátvételére szeretné használni a PowerShellt, miközben továbbra is fenntartja a kapcsolatot, vagy a SQL Server bármely verziójában adatvesztéssel szeretne feladatátvételt végezni, használja a A SQL Server és Managed Instance közötti feladatátvételt varázsló az SSMS-ben a környezet szkriptjének létrehozásához. Tervezett feladatátvételt az elsődleges vagy a másodlagos replikánál is hajthat végre. Kényszerített átkapcsoláshoz csatlakozzon a másodlagos replikához.

Ha meg szeretné szakítani a csatolást és leállítani a replikációt, amikor feladatátvételt vagy áttelepítést hajt végre az adatbázison, függetlenül az SQL Server verziótól, használja a Remove-AzSqlInstanceLink PowerShell vagy az sql mi link delete Azure CLI parancsot.

Vigyázat!

• A feladatátvétel előtt állítsa le a számítási feladatot a forrásadatbázison, hogy a replikált adatbázis teljes mértékben felzárkózhasson, és hajtson végre feladatátvételt adatvesztés nélkül. Ha kényszerített átállást hajt végre, vagy az LSN-ek egyeztetése előtt megszakítja a hivatkozást, előfordulhat, hogy adatokat veszít.
• A 2019- SQL Server és a korábbi verziók adatbázisának feladatátvétele megszakad, és eltávolítja a két replika közötti kapcsolatot. Nem lehet visszalépni a kezdeti elsődlegesre.

Az alábbi példaszkript megszakítja a csatolást, és véget vet a replikák közötti replikációnak, így az adatbázis mindkét példányon olvasható/írható. Helyettesít:

• <ManagedInstanceName> a felügyelt instance nevével.
• <DAGName> a feladatátvétel alatt álló hivatkozás nevével (a korábban végrehajtott Name parancsból Get-AzSqlInstanceLink tulajdonság kimenete).

# Run in Azure Cloud Shell (select PowerShell console) 
# =============================================================================
# POWERSHELL SCRIPT TO FAIL OVER OR MIGRATE DATABASE TO AZURE
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"
$LinkName = "<DAGName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Failover the specified link
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup |
-InstanceName $ManagedInstanceName -Name $LinkName -Force

Ha a feladatátvétel sikeres, a hivatkozás el lesz dobva, és már nem létezik. A SQL Server adatbázis és a SQL Managed Instance adatbázis egyaránt képes olvasási/írási számítási feladatokat végrehajtani, mivel teljesen függetlenek.

Fontos

Miután sikeresen megtörtént az átállás az SQL Managed Instance-re, manuálisan állítsa be az alkalmazás(ok) connection string-jét az SQL Managed Instance teljes tartománynévre a migrálás vagy átállási folyamat befejezéséhez, majd futtassa tovább az Azure-ban.

A hivatkozás elvetése után megtarthatja a rendelkezésre állási csoportot az SQL Serveren, de az elosztott rendelkezésre állási csoportot el kell távolítania az SQL Serverről a hivatkozás metaadatainak törléséhez. Ez a további lépés csak a PowerShell használatával történő feladatátvételhez szükséges, mivel az SSMS végrehajtja ezt a műveletet.

Az elosztott rendelkezésre állási csoport elvetéséhez cserélje le a következő értéket, majd futtassa a T-SQL-mintakódot:

• <DAGName> a SQL Server (a hivatkozás létrehozásához használt) elosztott rendelkezésre állási csoport nevével.

-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> 
GO

Fontos

A tervezett feladatátvétel végrehajtása után a replikációs mód aszinkronra van állítva.

Több adatbázis feladatátvétele

Ha példányokból a több adatbázis feladatátvételének végrehajtását tervezi ugyanazon a kiszolgálón, az optimális teljesítmény és kiszámíthatóság érdekében példányonként egyszerre 8 adatbázis feladatátvételét hajtsa végre. Ha például 10 példánya van, amelyek mindegyike 32 csatolt adatbázissal rendelkezik, mindegyik példányból egyszerre 8 adatbázist feladatátvételt kell végrehajtania, és ismételje meg a folyamatot, amíg az összes adatbázis feladatátvételre nem kerül.

Adatbázis megtekintése átállás után

SQL Server 2022 esetén, ha úgy dönt, hogy a hivatkozást fenntartja, ellenőrizheti, hogy az elosztott rendelkezésre állási csoport létezik-e az Availability Groups a Object Explorer-ben a SQL Server Management Studio-ban.

Ha a feladatátvétel során elvetette a hivatkozást, a Object Explorer használatával ellenőrizheti, hogy az elosztott rendelkezésre állási csoport már nem létezik-e. Ha úgy döntött, hogy megtartja a rendelkezésre állási csoportot, az adatbázis továbbra is szinkronizáltlesz.

Takarítás a feladatátvétel után

Amennyiben a Remove link after successful failover nincs kiválasztva, a SQL Server 2022 feladatátvétel nem szakítja meg a hivatkozást. A hivatkozást a feladatátvétel után is fenntarthatja, amely hagyja aktívként a rendelkezésre állási csoportot és az elosztott rendelkezésre állási csoportot. Nincs szükség további műveletre.

A hivatkozás elvetése csak az elosztott rendelkezésre állási csoportot elveti, és aktív marad a rendelkezésre állási csoport. Dönthet úgy, hogy megtartja a rendelkezésre állási csoportot, vagy elveti.

Ha úgy dönt, hogy elveti a rendelkezésre állási csoportot, cserélje le a következő értéket, majd futtassa a T-SQL-mintakódot:

• <AGName> a rendelkezésre állási csoport nevével az SQL Serveren (a hivatkozás létrehozásához használatos).

-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <AGName> 
GO

Inkonzisztens állapot a kényszerített feladatátvétel után

A kényszerített feladatátvételt követően előfordulhat, hogy egy split-brain forgatókönyvben mindkét replika elsődleges szerepet tölt be, így a kapcsolat inkonzisztens állapotban marad. Ez akkor fordulhat elő, ha egy katasztrófa során átvált a másodlagos replikára, majd az elsődleges replika újra online állapotba kerül.

A probléma megoldásához lásd: Split-brain scenario javítása.

Kapcsolódó tartalom

A hivatkozás használata:

• Készítse elő a(z) Managed Instance hivatkozáshoz tartozó környezetet
• Kapcsolat konfigurálása az SQL Server és a felügyelt SQL-példány között SSMS-sel
• Konfigurálási kapcsolat SQL Server és felügyelt SQL-példány között szkriptekkel
• Migrálás a hivatkozással
• ajánlott eljárások a hivatkozás karbantartásához
• A hivatkozással kapcsolatos problémák elhárítása

További információ a hivatkozásról:

• Managed Instance hivatkozás áttekintése
• Katasztrófa-helyreállítás kezelt példány hivatkozással

Egyéb replikációs és migrálási forgatókönyvek esetén fontolja meg a következő szempontokat:

• Tranzakciós replikáció SQL Managed Instance
• Napló Visszajátszó Szolgáltatás (LRS)