‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

מעבר מ-SQL Server בניהול עצמי באמצעות קבוצות זמינות מבוזרות

במדריך הזה מוסבר איך להעביר מסדי נתונים ממכונה בניהול עצמי של SQL Server Enterprise Edition אל Cloud SQL ל-SQL Server Enterprise Edition, דרך חיבור לרשת פרטית באמצעות קבוצת זמינות מבוזרת (DAG) ב-Database Migration Service.

בהעברה של DAG, ‏Database Migration Service מעביר בסטרימינג גם את הטעינה המלאה הראשונית (השלב שנקרא FULL_DUMP) וגם את הרפליקציה הרציפה של יומן העסקאות (השלב שנקרא "סימון נתונים שהשתנו" – CDC) ישירות ברשת בין קבוצת הזמינות במקור לבין קבוצת הזמינות ביעד ב-Cloud SQL ל-SQL Server. מידע נוסף על הארכיטקטורה, הדרישות המוקדמות והמגבלות של העברות DAG זמין במאמר מידע על העברות של קבוצות זמינות מבוזרות (DAG). כדי להעביר באמצעות קובצי גיבוי שמאוחסנים ב-Cloud Storage, קראו את המאמר העברת מסדי נתונים של SQL Server ל-Cloud SQL ל-SQL Server.

כדי לבצע העברה של קבוצת זמינות מבוזרת, צריך לבצע את המשימות הבאות ברמה גבוהה:

יוצרים ומכינים את מכונת היעד של Cloud SQL ל-SQL Server.
מכינים את מכונת המקור של SQL Server ואת קבוצת הזמינות.
יוצרים קישוריות דו-כיוונית לרשת פרטית ומגדירים שרת מקושר.
יוצרים פרופילי חיבור ומריצים את משימת ההעברה.
עוקבים אחרי ההעברה ומאמתים אותה.
מקַדמים, מבצעים מעבר חזרה למצב קודם או משלימים את ההעברה.

עלויות

להעברות הומוגניות ל-Cloud SQL, השירות Database Migration Service מוצע ללא תשלום נוסף. עם זאת, חלים התמחורים הרגילים של Cloud SQL ושל הרשת. כדי להעריך את עלויות השימוש, אתם יכולים להשתמש במחשבון עלויות.

לפני שמתחילים

מוודאים שמסדי הנתונים של המקור והיעד עומדים בכל הדרישות המוקדמות והמגבלות של העברות של קבוצות זמינות מבוזרות (כולל הפעלת Enterprise Edition, אחסון קובצי נתונים בספריית הנתונים שמוגדרת כברירת מחדל, ואי שימוש ב-sa כבעלים של מסד הנתונים). אפשר לקרוא מידע נוסף במאמר מידע על העברות של קבוצות זמינות מבוזרות (DAG).
בוחרים את האזור של Google Cloud להעברה. ‫Database Migration Service הוא מוצר אזורי לחלוטין. כל הישויות שקשורות להעברה (פרופילי החיבור של המקור והיעד, משימת ההעברה והמכונה של Cloud SQL ל-SQL Server ביעד) חייבות להיות באותו אזור.
במסוף Google Cloud , בדף לבחירת הפרויקט בוחרים פרויקט או יוצרים פרויקט ב- Google Cloud .
כניסה לדף לבחירת הפרויקט
מפעילים את ממשקי ה-API של Database Migration Service,‏ Compute Engine ו-Cloud SQL Admin.
הפעלת ממשקי ה-API

התפקידים הנדרשים

מוודאים שתפקידי ה-IAM הבאים מוקצים בפרויקט ב-Google Cloud :

חשבון המשתמש שמבצע את ההעברה:
- אדמין של Database Migration ‏ (roles/datamigration.admin)
- עריכה ב-Cloud SQL ‏(roles/cloudsql.editor)
חשבון השירות של Database Migration Service‏ (service-<var>PROJECT_NUMBER</var>@gcp-sa-datamigration.iam.gserviceaccount.com):
- סוכן שירות של Database Migration Service ‏(roles/datamigration.serviceAgent)
- עריכה ב-Cloud SQL ‏(roles/cloudsql.editor)
- משתמש ב-Cloud SQL Studio ‏ (roles/cloudsql.studioUser)

להסבר על מתן תפקידים, ראו איך מנהלים את הרשאות הגישה.

יצירה והכנה של מכונת היעד של Cloud SQL ל-SQL Server

בשלב הזה יוצרים את מכונת היעד של Cloud SQL ל-SQL Server Enterprise Edition ומפעילים את הדגל לניהול מסד הנתונים שנדרש לשרתים מקושרים.

יוצרים את מכונת היעד של Cloud SQL ל-SQL Server. הוראות מפורטות ליצירת מכונה מופיעות במאמר יצירת מכונה של Cloud SQL ל-SQL Server. מוודאים שהמכונה עומדת בדרישות הבאות להעברות של קבוצות זמינות מבוזרות:
- בוחרים באפשרות Enterprise Edition (גרסה 2017,‏ 2019,‏ 2022 או 2025).
- מגדירים רשת פרטית בהתאם לאופן שבו מתכננים לחבר את מכונת המקור של SQL Server למכונת היעד של Cloud SQL ל-SQL Server. מפעילים את האפשרות גישה לשירותים פרטיים אם מתכננים לחבר את המכונות באמצעות קישור VPC, או משתמשים ב- Private Service Connect אם מתכננים לחבר את המכונות באמצעות נקודת קצה נכנסת של Private Service Connect ומחבר רשת של Private Service Connect.
  אל תפעילו גם את Private Services Access וגם את Private Service Connect באותו מכונה של Cloud SQL ל-SQL Server ביעד. ב-Cloud SQL ל-SQL Server אין תמיכה בשרתים מקושרים כששתי האפשרויות מופעלות. לפרטים מלאים על הגדרת הרשת, ראו יצירת קישוריות דו-כיוונית לרשת פרטית.
- השאירו את האפשרות Point-in-time recovery (PITR) מושבתת ואל תוסיפו רפליקות לקריאה בלבד עד שתסיימו ותמחקו את משימת ההעברה של ה-DAG.
- אם מסד נתונים כלשהו במקור נמצא בבעלות של פרטי כניסה ל-Windows Active Directory, צריך לשנות את הבעלים של מסד הנתונים במקור לפרטי כניסה ל-SQL לפני ההעברה, או לצרף את מכונת היעד של Cloud SQL ל-SQL Server ל-Active Directory כדי ש-Database Migration Service יוכל ליצור באופן אוטומטי את פרטי הכניסה התואמים ל-Windows במכונת היעד כשמשימת ההעברה מתחילה. להוראות, קראו את המאמר הגדרת שירות מנוהל ל-Microsoft AD ב-Cloud SQL ל-SQL Server.
מפעילים את הדגל לניהול מסד הנתונים cloudsql enable linked servers (מגדירים אותו לערך on) במכונה של Cloud SQL ל-SQL Server ביעד. הוראות להגדרת דגלים זמינות במאמרים ניהול שרתים מקושרים והגדרת דגלים של מסדי נתונים.
תצטרכו את הדגל הזה בהמשך המדריך, כשתרצו ליצור ולאמת את השרת המקושר במכונה של Cloud SQL ל-SQL Server ביעד.

הכנת מכונת המקור של SQL Server

בשלב הזה מפעילים את Always On Availability Groups במכונה של SQL Server במקור, יוצרים נקודת קצה ותעודה לשיקוף מסד הנתונים, יוצרים פרטי כניסה ייעודיים ל-SQL בשביל Database Migration Service ומכינים את קבוצת הזמינות במקור.

הפעלת Always On Availability Groups

מוודאים שהתכונה Always On Availability Groups מופעלת במכונה של SQL Server במקור:

ב-Windows, אפשר לעיין במאמר הפעלה והשבתה של קבוצות זמינות מסוג Always On במסמכי התיעוד של Microsoft.
ב-Linux, קראו את המאמר הגדרת קבוצת זמינות של SQL Server Always On לזמינות גבוהה ב-Linux במסמכי התיעוד של Microsoft.

יצירת נקודת הקצה והאישור של שיקוף מסד הנתונים

ב-SQL Server, קבוצות זמינות מבוזרות מעבירות נתונים ויומני טרנזקציות בין מכונות דרך נקודות קצה (endpoint) של TCP DATABASE_MIRRORING (DBM) (יציאת ברירת המחדל היא 5022). מכיוון שהמכונה של SQL Server בניהול עצמי והמכונה של Cloud SQL ל-SQL Server הן מכונות נפרדות, הן דורשות אימות הדדי מבוסס-אישור והצפנת AES כדי ליצור אמון בנקודת הקצה (endpoint) של DBM.

צריך רק ליצור אישור ולקשר אותו לנקודת הקצה (endpoint) של DATABASE_MIRRORING במכונה של שרת ה-SQL במקור. לא צריך לייצא ידנית קובצי אישורים או ליצור אישורים במכונה של Cloud SQL ל-SQL Server ביעד:

כשמתחילים את משימת ההעברה, השירות Database Migration Service מגדיר באופן אוטומטי את נקודת הקצה והאישור של DATABASE_MIRRORING במכונה של Cloud SQL ל-SQL Server ביעד, ומשתמש בשרת המקושר כדי להחליף את המפתחות הציבוריים בין שתי המכונות.
כשמוחקים את משימת ההעברה אחרי השלמת המעבר החד למערכת אחרת, Database Migration Service מסיר באופן אוטומטי את האישורים המיובאים משני המופעים.

אם למכונה של שרת ה-SQL במקור אין נקודת קצה (endpoint) של DATABASE_MIRRORING שאומתה באמצעות אישור, צריך ליצור אחת:

מתחברים למכונה של המקור באמצעות לקוח SQL, למשל הכלי sqlcmd.
מריצים את פקודות ה-T-SQL הבאות כדי ליצור מפתח מאסטר למסד הנתונים, אישור ונקודת קצה (endpoint) של DATABASE_MIRRORING שמאזינה ליציאת ה-DBM שבחרתם (ברירת המחדל היא 5022):
```
USE [master];
GO

IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
BEGIN
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'MASTER_KEY_PASSWORD';
END
GO

CREATE CERTIFICATE [SOURCE_CERT_NAME]
    WITH SUBJECT = 'AlwaysOn AG Certificate',
    EXPIRY_DATE = 'CERT_EXPIRY_DATE';
GO

CREATE ENDPOINT [HADR_ENDPOINT_NAME]
    STATE = STARTED
    AS TCP (LISTENER_PORT = SOURCE_DBM_PORT_NUMBER)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE [SOURCE_CERT_NAME],
        ENCRYPTION = REQUIRED ALGORITHM AES
    );
GO
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫MASTER_KEY_PASSWORD בסיסמה להצפנת מפתח המאסטר של מסד הנתונים.
- ‫SOURCE_CERT_NAME בשם של אישור שיקוף מסד הנתונים במקור (לדוגמה, dbmCertificate).
- ‫CERT_EXPIRY_DATE בתאריך התפוגה של האישור בפורמט YYYYMMDD.
- ‫HADR_ENDPOINT_NAME בשם של נקודת הקצה של שיקוף מסד הנתונים.
- ‫SOURCE_DBM_PORT_NUMBER עם מספר יציאת ה-TCP לתנועה של שיקוף מסד הנתונים (ברירת המחדל היא 5022).

‫Database Migration Service מתחבר למכונה של שרת ה-SQL במקור דרך השרת המקושר, באמצעות פרטי התחברות ייעודיים ל-SQL שאתם מספקים בפרופיל החיבור של המקור. כדי להגדיר את ההתחברות הזו, אתם יכולים להקצות את תפקיד השרת sysadmin או להגדיר הרשאות מינימליות באמצעות מסד הנתונים המסייע gcp_dms_db:

הקצאת תפקיד sysadmin

אם מדיניות האבטחה שלכם מאפשרת להקצות את תפקיד השרת sysadmin להתחברות להעברה, מריצים את פקודות ה-T-SQL הבאות:

USE [master];
GO
CREATE LOGIN [SOURCE_USERNAME] WITH PASSWORD = 'SOURCE_PASSWORD';
CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
ALTER SERVER ROLE [sysadmin] ADD MEMBER [SOURCE_USERNAME];
GRANT CONNECT ON ENDPOINT::[HADR_ENDPOINT_NAME] TO [SOURCE_USERNAME];
GO

מחליפים את מה שכתוב בשדות הבאים:

‫SOURCE_USERNAME בשם המשתמש של SQL שמשמש את Database Migration Service כדי להתחבר למכונה במקור (לדוגמה, cloud_dms_login).
‫SOURCE_PASSWORD מחליפים בסיסמה של המשתמש SOURCE_USERNAME.
‫SOURCE_USER עם שם המשתמש של מסד הנתונים שממופה ל-SOURCE_USERNAME (לדוגמה, cloud_dms_user).
‫HADR_ENDPOINT_NAME בשם של נקודת הקצה של שיקוף מסד הנתונים (לדוגמה, Hadr_endpoint).

הרשאות מינימליות (gcp_dms_db)

אם מדיניות האבטחה שלכם אוסרת על מתן הרשאת sysadmin להתחברות להעברה, צרו את מסד הנתונים הייעודי gcp_dms_db (בבעלות sa עם TRUSTWORTHY ON), צרו את שלוש הפרוצדורות המאוחסנות של Database Migration Service והעניקו הרשאות מפורטות להתחברות להעברה:

USE [master];
GO

CREATE DATABASE [gcp_dms_db];
GO

ALTER AUTHORIZATION ON DATABASE::[gcp_dms_db] TO [sa];
ALTER DATABASE [gcp_dms_db] SET TRUSTWORTHY ON;
GO

USE [gcp_dms_db];
GO

CREATE OR ALTER PROCEDURE dbo.gcp_dms_set_dag_commit_mode
    @dag_name NVARCHAR(128),
    @source_ag NVARCHAR(128),
    @dest_ag NVARCHAR(128),
    @commit_mode NVARCHAR(30)
WITH EXECUTE AS 'dbo'
AS
BEGIN
    SET NOCOUNT ON;
    IF @commit_mode NOT IN ('SYNCHRONOUS_COMMIT', 'ASYNCHRONOUS_COMMIT')
    BEGIN
        RAISERROR('Invalid commit mode. Must be SYNCHRONOUS_COMMIT or ASYNCHRONOUS_COMMIT.', 16, 1);
        RETURN;
    END
    DECLARE @sql NVARCHAR(MAX);
    SET @sql = N'USE master; ALTER AVAILABILITY GROUP ' + QUOTENAME(@dag_name) +
               N' MODIFY AVAILABILITY GROUP ON ' +
               QUOTENAME(@source_ag, '''') + N' WITH (AVAILABILITY_MODE = ' + @commit_mode + N'), ' +
               QUOTENAME(@dest_ag, '''') + N' WITH (AVAILABILITY_MODE = ' + @commit_mode + N');';
    EXECUTE sp_executesql @sql;
END;
GO

CREATE OR ALTER PROCEDURE dbo.gcp_dms_set_dag_secondary
    @dag_name NVARCHAR(128)
WITH EXECUTE AS 'dbo'
AS
BEGIN
    SET NOCOUNT ON;
    DECLARE @sql NVARCHAR(MAX);
    SET @sql = N'USE master; ALTER AVAILABILITY GROUP ' + QUOTENAME(@dag_name) + N' SET (ROLE = SECONDARY);';
    EXECUTE sp_executesql @sql;
END;
GO

CREATE OR ALTER PROCEDURE dbo.gcp_dms_failover_dag
    @dag_name NVARCHAR(128)
WITH EXECUTE AS 'dbo'
AS
BEGIN
    SET NOCOUNT ON;
    DECLARE @sql NVARCHAR(MAX);
    SET @sql = N'USE master; ALTER AVAILABILITY GROUP ' + QUOTENAME(@dag_name) + N' FORCE_FAILOVER_ALLOW_DATA_LOSS;';
    EXECUTE sp_executesql @sql;
END;
GO

USE [master];
GO

CREATE LOGIN [SOURCE_USERNAME] WITH PASSWORD = 'SOURCE_PASSWORD';
CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
GRANT VIEW SERVER STATE TO [SOURCE_USERNAME];
-- Note: Run GRANT VIEW SERVER PERFORMANCE STATE on SQL Server 2022 and later:
GRANT VIEW SERVER PERFORMANCE STATE TO [SOURCE_USERNAME];
GRANT VIEW ANY DEFINITION TO [SOURCE_USERNAME];
GRANT ALTER ANY AVAILABILITY GROUP TO [SOURCE_USERNAME];
GRANT CONNECT ON ENDPOINT::[HADR_ENDPOINT_NAME] TO [SOURCE_USERNAME];
GRANT CREATE CERTIFICATE TO [SOURCE_USER];
GO

USE [gcp_dms_db];
GO

CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
GRANT EXECUTE ON dbo.gcp_dms_set_dag_commit_mode TO [SOURCE_USER];
GRANT EXECUTE ON dbo.gcp_dms_set_dag_secondary TO [SOURCE_USER];
GRANT EXECUTE ON dbo.gcp_dms_failover_dag TO [SOURCE_USER];
GO

-- Repeat the following block for EACH user database in your source Availability Group:
USE [DATABASE_NAME];
GO

CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
ALTER ROLE [db_backupoperator] ADD MEMBER [SOURCE_USER];
GO

מחליפים את מה שכתוב בשדות הבאים:

‫SOURCE_USERNAME בשם המשתמש של SQL שמשמש את Database Migration Service כדי להתחבר למכונה במקור (לדוגמה, cloud_dms_login).
‫SOURCE_PASSWORD מחליפים בסיסמה של המשתמש SOURCE_USERNAME.
‫SOURCE_USER עם שם המשתמש של מסד הנתונים שממופה ל-SOURCE_USERNAME (לדוגמה, cloud_dms_user).
‫HADR_ENDPOINT_NAME בשם של נקודת הקצה של שיקוף מסד הנתונים (לדוגמה, Hadr_endpoint).
‫DATABASE_NAME בשם של כל מסד נתונים של מקור בקבוצת הזמינות. כדי להעביר את מסד הנתונים, צריך להעניק את ההרשאה db_backupoperator בכל מסד נתונים שמועבר. ההרשאה הזו נדרשת לאימות לפני ההעברה של Database Migration Service, והיא מאפשרת למחוק את יומני העסקאות באמצעות CHECKPOINT במהלך הקידום.

הכנת מסדי הנתונים של המקור וקבוצת הזמינות

אתם יכולים להעביר מסדי נתונים מקבוצת זמינות קיימת של Always On או ליצור קבוצת זמינות חדשה (CLUSTER_TYPE = NONE). לפני שתמשיכו, ודאו שאתם עומדים בדרישות הבאות:

כל מסד נתונים בקבוצת הזמינות משתמש במודל השחזור FULL, לא נמצא בבעלות של sa ומאחסן את קובצי הנתונים שלו (.mdf ו-.ndf) בספריית הנתונים שמוגדרת כברירת מחדל.
אם אתם משתמשים שוב בקבוצת זמינות קיימת, ודאו שנקודת הקצה של שיקוף מסד הנתונים מוגדרת ביציאה 5022 (או ביציאת ה-DBM שבחרתם), ש-SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL) מופעל ברפליקה כדי שמסדי נתונים משניים יישארו קריאים עם מחרוזות חיבור רגילות אחרי שהקידום הופך את תפקידי ה-DAG, ושלכניסה להעברה יש CONNECT ON ENDPOINT. אם לקבוצת הזמינות במקור יש כמה רפליקות ומוגדר לה מאזין, השתמשו בכתובת ה-IP של המאזין בתור <var>SOURCE_HOST_IP_ADDRESS</var> כשאתם מגדירים את השרת המקושר ואת פרופיל החיבור למקור. כך תוכלו להמשיך את ההעברה אם תהיה יתירות כשל בקבוצת הזמינות במקור.

כדי להכין מסד נתונים וליצור קבוצת זמינות חדשה (CLUSTER_TYPE = NONE) נפרדת, מריצים את פקודות ה-T-SQL הבאות:

USE [master];
GO

ALTER DATABASE [DATABASE_NAME] SET RECOVERY FULL;
GO

-- If the database is owned by 'sa', change the owner to another login:
ALTER AUTHORIZATION ON DATABASE::[DATABASE_NAME] TO [DB_OWNER_LOGIN];
GO

-- Initialize the local SQL Server transaction log chain for the Availability Group:
BACKUP DATABASE [DATABASE_NAME] TO DISK = 'NUL';
GO

CREATE AVAILABILITY GROUP [SOURCE_AVAILABILITY_GROUP_NAME] WITH (CLUSTER_TYPE = NONE)
    FOR REPLICA ON N'SOURCE_SERVER_NAME' WITH (
        ENDPOINT_URL = N'TCP://localhost:SOURCE_DBM_PORT_NUMBER',
        FAILOVER_MODE = MANUAL,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        SEEDING_MODE = MANUAL,
        PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE),
        SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
    );
GO

ALTER AVAILABILITY GROUP [SOURCE_AVAILABILITY_GROUP_NAME] ADD DATABASE [DATABASE_NAME];
GO

מחליפים את מה שכתוב בשדות הבאים:

‫DATABASE_NAME בשם של מסד הנתונים שרוצים לכלול בקבוצת הזמינות.
DB_OWNER_LOGIN עם פרטי התחברות שהם לא של sa כדי להיות הבעלים של מסד הנתונים.
SOURCE_AVAILABILITY_GROUP_NAME בשם של קבוצת הזמינות במקור (לדוגמה, source_ag).
‫SOURCE_SERVER_NAME בשם השרת של מכונת המקור של SQL Server (תואם לערך שמוחזר על ידי SELECT @@SERVERNAME).
‫SOURCE_DBM_PORT_NUMBER עם מספר יציאת ה-TCP של נקודת הקצה של שיקוף מסד הנתונים (ברירת המחדל היא 5022).

יצירת קישוריות דו-כיוונית לרשת פרטית

בהעברות של DAG, ‏Database Migration Service מתקשר עם מכונת היעד של Cloud SQL ל-SQL Server באמצעות ממשקי API פנימיים של Google Cloud , מריץ שאילתות תזמור במכונת המקור של SQL Server באמצעות שרת מקושר במכונת היעד של Cloud SQL ל-SQL Server, ומעביר נתונים ישירות בין שתי המכונות ברשת פרטית. כדי לבצע את ההעברה הזו, צריך ליצור קישוריות דו-כיוונית דרך IP פרטי ישירות בין המארח של SQL Server במקור לבין המכונה של Cloud SQL ל-SQL Server ביעד, דרך רשת ה-VPC. אין תמיכה בקישוריות של כתובת IP ציבורית בין המכונות של המקור והיעד.

יציאות וכתובות IP נדרשות

הגדרת הרשת צריכה לאפשר תנועה בין מכונת המקור של SQL Server לבין מכונת היעד של Cloud SQL ל-SQL Server בשתי יציאות ה-TCP הבאות:

יציאה	כיוון	מטרה
יציאת מסד הנתונים של SQL Server (ברירת המחדל היא `1433`)	ממכונת היעד של Cloud SQL ל-SQL Server למכונת המקור של SQL Server	משמש את השרת המקושר במכונה של Cloud SQL ל-SQL Server ביעד כדי להריץ שאילתות של אימות לפני ההפעלה, החלפת אישורים ותזמור של DAG במכונה של המקור.
יציאת שיקוף מסד נתונים (`DBM`) (ברירת המחדל היא `5022`)	דו-כיווני בין מכונת המקור של SQL Server לבין מכונת היעד של Cloud SQL ל-SQL Server	משמש את קבוצות הזמינות של המקור והיעד להעברת הנתונים הראשונית המלאה במהלך `FULL_DUMP`, שינויים שוטפים במסד הנתונים במהלך `CDC` ויצירת רפליקה הפוכה במהלך `FAILBACK`.

כשמגדירים את השרת המקושר ואת פרופילי החיבור בהמשך המדריך, צריך לספק שתי כתובות IP פרטיות:

‫SOURCE_HOST_IP_ADDRESS (שמשמש בפרמטר @datasrc של השרת המקושר ובדגל --host של פרופיל החיבור של המקור) הוא כתובת ה-IP הפרטית של מארח SQL Server של המקור (או כתובת ה-IP של המאזין של קבוצת הזמינות, שעדיפה אם היא מוגדרת לקבוצת זמינות של מקור עם כמה רפליקות, כדי שאפשר יהיה להמשיך את ההעברה אם מתרחשת יתירות כשל בקבוצת הזמינות של המקור) שאפשר להגיע אליה מהמכונה של Cloud SQL ל-SQL Server של היעד.
‫DESTINATION_HOST_IP_ADDRESS (משמש בדגל --host של פרופיל החיבור ליעד) הוא כתובת ה-IP הפרטית של מכונת היעד של Cloud SQL ל-SQL Server (או כתובת ה-IP של נקודת הקצה של Private Service Connect) שאפשר להגיע אליה מהמארח של SQL Server במקור.

הגדרת שיטת הרשת הפרטית

משלימים את הגדרת הניתוב ברשת לשיטת הרישות (גישה לשירותים פרטיים או Private Service Connect) שהפעלתם במכונה של Cloud SQL ל-SQL Server ביעד:

גישה לשירותים פרטיים

גישה לשירותים פרטיים: מגדירה את רשת ה-VPC שלכם כרשת שכנה של רשת ה-VPC של הבעלים של השירות המנוהל על ידי Google, שמארחת את מכונת היעד של Cloud SQL ל-SQL Server:

מוודאים שברשת של הענן הווירטואלי הפרטי (VPC) יש טווח כתובות IPv4 פנימיות שהוקצו וחיבור פרטי (קישור בין רשתות שכנות (peering) של VPC ל-servicenetworking-googleapis-com) שמופעל למכונת היעד של Cloud SQL ל-SQL Server. להוראות, ראו הגדרת כתובת IP פרטית ל-Cloud SQL ל-SQL Server.
מגדירים את הניתוב למארח של שרת ה-SQL בהתאם למקום שבו הוא מאוחסן:
- אם מכונת המקור פועלת במכונה וירטואלית של Compute Engine באותה רשת VPC, לא נדרש ניתוב נוסף. המכונה הווירטואלית והמכונה של Cloud SQL ל-SQL Server יכולות להגיע ישירות לכתובות ה-IP הפרטיות זו של זו דרך החיבור בין רשתות VPC שכנות.
- אם מכונת המקור פועלת באופן מקומי, אצל ספק שירותי ענן אחר או ברשת אחרת של ענן וירטואלי פרטי, צריך לבצע את הפעולות הבאות כדי שהמסלולים יוחלפו בגבולות של הקישור הטרנזיטיבי בין רשתות שכנות:
  1. מחברים את הרשת החיצונית לרשת בענן הווירטואלי הפרטי (VPC) באמצעות Cloud VPN או Cloud Interconnect. להוראות, קראו את המאמר גישה למכונה של Cloud SQL ממקור חיצוני.
  2. ב-Cloud Router, מפרסמים את טווח כתובות ה-IP שהוקצו ל-Cloud SQL ל-SQL Server ברשת המקור. להוראות, ראו פרסום טווחי כתובות IP בהתאמה אישית.
  3. מעדכנים את חיבור ה-peering של servicenetworking-googleapis-com ברשת ה-VPC כדי להפעיל את האפשרות Export custom routes, וכך המכונה של Cloud SQL ל-SQL Server תלמד את הנתיבים לרשת המקור. הוראות מפורטות זמינות במאמר עדכון חיבור Peering.
מתעדים את כתובות ה-IP הפרטיות של ההעברה:
- משתמשים בכתובת ה-IP הפנימית של מארח שרת ה-SQL כמקור, בתור SOURCE_HOST_IP_ADDRESS.
- משתמשים בכתובת ה-IP הפרטית שהוקצתה למכונה של Cloud SQL ל-SQL Server ביעד (מוצגת בדף Overview של המכונה) בתור DESTINATION_HOST_IP_ADDRESS.

התחברות לשירות פרטי

אם אתם משתמשים ב-Private Service Connect במקום בגישה לשירותים פרטיים, אתם צריכים להגדיר גם נקודת קצה נכנסת של Private Service Connect (כדי שמכונת המקור תוכל להתחבר ל-Cloud SQL ל-SQL Server ביציאה 5022) וגם ממשק יוצא של Private Service Connect (כדי ש-Cloud SQL ל-SQL Server יוכל ליזום חיבורים של Linked Server ו-DAG למכונת המקור ביציאות 1433 ו-5022):

מוודאים שבמכונה של Cloud SQL ל-SQL Server ביעד מופעל Private Service Connect (בלי כתובת IP פרטית) ומצוינים הפרויקטים המורשים של הצרכנים. הוראות מפורטות זמינות במאמר הגדרת Private Service Connect.
כדי לאפשר חיבורים נכנסים ממארח המקור של SQL Server למכונה של Cloud SQL ל-SQL Server ביעד, צריך להקצות כתובת IP פנימית ברשת המשנה של ה-VPC וליצור נקודת קצה (כלל העברה) של Private Service Connect שמטרגטת את צירוף השירות של המכונה של Cloud SQL ל-SQL Server. להוראות, ראו יצירת נקודת קצה של Private Service Connect.
כדי לאפשר חיבורים יוצאים ממכונת היעד של Cloud SQL ל-SQL Server למארח המקור של SQL Server (נדרש לחיבורים של Linked Server ו-DAG יוצאים), יוצרים מחבר רשת של Virtual Private Cloud ברשת המשנה שיכולה לנתב למארח המקור, ומגדירים קישוריות יוצאת של Private Service Connect במכונת היעד של Cloud SQL ל-SQL Server. להוראות, קראו את המאמרים יצירה וניהול של חיבורי רשת והגדרת קישוריות יוצאת ב-Private Service Connect.
מתעדים את כתובות ה-IP הפרטיות של ההעברה:
- משתמשים בכתובת ה-IP הפרטית של מארח שרת ה-SQL כמקור בתור SOURCE_HOST_IP_ADDRESS.
- משתמשים בכתובת ה-IP הפנימית של נקודת הקצה של Private Service Connect (כלל העברה) ברשת של הענן הווירטואלי הפרטי בתור DESTINATION_HOST_IP_ADDRESS.

הגדרת כללים לחומת האש של הענן הווירטואלי הפרטי (VPC) ושל המארח המקורי

ברשת VPC, יוצרים כללים של חומת אש לתעבורת נתונים נכנסת ויוצאת שמאפשרים תעבורת נתונים מסוג TCP בין כתובת ה-IP של שרת ה-SQL במקור (SOURCE_HOST_IP_ADDRESS) לבין טווח כתובות ה-IP של Cloud SQL ל-SQL Server ביעד (או נקודת הקצה של Private Service Connect ורשת המשנה של מחבר הרשת), גם ביציאה של מסד הנתונים (ברירת המחדל היא 1433) וגם ביציאה של שיקוף מסד הנתונים (ברירת המחדל היא 5022). מידע נוסף על יצירת כללים של חומת אש זמין במאמר יצירת כללים של חומת אש.
במכונה של שרת ה-SQL המקורית, בודקים את ההגדרות הבאות של הרשת ושל חומת האש של המארח:
- ‫TCP/IP מופעל ב-SQL Server Configuration Manager (או mssql-conf ב-Linux) והמכונה מאזינה ליציאת TCP סטטית (ברירת המחדל היא 1433).
- חומת האש של מערכת ההפעלה (כמו חומת האש של Windows Defender או iptables או firewalld של Linux) מאפשרת חיבורי TCP נכנסים גם ביציאת מסד הנתונים (ברירת המחדל היא 1433) וגם ביציאת שיקוף מסד הנתונים (ברירת המחדל היא 5022), וחיבורי TCP יוצאים אל DESTINATION_HOST_IP_ADDRESS ביציאה 5022.

אימות הנגישות באמצעות בדיקות קישוריות של Cloud SQL

לפני שמגדירים את השרת המקושר, מומלץ להריץ שלוש בדיקות קישוריות מהכרטיסייה Connections > Connectivity tests של המכונה של Cloud SQL ל-SQL Server במסוף Google Cloud . במאמר ניהול בדיקות קישוריות מוסבר איך מריצים בדיקת קישוריות:

כדי לבדוק את הקישוריות של השרת המקושר היוצא ביציאה 1433, מגדירים את Source ל-Current Cloud SQL instance, את Destination ל-SOURCE_HOST_IP_ADDRESS ואת Destination port ל-1433 (או ליציאת מסד הנתונים בהתאמה אישית).
כדי לבדוק את הקישוריות של שיקוף מסד הנתונים היוצא ביציאה 5022, מגדירים את Source ל-Current Cloud SQL instance, את Destination ל-SOURCE_HOST_IP_ADDRESS ואת Destination port ל-5022 (או ליציאת DBM בהתאמה אישית).
כדי לבדוק את הקישוריות הנכנסת של שיקוף מסד הנתונים ביציאה 5022, מגדירים את Source ל-SOURCE_HOST_IP_ADDRESS, את Destination ל-Current Cloud SQL instance (או ל-DESTINATION_HOST_IP_ADDRESS אם משתמשים ב-Private Service Connect) ואת Destination port ל-5022 (או ליציאת DBM בהתאמה אישית).

יצירה ואימות של השרת המקושר במכונה של Cloud SQL ל-SQL Server ביעד

אחרי שהקישוריות לרשת מוכנה, מתחברים למכונה של Cloud SQL ל-SQL Server ביעד ויוצרים את השרת המקושר שמפנה למכונה של SQL Server במקור:

מתחברים למכונה של Cloud SQL באמצעות לקוח SQL. אפשר להשתמש בשיטות הבאות:
- לקוח sqlcmd. אתם יכולים להשתמש בשיטה הזו כדי להתחבר לכתובת ה-IP הפרטית של המכונה, אבל יכול להיות שתצטרכו ליצור מכונה וירטואלית של Compute Engine.
- gcloud sql connect. הפקודה הזו פועלת רק במכונות של Cloud SQL שמופעלת בהן כתובת IP ציבורית.

נכנסים בתור המשתמש sqlserver ומריצים את פקודות ה-T-SQL הבאות בגרסת Cloud SQL ל-SQL Server של היעד, כדי ליצור שרת מקושר שמפנה למכונה של שרת ה-SQL במקור, למפות את @locallogin = N'sqlserver' לפרטי ההתחברות להעברה במקור, להפעיל את rpc out ולבדוק את החיבור באמצעות OPENQUERY (מידע נוסף על האפשרויות של שרת מקושר ב-Cloud SQL זמין במאמר ניהול שרתים מקושרים):

‫Cloud SQL ל-SQL Server בגרסאות 2017, 2019 ו-2022

USE [master];
GO

EXEC master.dbo.sp_addlinkedserver
    @server = N'LINKED_SERVER_NAME',
    @srvproduct = N'',
    @provider = N'SQLNCLI',
    @datasrc = N'SOURCE_HOST_IP_ADDRESS,SOURCE_PORT_NUMBER';
GO

EXEC master.dbo.sp_addlinkedsrvlogin
    @rmtsrvname = N'LINKED_SERVER_NAME',
    @useself = N'False',
    @locallogin = N'sqlserver',
    @rmtuser = N'SOURCE_USERNAME',
    @rmtpassword = N'SOURCE_PASSWORD';
GO

EXEC master.dbo.sp_serveroption
    @server = N'LINKED_SERVER_NAME',
    @optname = N'rpc out',
    @optvalue = N'TRUE';
GO

SELECT * FROM OPENQUERY([LINKED_SERVER_NAME], 'SELECT @@VERSION AS SourceServerVersion');
GO

‫Cloud SQL ל-SQL Server 2025

USE [master];
GO

EXEC master.dbo.sp_addlinkedserver
    @server = N'LINKED_SERVER_NAME',
    @srvproduct = N'',
    @provider = N'MSOLEDBSQL19',
    @datasrc = N'SOURCE_HOST_IP_ADDRESS,SOURCE_PORT_NUMBER',
    @provstr = N'Encrypt=Optional;TrustServerCertificate=Yes;Authentication=SqlPassword;UID=Placeholder;';
GO

EXEC master.dbo.sp_addlinkedsrvlogin
    @rmtsrvname = N'LINKED_SERVER_NAME',
    @useself = N'False',
    @locallogin = N'sqlserver',
    @rmtuser = N'SOURCE_USERNAME',
    @rmtpassword = N'SOURCE_PASSWORD';
GO

EXEC master.dbo.sp_serveroption
    @server = N'LINKED_SERVER_NAME',
    @optname = N'rpc out',
    @optvalue = N'TRUE';
GO

SELECT * FROM OPENQUERY([LINKED_SERVER_NAME], 'SELECT @@VERSION AS SourceServerVersion');
GO

מחליפים את מה שכתוב בשדות הבאים:

‫LINKED_SERVER_NAME בשם של השרת המקושר ב-Cloud SQL ל-SQL Server (לדוגמה, source_sql_linked_server).
‫SOURCE_HOST_IP_ADDRESS עם כתובת ה-IP הפרטית של מכונת המקור של SQL Server (או כתובת ה-IP של המאזין של קבוצת הזמינות, אם הוגדרה קבוצת זמינות של מקור עם כמה רפליקות).
SOURCE_PORT_NUMBER עם מספר היציאה שבה המנוע של מסד הנתונים של SQL Server במקור מקבל חיבורים (ברירת המחדל היא 1433).
‫SOURCE_USERNAME עם שם ההתחברות הייעודי ל-SQL שיצרתם במכונת המקור בקטע יצירת ההתחברות וההרשאות הייעודיות ל-Database Migration Service.
‫SOURCE_PASSWORD מחליפים בסיסמה של המשתמש SOURCE_USERNAME.

יצירת פרופילי חיבור והרצת משימת ההעברה

משתמשים ב-Google Cloud CLI כדי ליצור את פרופילי החיבור של המקור והיעד, ליצור את משימת ההעברה הרציפה של ה-DAG, לאמת את הגדרות ההעברה ולהתחיל את משימת ההעברה:

יוצרים את פרופיל החיבור של המקור.
מריצים את הפקודה gcloud database-migration connection-profiles create sqlserver (לחצו כדי להרחיב):
gcloud database-migration connection-profiles create sqlserver

בדוגמה הזו נעשה שימוש בדגל האופציונלי --no-async כדי שכל הפעולות יתבצעו באופן סינכרוני. זה אומר שיכול להיות שייקח קצת זמן עד שפקודות מסוימות יסתיימו. אפשר לדלג על הדגל --no-async כדי להריץ פקודות באופן אסינכרוני. אם כן, צריך להשתמש בפקודה gcloud database-migration operations describe כדי לוודא שהפעולה הצליחה.
```
gcloud database-migration connection-profiles create sqlserver SOURCE_CONNECTION_PROFILE_ID \
    --no-async \
    --display-name=SOURCE_CONNECTION_PROFILE_NAME \
    --region=REGION \
    --role=SOURCE \
    --host=SOURCE_HOST_IP_ADDRESS \
    --port=SOURCE_PORT_NUMBER \
    --dbm-port=SOURCE_DBM_PORT_NUMBER \
    --username=SOURCE_USERNAME \
    --password=SOURCE_PASSWORD
```
מחליפים את מה שכתוב בשדות הבאים:
- SOURCE_CONNECTION_PROFILE_ID במזהה קריא למכונה של פרופיל החיבור של המקור (לדוגמה, sqlserver-dag-source-profile).
- ‫SOURCE_CONNECTION_PROFILE_NAME עם שם קריא לאנשים עבור פרופיל החיבור של המקור. הערך הזה מוצג ב-Database Migration Service במסוף Google Cloud .
- REGION במזהה האזור שבו רוצים לשמור את פרופיל החיבור (לדוגמה, us-central1).
- ‫SOURCE_HOST_IP_ADDRESS עם כתובת ה-IP הפרטית של מכונת המקור של SQL Server (או כתובת ה-IP של המאזין של קבוצת הזמינות, אם הוגדרה קבוצת זמינות של מקור עם כמה רפליקות).
- SOURCE_PORT_NUMBER עם מספר היציאה שבה המנוע של מסד הנתונים של SQL Server במקור מקבל חיבורים (ברירת המחדל היא 1433).
- ‫SOURCE_DBM_PORT_NUMBER במספר יציאת ה-TCP של נקודת הקצה של שיקוף מסד הנתונים במקור (ברירת המחדל היא 5022).
- ‫SOURCE_USERNAME עם שם ההתחברות הייעודי ל-SQL שיצרתם במכונת המקור בקטע יצירת ההתחברות וההרשאות הייעודיות ל-Database Migration Service.
- ‫SOURCE_PASSWORD מחליפים בסיסמה של המשתמש SOURCE_USERNAME.
יוצרים את פרופיל החיבור של היעד.
מריצים את הפקודה gcloud database-migration connection-profiles create sqlserver (לחצו כדי להרחיב):
gcloud database-migration connection-profiles create sqlserver

בדוגמה הזו נעשה שימוש בדגל האופציונלי --no-async כדי שכל הפעולות יתבצעו באופן סינכרוני. זה אומר שיכול להיות שייקח קצת זמן עד שפקודות מסוימות יסתיימו. אפשר לדלג על הדגל --no-async כדי להריץ פקודות באופן אסינכרוני. אם כן, צריך להשתמש בפקודה gcloud database-migration operations describe כדי לוודא שהפעולה הצליחה.
```
gcloud database-migration connection-profiles create sqlserver DESTINATION_CONNECTION_PROFILE_ID \
    --no-async \
    --display-name=DESTINATION_CONNECTION_PROFILE_NAME \
    --region=REGION \
    --role=DESTINATION \
    --cloudsql-instance=CLOUDSQL_INSTANCE_ID \
    --host=DESTINATION_HOST_IP_ADDRESS \
    --port=DESTINATION_PORT_NUMBER \
    --dbm-port=DESTINATION_DBM_PORT_NUMBER \
    --username=sqlserver \
    --password=CLOUD_SQL_DB_USER_PASSWORD
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫DESTINATION_CONNECTION_PROFILE_ID עם מזהה בפורמט קריא למכונה עבור פרופיל החיבור ליעד (לדוגמה, sqlserver-dag-dest-profile).
- ‫DESTINATION_CONNECTION_PROFILE_NAME עם שם קריא לאנשים לפרופיל החיבור של היעד. הערך הזה מוצג ב-Database Migration Service במסוף Google Cloud .
- ‫REGION במזהה של האזור שבו רוצים לשמור את פרופיל החיבור.
- ‫CLOUDSQL_INSTANCE_ID בשם של מכונת היעד ב-Cloud SQL ל-SQL Server.
- ‫DESTINATION_HOST_IP_ADDRESS עם כתובת ה-IP הפרטית של מכונת היעד של Cloud SQL ל-SQL Server (או כתובת ה-IP של נקודת הקצה של Private Service Connect), שאפשר להגיע אליה ממכונת המקור של SQL Server.
- DESTINATION_PORT_NUMBER במספר היציאה של מסד הנתונים של מכונת היעד של Cloud SQL ל-SQL Server‏ (1433).
- DESTINATION_DBM_PORT_NUMBER עם מספר היציאה של שיקוף מסד הנתונים של המכונה של Cloud SQL ל-SQL Server ביעד (5022).
- ‫CLOUD_SQL_DB_USER_PASSWORD בסיסמה של המשתמש sqlserver במכונה של Cloud SQL ל-SQL Server ביעד (צריך להגדיר את --username לערך sqlserver).
יוצרים את משימת ההעברה הרציפה של ה-DAG.
מריצים את הפקודה gcloud database-migration migration-jobs create (לחצו כדי להרחיב):
gcloud database-migration migration-jobs create

בדוגמה הזו נעשה שימוש בדגל האופציונלי --no-async כדי שכל הפעולות יתבצעו באופן סינכרוני. זה אומר שיכול להיות שייקח קצת זמן עד שפקודות מסוימות יסתיימו. אפשר לדלג על הדגל --no-async כדי להריץ פקודות באופן אסינכרוני. אם כן, צריך להשתמש בפקודה gcloud database-migration operations describe כדי לוודא שהפעולה הצליחה.
```
gcloud database-migration migration-jobs create MIGRATION_JOB_ID \
    --no-async \
    --display-name=MIGRATION_JOB_NAME \
    --region=REGION \
    --type=CONTINUOUS \
    --source=SOURCE_CONNECTION_PROFILE_ID \
    --destination=DESTINATION_CONNECTION_PROFILE_ID \
    --sqlserver-dag-source-ag=SOURCE_AVAILABILITY_GROUP_NAME \
    --sqlserver-dag-linked-server=LINKED_SERVER_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫MIGRATION_JOB_ID עם מזהה בפורמט קריא למכונה של משימת ההעברה (לדוגמה, sqlserver-dag-job).
- MIGRATION_JOB_NAME בשם קריא לאנשים של משימת ההעברה. הערך הזה מוצג במסוף Google Cloud .
- ‫REGION במזהה של האזור שבו רוצים ליצור את משימת ההעברה.
- ‫SOURCE_CONNECTION_PROFILE_ID במזהה של פרופיל החיבור של המקור.
- ‫DESTINATION_CONNECTION_PROFILE_ID במזהה של פרופיל החיבור ליעד.
- ‫SOURCE_AVAILABILITY_GROUP_NAME בשם של קבוצת הזמינות במכונה של SQL Server במקור.
- ‫LINKED_SERVER_NAME בשם של השרת המקושר שהגדרתם במכונה של Cloud SQL ל-SQL Server ביעד, בקטע יצירה ואימות של השרת המקושר במכונה של Cloud SQL ל-SQL Server ביעד.
בודקים את ההגדרות של משימת ההעברה.
לפני שמתחילים משימת העברה של DAG, צריך להריץ את verify כדי לאמת את הקישוריות הדו-כיוונית לרשת, את הגישה ל-RPC של השרת המקושר, את ההרשאות של gcp_dms_db (אם משתמשים בהרשאות המינימליות), את הבעלים של מסד הנתונים במקור (כדי לוודא שאף מסד נתונים לא נמצא בבעלות של sa) ואת נתיבי ברירת המחדל של קובצי הנתונים. מריצים את הפקודה gcloud database-migration migration-jobs verify (לחצו כדי להרחיב):
gcloud database-migration migration-jobs verify
```
gcloud database-migration migration-jobs verify MIGRATION_JOB_ID \
    --region=REGION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫MIGRATION_JOB_ID במזהה של משימת ההעברה.
- ‫REGION במזהה של האזור שבו נשמרת משימת ההעברה.
כדי לבדוק את סטטוס פעולת האימות, מריצים את הפקודה gcloud database-migration operations describe.
מתחילים את משימת ההעברה.
אחרי שהאימות מסתיים בהצלחה, מריצים את הפקודה gcloud database-migration migration-jobs start (לוחצים כדי להרחיב):
gcloud database-migration migration-jobs start
```
gcloud database-migration migration-jobs start MIGRATION_JOB_ID \
    --region=REGION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫MIGRATION_JOB_ID במזהה של משימת ההעברה.
- ‫REGION במזהה של האזור שבו נשמרת משימת ההעברה.
זהירות: כשמתחילים את משימת ההעברה של DAG, השירות Database Migration Service מגדיר באופן אוטומטי את הדגל cloud sql enable dag support לערך on במכונה של Cloud SQL ל-SQL Server ביעד. אל תשנו או תסירו ידנית את הדגל cloud sql enable dag support.

מעקב אחרי ההעברה ואימות שלה

בזמן שמשימת ההעברה של DAG פועלת, אתם יכולים לעקוב אחרי ההתקדמות שלה במסוף Google Cloud , לשלוח שאילתות למסדי הנתונים של היעד במצב קריאה בלבד במהלך CDC ולנהל את הרפליקציה הפעילה.

מעקב אחרי ההתקדמות במסוף Google Cloud

אפשר לעקוב אחרי משימת העברה של DAG שפועלת במסוף Google Cloud בדף Migration job details, כמו כל משימת העברה אחרת ב-Database Migration Service:

בטבלה Databases שבדף הפרטים של משימת ההעברה, בודקים את השלב בזמן אמת (Full dump במהלך הטעינה המלאה הראשונית, CDC במהלך הרפליקציה הרציפה וכל הודעת שגיאה ברמת מסד הנתונים) ואת Restore lag לכל מסד נתונים בקבוצת הזמינות.
בכרטיסייה Monitoring, בודקים את התרשים Restore lag (datamigration.googleapis.com/migration_job/max_replica_sec_lag, שמדווח על השהיית הרפליקציה של Distributed Availability Group בשניות לכל מסד נתונים).

למידע נוסף על מדדי מעקב ומצבי משימות, ראו מדדים של משימות העברה וקודי סטטוס של משימות העברה.

אימות מסדי נתונים שהועברו במצב קריאה בלבד במהלך CDC

בניגוד להעברות שמבוססות על גיבוי (שבהן מסדי הנתונים ביעד נשארים במצב RESTORING עד לקידום), העברות של קבוצות זמינות מבוזרות מאפשרות לשלוח שאילתות למסדי הנתונים של Cloud SQL ל-SQL Server ביעד במצב קריאה בלבד ברגע שהם נכנסים לשלב CDC.

לכל מסד נתונים שבבעלות של פרטי כניסה ל-SQL במכונה המקורית, שירות Database Migration Service יוצר באופן אוטומטי פרטי כניסה במכונה של Cloud SQL ל-SQL Server ביעד, עם הקידומת gcp_dms_, מזהה בן 6 תווים ושם הבעלים של המקור (לדוגמה, gcp_dms_a1b2c3_myowner). כדי לשלוח שאילתה למסד הנתונים עם פרטי הכניסה האלה לפני השדרוג, מתחברים למכונה של Cloud SQL ל-SQL Server ביעד בתור sqlserver, מוצאים את שם המשתמש שנוצר ב-sys.server_principals ומאפסים את הסיסמה שלו:

SELECT name FROM sys.server_principals WHERE name LIKE 'gcp_dms_%';
GO
ALTER LOGIN [GENERATED_DMS_OWNER_LOGIN] WITH PASSWORD = 'NEW_OWNER_PASSWORD';
GO

מחליפים את מה שכתוב בשדות הבאים:

‫GENERATED_DMS_OWNER_LOGIN בשם ההתחברות של בעלי מסד הנתונים שנוצר, שהוחזר על ידי השאילתה.
‫NEW_OWNER_PASSWORD בסיסמה חדשה להתחברות.

למידע נוסף על אימות של אובייקטים ונתונים שהועברו, קראו את המאמר אימות העברה.

ניהול משימת העברה פעילה של DAG (אופציונלי)

בזמן שמשימת ההעברה פועלת בשלב CDC, אתם יכולים לבצע את פעולות הניהול הבאות:

מוסיפים או מסירים מסדי נתונים בקבוצת הזמינות במכונה של שרת ה-SQL במקור, על ידי הפעלת ALTER AVAILABILITY GROUP ... ADD DATABASE או ALTER AVAILABILITY GROUP ... REMOVE DATABASE. ‫Database Migration Service מזהה את השינוי באופן אוטומטי במחזור הסקר הבא שלו, ומעדכן את מכונת היעד של Cloud SQL ל-SQL Server.
מריצים את הפקודה gcloud database-migration migration-jobs stop כדי להפסיק זמנית את הרפליקציה של הנתונים. כדאי לעצור משימת העברה של DAG רק לפרק זמן קצר ומוגדר, כי העדכונים ממשיכים להצטבר ביומני הטרנזקציות בזמן שהרפליקציה מושהית, וזה יכול לגרום לדיסקים של יומני הטרנזקציות להתמלא. ממצב עצירה, אפשר להריץ את הפקודה gcloud database-migration migration-jobs resume כדי להמשיך את שכפול הנתונים, או להריץ את הפקודה gcloud database-migration migration-jobs delete כדי להשלים את ההעברה ולבצע את הניקוי הנדרש.
כדי להפעיל מחדש משימת העברה שנכשלה, מריצים את הפקודה gcloud database-migration migration-jobs restart. כשמפעילים מחדש משימת העברה של DAG, מסדי הנתונים שהועברו נמחקים במכונה של Cloud SQL ל-SQL Server ביעד, קבוצת הזמינות המבוזרת נוצרת מחדש והטעינה המלאה הראשונית מופעלת מחדש ברשת.

קידום, החזרה למצב קודם או השלמה של ההעברה

כשתהיו מוכנים להעביר את האפליקציות ל-Cloud SQL ל-SQL Server, קדמו את משימת ההעברה. בהעברת DAG, קידום המשימה מעביר את Cloud SQL ל-SQL Server למצב ראשי לקריאה/כתיבה, ומעביר את משימת ההעברה לשלב FAILBACK (PHASE_FAILBACK בתגובות של Google Cloud CLI ו-API) עם רפליקציה הפוכה פעילה בחזרה למכונה של SQL Server במקור:

מפסיקים את פעולות הכתיבה של האפליקציה במסדי הנתונים של SQL Server במקור, ובודקים את המדד Restore lag במסוף Google Cloud כדי לוודא שההשהיה ברפליקציה הגיעה לאפס.
קידום משימת ההעברה כדי לעבור ל-Cloud SQL.
מריצים את הפקודה gcloud database-migration migration-jobs promote (לחצו כדי להרחיב):
gcloud database-migration migration-jobs promote
```
gcloud database-migration migration-jobs promote MIGRATION_JOB_ID \
    --region=REGION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫MIGRATION_JOB_ID במזהה של משימת ההעברה.
- ‫REGION במזהה של האזור שבו נשמרת משימת ההעברה.
במהלך הקידום, Database Migration Service מבצע את הפעולות הבאות:
- הגדרת קבוצת הזמינות המבוזרת לביצוע סינכרוני, הפעלת CHECKPOINT בכל מסדי הנתונים של המקור, המתנה לסנכרון של כל הטרנזקציות ללא אובדן נתונים, והיפוך התפקידים של קבוצת הזמינות כך שמכונת היעד של Cloud SQL ל-SQL Server הופכת ל-Primary לקריאה/כתיבה, ומכונת המקור המקורית של SQL Server הופכת ל-Secondary.
- משימת ההעברה נשארת במצב Running ומצב המשנה עובר לשלב FAILBACK (PHASE_FAILBACK בתגובות מה-API ומ-Google Cloud CLI), ומתבצעת רפליקציה רציפה של כתיבות חדשות מיעד Cloud SQL ל-SQL Server בחזרה למכונה של שרת ה-SQL במקור.
אחרי שהקידום מסתיים, מחברים את האפליקציות למכונה החדשה של Cloud SQL ל-SQL Server.
(אופציונלי) חזרה למכונה המקורית של SQL Server.
אם נתקלתם בבעיה אחרי שהעברתם את האפליקציות ל-Cloud SQL ל-SQL Server בזמן שמשימת ההעברה נמצאת בשלב FAILBACK, אתם יכולים לבטל את המעבר בלי לאבד נתונים. כדי לעשות את זה, צריך להפסיק את פעולות הכתיבה של האפליקציה ב-Cloud SQL ל-SQL Server ולהריץ את הפקודה gcloud database-migration migration-jobs promote עם הדגל --failback (לחצו כדי להרחיב):
gcloud database-migration migration-jobs promote --failback
```
gcloud database-migration migration-jobs promote MIGRATION_JOB_ID \
    --region=REGION \
    --failback
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫MIGRATION_JOB_ID במזהה של משימת ההעברה.
- ‫REGION במזהה של האזור שבו נשמרת משימת ההעברה.
הפעלת promote עם הדגל --failback במהלך השלב FAILBACK מסנכרנת את כל השינויים שנכתבו ב-Cloud SQL ל-SQL Server, מחליפה שוב את כיוון הרפליקציה כך שקבוצת הזמינות המקורית של SQL Server הופכת ל-Primary לקריאה/כתיבה ו-Cloud SQL ל-SQL Server הופך ל-Secondary, ומחזירה את משימת ההעברה לשלב CDC. שימו לב שהערך --failback תקף רק כשמשימת ההעברה נמצאת בשלב FAILBACK. אם מריצים את promote בלי --failback במהלך השלב FAILBACK (או מעבירים את --failback במהלך השלב CDC), האימות נכשל עם השגיאה FAILED_PRECONDITION ומשימת ההעברה ממשיכה לפעול.
(אופציונלי) מפסיקים את שכפול הנתונים לפני שמוחקים את משימת ההעברה.
אם רוצים לעצור את שכפול הנתונים לפני שמוחקים את משימת ההעברה באופן סופי, מריצים את הפקודה gcloud database-migration migration-jobs stop (לוחצים כדי להרחיב):
gcloud database-migration migration-jobs stop
```
gcloud database-migration migration-jobs stop MIGRATION_JOB_ID \
    --region=REGION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫MIGRATION_JOB_ID במזהה של משימת ההעברה.
- ‫REGION במזהה של האזור שבו נשמרת משימת ההעברה.
זהירות: עצירת משימת העברה מפסיקה את שכפול הנתונים, אבל צריך להשתמש בה רק לפרק זמן קצר ומוגדר, כי העדכונים ממשיכים להצטבר ביומני העסקאות בזמן שהשכפול נעצר. במצב Stopped, אפשר להריץ את הפקודה gcloud database-migration migration-jobs resume כדי להמשיך את שכפול הנתונים, או להריץ את הפקודה gcloud database-migration migration-jobs delete בשלב הבא כדי להשלים את ההעברה ולבצע את הניקוי הנדרש.
מסיימים את ההעברה ומוחקים את משימת ההעברה.
אחרי שמוודאים שהאפליקציות פועלות באופן מלא עם המכונה החדשה של Cloud SQL ל-SQL Server, וכבר לא צריך רפליקציה הפוכה למכונה של SQL Server, מוחקים את משימת ההעברה (מהמצב Running או Stopped) כדי להשלים את ההעברה ולבצע את הניקוי הנדרש. מריצים את הפקודה gcloud database-migration migration-jobs delete (לחצו כדי להרחיב):
gcloud database-migration migration-jobs delete

הפקודה הזו מחזירה בקשת אישור אינטראקטיבית שדורשת קלט כדי להשלים את הפעולה. אפשר לדלג על בקשת האישור באמצעות הדגל האופציונלי --quiet.
```
gcloud database-migration migration-jobs delete MIGRATION_JOB_ID \
    --region=REGION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫MIGRATION_JOB_ID במזהה של משימת ההעברה.
- ‫REGION במזהה של האזור שבו נשמרת משימת ההעברה.
מחיקת משימת ההעברה משלימה את ההעברה, מפסיקה את הרפליקציה ההפוכה הפעילה, מסירה את האישורים של Distributed Availability Group ושל Database Mirroring בשני המופעים, ומאפשרת להפעיל תכונות של Cloud SQL ל-SQL Server שמוגבלות במהלך הרפליקציה של DAG (כמו שחזור מערכת מנקודה מסוימת בזמן (PITR) או רפליקות לקריאה בלבד).

אחרי שמוחקים את משימת ההעברה, אפשר להשבית או להסיר את הדגל לניהול מסד הנתונים cloud sql enable dag support במכונה של Cloud SQL ל-SQL Server ביעד, להסיר את השרת המקושר במכונה של Cloud SQL ל-SQL Server (EXEC master.dbo.sp_dropserver @server = N'LINKED_SERVER_NAME', @droplogins = 'droplogins';) ולהסיר את מסד הנתונים המסייע gcp_dms_db ואת פרטי ההתחברות להעברה במכונה של SQL Server במקור.

מעבר מ-SQL Server בניהול עצמי באמצעות קבוצות זמינות מבוזרות

עלויות

לפני שמתחילים

התפקידים הנדרשים

יצירה והכנה של מכונת היעד של Cloud SQL ל-SQL Server

הכנת מכונת המקור של SQL Server

הפעלת Always On Availability Groups

יצירת נקודת הקצה והאישור של שיקוף מסד הנתונים

הקצאת תפקיד sysadmin

הרשאות מינימליות (gcp_dms_db)

הכנת מסדי הנתונים של המקור וקבוצת הזמינות

יצירת קישוריות דו-כיוונית לרשת פרטית

יציאות וכתובות IP נדרשות

הגדרת שיטת הרשת הפרטית

גישה לשירותים פרטיים

התחברות לשירות פרטי

הגדרת כללים לחומת האש של הענן הווירטואלי הפרטי (VPC) ושל המארח המקורי

אימות הנגישות באמצעות בדיקות קישוריות של Cloud SQL

יצירה ואימות של השרת המקושר במכונה של Cloud SQL ל-SQL Server ביעד

‫Cloud SQL ל-SQL Server בגרסאות 2017, 2019 ו-2022

‫Cloud SQL ל-SQL Server 2025

יצירת פרופילי חיבור והרצת משימת ההעברה

`gcloud database-migration connection-profiles create sqlserver`

`gcloud database-migration connection-profiles create sqlserver`

`gcloud database-migration migration-jobs create`

`gcloud database-migration migration-jobs verify`

`gcloud database-migration migration-jobs start`

מעקב אחרי ההעברה ואימות שלה

מעקב אחרי ההתקדמות במסוף Google Cloud

אימות מסדי נתונים שהועברו במצב קריאה בלבד במהלך CDC

ניהול משימת העברה פעילה של DAG (אופציונלי)

קידום, החזרה למצב קודם או השלמה של ההעברה

`gcloud database-migration migration-jobs promote`

`gcloud database-migration migration-jobs promote --failback`

`gcloud database-migration migration-jobs stop`

`gcloud database-migration migration-jobs delete`

מעבר מ-SQL Server בניהול עצמי באמצעות קבוצות זמינות מבוזרות קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

עלויות

לפני שמתחילים

התפקידים הנדרשים

יצירה והכנה של מכונת היעד של Cloud SQL ל-SQL Server

הכנת מכונת המקור של SQL Server

הפעלת Always On Availability Groups

יצירת נקודת הקצה והאישור של שיקוף מסד הנתונים

יצירת פרטי התחברות והרשאות ייעודיים ל-Database Migration Service

הקצאת תפקיד sysadmin

הרשאות מינימליות (gcp_dms_db)

הכנת מסדי הנתונים של המקור וקבוצת הזמינות

יצירת קישוריות דו-כיוונית לרשת פרטית

יציאות וכתובות IP נדרשות

הגדרת שיטת הרשת הפרטית

גישה לשירותים פרטיים

התחברות לשירות פרטי

הגדרת כללים לחומת האש של הענן הווירטואלי הפרטי (VPC) ושל המארח המקורי

אימות הנגישות באמצעות בדיקות קישוריות של Cloud SQL

יצירה ואימות של השרת המקושר במכונה של Cloud SQL ל-SQL Server ביעד

‫Cloud SQL ל-SQL Server בגרסאות 2017, 2019 ו-2022

‫Cloud SQL ל-SQL Server 2025

יצירת פרופילי חיבור והרצת משימת ההעברה

gcloud database-migration connection-profiles create sqlserver

gcloud database-migration connection-profiles create sqlserver

gcloud database-migration migration-jobs create

gcloud database-migration migration-jobs verify

gcloud database-migration migration-jobs start

מעקב אחרי ההעברה ואימות שלה

מעקב אחרי ההתקדמות במסוף Google Cloud

אימות מסדי נתונים שהועברו במצב קריאה בלבד במהלך CDC

ניהול משימת העברה פעילה של DAG (אופציונלי)

קידום, החזרה למצב קודם או השלמה של ההעברה

gcloud database-migration migration-jobs promote

gcloud database-migration migration-jobs promote --failback

gcloud database-migration migration-jobs stop

gcloud database-migration migration-jobs delete

מעבר מ-SQL Server בניהול עצמי באמצעות קבוצות זמינות מבוזרות

`gcloud database-migration connection-profiles create sqlserver`

`gcloud database-migration connection-profiles create sqlserver`

`gcloud database-migration migration-jobs create`

`gcloud database-migration migration-jobs verify`

`gcloud database-migration migration-jobs start`

`gcloud database-migration migration-jobs promote`

`gcloud database-migration migration-jobs promote --failback`

`gcloud database-migration migration-jobs stop`

`gcloud database-migration migration-jobs delete`