Таны синхрон SQL commit яагаад VPN-ийн тойрог замыг хүлээдэг вэ

Хуулбарыг хоёр дахь сайт руу зөөсний дараа бичих саатал өсөж, туннель нь хамгийн шинэ бүрэлдэхүүн тул буруу түүн дээр буудаг. Туннель гэм зэмгүй байж болно: синхрон commit-той боломжтой байдлын бүлэг дотор үндсэн хуулбар алсын лог бичих ажил дуусах хүртэл commit-ыг хүлээн зөвшөөрч чадахгүй тул холбоос хэдэн мегабит дамжуулж чадсанаас үл хамааран гүйлгээ бүр тойрог замыг төлдөг. Дамжуулах чадвар секундэд байтыг хэмждэг, саатал нэг солилцоо хэр удаан үргэлжлэхийг хэмждэг бөгөөд commit дуусахад зөвхөн нэг жижиг солилцоо хангалттай. Нэг тоо маргааныг шийднэ: жижиг гүйлгээний commit үргэлжлэх хугацаа, боломжтой байдлын мэдээллийн санд хэмжиж, дараа нь мөн адил инстанцын локал хүснэгттэй харьцуулан дахин хэмжсэн.

Үндсэн хуулбар үнэхээр юу хүлээж байна

Синхрон commit үед үндсэн хуулбар түншийн лог бичлэгүүд бэхжсэн гэдгийг батлах хүртэл commit-ын баталгаажуулалтыг барьж байдаг. Бэхжсэн гэдэг нь хоёрдогчын гүйлгээний лог руу бат бөх бичигдсэн, түүний өгөгдлийн хуудас руу дахин ажиллуулаагүй гэсэн үг. Redo нь үндсэн хуулбарын commit-д нэг миллисекунд ч нэмэхгүйгээр хэдэн минутаар хоцорч болно.

Боломжтой байдлын горимуудын тухай Microsoft-ын баримт бичиг тэр гар барилтыг тайлбарлаж, түнш унахад платформ юу хийдгийг дүрсэлдэг. Синхрон гэж тэмдэглэсэн хуулбар нь хүлээх тухай дүрэм бөгөөд commit бүрт эрүүл алсын хуулбар байна гэсэн байнгын амлалт биш. Тасарсан зам тусдаа тодорхойлогддог бөгөөд энэ нь зөвхөн commit бүтэлгүйтдэг гэсэн үг биш.

Тиймээс таны харж буй хүлээлт нь нийлбэр юм: лог дамжуулалт, хоёр хост дээрх хуваарьлалт, алсын санд бичих. Ханасан лог хэмжээтэй хоёрдогч нь ямар ч хурдны туршилт харуулахгүй цаг нэмдэг. Гомдол VPN-ийг нэрлэх үед тэр диск ховор хэмжигддэг.

Дамжуулах чадвар нь тойрог замын саатал биш

Хурдны туршилт замыг түр дүүргэж, хурдыг мэдээлдэг. Commit нь илүү нарийн зүйл асуудаг: жижиг мессеж нөгөө талд хүрэх, хадгалагдах, буцаж ирэхэд хэр хугацаа шаардагдана. Замын урт, дараалал, пакет алдагдал тэр тоог тодорхойлдог бөгөөд нийлүүлэгч дээд хязгаарыг өсгөхөд тэдгээрийн аль нь ч сайжрахгүй.

Тиймээс «хурдан» туннель олон жижиг дараалсан гүйлгээнээс бүрдсэн бичих ачаалал ихтэй ажилд харагдахуйц торгууль нэмж болно. Мөн адил нийт байтыг мянган commit-д хуваавал тойрог замыг мянган удаа төлнө; нэг бөөн шилжүүлэг үүнийг нэг удаа төлнө.

Сүлжээний эзэмшигчээс төлөөлөх ачааллын дор хуулбарын замын өөр дээр саатал, алдагдлыг хэмжихийг хүсээрэй. Оффисын зөөврийн компьютерээс VPN гарц руу ping хийх эсвэл ойрын зангилаа руу хурдны туршилт хийх нь лог үнэхээр явдаг замд бараг юу ч хамааруулдаггүй. Хэмжилтийн цонхыг бичих удаан цагуудтай давхцуулаарай.

Ямар нэгэн зүйлийг өөрчлөхөөс өмнө хуулбарын төлөвийг уншаарай

Инстанцууд өөрсдийн тухай мэдээлдэг зүйлээс эхлээрэй, учир нь түншлэл хэр эрүүл гэдэг дээр хоёр тал санал зөрж болно, хяналтын самбарын дундаж нь аль дараалал хөдөлж байгааг нуудаг. Доорх асуултууд өөр өөр асуултад хариулдаг: нэг нь мэдээллийн сан бүрийн репликацийн төлөвийг уншдаг, нөгөө нь хуулбар бүр хэрхэн тохируулагдсаныг уншдаг. Горимд хүрэхээс өмнө хоёуланг нь ажиллуулаарай.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size, drs.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

SELECT ar.replica_server_name, ar.availability_mode_desc, ar.failover_mode_desc
FROM sys.availability_replicas AS ar;

Эхний үр дүн лог дамжуулалтыг redo-оос тусгаарладаг. log_send_queue_size өсөж, redo_queue_size тэгш байвал лог ирээгүй гэсэн үг; эсрэгээрээ бол ирсэн бөгөөд дахин тоглуулалт хоцорч байна. Зөвхөн эхний тохиолдол commit-ын зам дээр суудаг.

Хоёр дахь үр дүн аль хуулбарууд үнэхээр таны таамаглаж байгаагаар тохируулагдсаныг баталдаг, учир нь өмнөх ослын үеэр өөрчлөгдсөн горим өөрчлөгдсөн, баримтжуулаагүй хэвээр үлдэх хандлагатай. Бүлгийн өгөгдмөл утгын оронд танд чухал мөрийг уншаарай: availability_mode_desc болон failover_mode_desc нь хуулбар бүрт хамаарна. secondary_lag_seconds зөвхөн SQL Server 2016 ба түүнээс хойшхи хувилбарт байдаг тул хуучин хувилбар танд илгээх дараалал болон redo баганыг л үлдээдэг.

Дараа нь хяналтын самбарын дундажид итгэхийн оронд төлөөлөх бичлэгийг хэмжээрэй. Доорх блокыг боломжтой байдлын мэдээллийн санд ажиллуулж, дараа нь мөн адил инстанц дээрх бүлгээс гадуурх мэдээллийн санд ижил хүснэгтийн хэлбэртэй харьцуулан дахин ажиллуулаарай. Хоёр үргэлжлэх хугацааны ялгаа нь алсын логын бүдүүн үнэ бөгөөд сүлжээний багтай маргаан дээр графикийнхаас хамаагүй сайн тэсдэг. Үүний дараа нэг удаад нэг хувьсагчийг өөрчил, эс тэгвээс ялгаа нь утгаа алдана.

IF OBJECT_ID('dbo.CommitProbe') IS NULL
    CREATE TABLE dbo.CommitProbe (probe_id int PRIMARY KEY, touched_at datetime2(3));
IF NOT EXISTS (SELECT 1 FROM dbo.CommitProbe WHERE probe_id = 1)
    INSERT INTO dbo.CommitProbe (probe_id) VALUES (1);
SET STATISTICS TIME ON;
BEGIN TRANSACTION;
UPDATE dbo.CommitProbe SET touched_at = SYSUTCDATETIME() WHERE probe_id = 1;
COMMIT TRANSACTION;
SET STATISTICS TIME OFF;

Асинхрон commit юу худалдаж авах, хэр үнэтэй вэ

Асинхрон commit үед үндсэн хуулбар алсын бэхжүүлэлтийн баталгаажуулалтыг хүлээхээ болих тул тойрог зам commit-ын замаас гардаг. Commit-ын саатал буурч, хоёрдогч нь хэн ч хянадаггүй хэмжээгээр хоцрох эрхтэй болно. Энэ нь хүлээлтийн бодит засвар, амлалтын бодит өөрчлөлт юм.

Үнэ нь сэргээх цэгийн шийдвэр юм. Хэрэв үндсэн хуулбар өөрийн лог үнэхээр ашиглаж болох гэмтэлд шилжих зорилгод хүрэхээс өмнө үхвэл, үйлчилгээг асинхрон хуулбар руу зөөх нь програмын аль хэдийн commit гэж мэдээлсэн гүйлгээг хаядаг. Ямар ч тохиргооны харилцах цонх үүнийг тэгж харуулдаггүй, учир нь энэ нь хүлээн зөвшөөрөгдөх алдагдлын тухай бизнесийн асуулт, гүйцэтгэлийн тохиргоо биш. Хүлээн зөвшөөрөх алдагдлын цонхыг ослоос өмнө бичээрэй, түүний үеэр биш.

Горимыг өгөгдлийн эзэмшигчтэй бичгээр тохиролцож, илүүд үзсэн зорилт боломжгүй тохиолдолын гэмтэлд шилжих журамтай хамт. Дизайны баримт бичиг дэх синхрон нь үйл ажиллагааны гарын авлага биш, асинхрон нь дарааллыг ажиглахаа болих тусгай зөвшөөрөл биш.

Дараа нь хамгаалж чадах засварыг сонгоорой

Дөрвөн шударга сонголт байна. Програмын семантик багцлахыг зөвшөөрдөг газарт зайлсхийж болох commit-ын тойрог замыг таслаарай; хэмжсэн дамжуулалт эсвэл хадгалалтын саадыг засаарай, энэ нь хоёрдогч дээр том хоолойн оронд илүү хурдан лог хэмжээ гэсэн үг байж болно; тойрог зам багасахын тулд хуулбарыг ойртуулаарай; эсвэл хамгаалалтын бодлогыг сулруулж, илүү өргөн алдагдлын цонхыг хүлээн зөвшөөрөөрэй. Нэг нь саатлыг өөр зүйл зарцуулж худалдаж авдаг, дөрөв дэх нь бат бөхийг зарцуулдаг. Сонгохоос өмнө зарцуулалтыг нэрлээрэй.

Ажлын ачааллын саатлын зорилт болон түүний бат бөхийн шаардлагыг нэгэн зэрэг өмнөө тавьж шийдээрэй, учир нь нэгийг оновчтой болгох нь нөгөөг чимээгүй зарцуулдаг. Дараа нь өөрчлөлтөөс өмнө хэмжсэн тэр гүйлгээг дахин ажиллуулаарай. Тэр тоог хөдөлгөж чадахгүй засвар бол өөрчлөлтийн тасаг зүүсэн таамаг юм.

Өөрчлөлтийн бүртгэлд өмнөх болон дараах уншилтыг хадгалаарай. Эс бөгөөс удаан бичлэгийг харсан дараагийн хүн мөрдөн шалгалтыг эхнээс давтаж, дахин туннелийг буруутгаж эхэлдэг.