گلدن گیت ۲ نوع معماری کلی داره:
- classic capture
در این سناریو گلدن گیت وابسته به ورژن باینری خودش بر روی پلتفرم مورد نظر هستش و گلدن گیت باید کنار هر دیتابیس در سرور مبدا و مقصد نصب بشود
- integrate capture
در این معماری گلدن گیت بر روی یک سرور در کنار یک دیتابیس نصب میشه و با agentهایی دیتابیسها باید logهای خودشون رو به این سرور ارسال کنند و capture (بازکردن لاگها) در سرور گلدن گیت انجام میشه. مثلاً شما میتونید گلدن گیت رو بر روی یک سرور لینوکسی نصب و راهاندازی کنید و ریپلیکیشن بین دیتابیسهای سرورهای ویندوزی راهاندازی کنید.
-
- integrate capture downstream
اگر سرور گلدن گیت با یکی از دیتابیسها یکی باشه بهش integrate capture میگن ولی اگه کلاً سرور گلدن گیت جدا از سرورهای دیتابیس باشه بهش integrate capture downstream میگن
نکته: یادمون باشه مبنای سناریوی integrate کلاً انجام عملیات logminer هستش
-- توپولوژیهایی که GG میتونه برای ما ساپورت بکنه به صورت کلی شکل زیر هستش راجع به هر توپولوژی من یک توضیح مختصری میدم:
UNIDIRECTIONAL or HOT Standby
کابرد دیتاگارد رو در نظر بگیرید این توپولوژی همانند دیتاگارد اوراکله، در حقیقت این کانفیگ یک ریپلیکیشن یکطرفه است که در گلدن گیت به این مدل ریپلیکیشن (ریپلیکیشن یکطرفه) UNIDIRECTIONAL میگن
شما با این توپولوژی میتونید با گلدنگیت standbyهای متفاوتی ایجاد کنید و درکل standbyای که با گلدنگیت راهاندازی بشه HOT Standby گفته میشه چون standby ما به طور کامل OPEN هستش و نیازی نیست موقع سوییچ (برای در دسترس گرفتن standby) از حالت open readonly خارجش بکنیم و open اش کنیم.
(از این سناریو میتونیم برای کار با نرمافزارهای ریپورتگیری استفاده بکنیم)
BI-DIRECTIONAL or Live Standby
معماری ۲ طرفه گلدنگیت
یعنی دیتابیسهای ما به صورت Active در Active هستند. به این مدل Live Standby هم میگن تو این حالت هر دو دیتابیس با هم SYNC هستند
از این حالت به عنوان سایت DR دوطرفه هم میتونیم استفاده بکنیم یعنی با راهاندازی این سناریو تغییرات هر دو سایت دیتابیس رو همیشه یک طرف داریم و اگه یکی از دیتابیسها از دسترس خارج بشه اطلاعات هر ۲ سایت رو باز در دسترس داریم پس علاوه بر اینکه ریپلیکیشن ۲ طرفه راهاندازی کردیم و مشکلاتمون رو رفع کردیم از دادههامون هم محافظت کردیم.
Peer-to-Peer or Ring Database
در زیرساخت شبکه ما میتونیم توپلوژیهای ring راهاندازی کنیم در این معماری نیز میتونیم ring دیتابیسی برقرار کنیم.
شاید بد نباشه بدونید اولین شبکهای که تو ایران راه افتاد شبکه نیروی هوایی بوده که بر مبنای solutionهای IBM Mainframe توسط نیرویهای آمریکایی برای سیستم Logistics بوده (سیستم انبار قطعات جتها) مثلاً اگه تو پایگاه هوایی نوژه همدان یه قطعهی جتای کم میومد و تو شبکه داخلی دنبال قطعه میگشتن سیستم تو تمام اطلاعات شهرهای دیگه میگشت مشهد، بوشهر و ... استعلام قطعه رو میگرفت البته به صورت رینگ دیتابیسی که همهی پایگاهدادهها با هم SYNC بودند.
هم اکنون انجام اینکار با گلدنگیت به سادگی ممکنه و نیازی به solutionهای گران قیمت IBM نیست.
یکی از تجربیات عملی من در این حوزه راهاندازی این ring در شرکتی بین مشهد - تهران - شیراز بود. مشکل این بود که لیست پرواز توسط اتوماسیون اداری فرستاده میشد و اولین سناریویی که توسط تیم اپلیکیشن برای SYNC اتوماسیون اداری پیادهسازی شده بود سناریوی اپلیکیشنی بود فرضاً پرواز شما از شیراز رسیده تهران و خب ۱ ساعت بعدش لیست پرواز میرسید چون مثلاً میل سرور قطع میشد یا پکیجها با مشکل رد و بدل میشدند این قضیه توسط امنیت پرواز مورد قبول نیستش چون لیست پرواز باید قبل از پرواز برسه تا چکها انجام بشه
ما اومدیم راهحل رو بر مبنای همین سولوشن گلدنگیت و به صورت دیتابیسی ارائه دادیم و خیلی راهکار جامع و با سرعت بالا و خوبی بود جوری که بعد از راهاندازی راهکار بین مشهد و تهران، شیراز هم اضافه شد و خواست از این راهکار دیتابیسی برای SYNC لیست خودش استفاده بکنه خب این وسط تهران هم به عنوان مرکز باید کنترل دیتا رو انجام میداد پس عملاً یک ring با گلدنگیت ایجاد کردیم تا دیتاها با سرعت بالا و بدون مشکل جا به جا بشه.
حالا فرض کنید تهران میاد میگه دیتای من master هستش و ما یکسری فرم براساس ISO میسازیم(فرم حضور و غیاب، فرم تحویل انباری و ...) و میخوایم این فرمها به محض اینکه در تهران ساخته شد اتوماتیک در مشهد و شیراز هم ساخته بشوند ولی فقط این موضوع براس سیستم تهران باشه و اگه مشهد با سیستم فرمسازش اومد و فرمی رو ساخت دیگه به صورت لوکالی خودش باشه و تو تهران ساخته نشه این موضوع در رینگ گلدنگیت به راحتی با فیلترهای گوناگون قایل پیادهسازی هستش و نیازی نیست همهی دیتا باهم جا به جا بشه
حالا اگه یکی از نودهای رینگ قطع بشه ارتباط نودهای دیگه قطع نمیشه و ریپلیکیشن نودهای باقی مونده بدون مشکل انجام میشه و اگه نود ما که از مدار خارج شده دوباره به مدار برگرده دیتابیسها دوباره باهم SYNC میشوند.
ما معمولاً میگیم اگه master تهران هستش اگه شیراز قطع شد فقط خودتو با مشهد SYNC نگه داره
Broadcast or Data Distribution
تو این توپولوژی ما میخوایم یک broadcat دیتابیسی راهاندازی کنیم تا داده رو بین دیتابیسهای مختلف توزیع کنیم. در حقیقت ما یک دیتابیس master داریم و نیاز داریم که داده رو بین چند دیتابیس slave توزیع کنیم چون هرکی نیاز داره دیتای خودشو داشته باشه
در این توپولوژی ما broadcat یکطرفه داریم البته میتونیم broadcast دوطرفه هم داشته باشیم ولی معمولاً کارایی بالایی از لحاظ بیزنسی نداره
Integration/Consolidation or Data Warehouse/Mart/Store
فرض کنید ما دیتابیسهای مختلفی از vendorهای مختلف داریم مثلاً داریم از MySQL, DB2, SQL Server در اپلیکیشنهای مختلف استفاده میکنیم حالا نیاز داریم دیتای این دیتابیسها رو باهم تجمیع بکنیم و در یک دیتابیس دیگه ذخیره بکنیم تا انبارهداده ای رو شکل بدیم تو این سناریو خیلی مهمه که این دیتابیسها از دسترس خارج نشوند و به صورت لحظهای دیتا و تغییرات اونها در انبارهداده ما تجمیع بشه خب ما با گلدنگیت به راحتی میتونیم اینکار ور انجام بدیم. همچنین میتونیم به صورت برگشتی هم اینکار رو انجام بدیم یعنی از انبارهداده مون دیتا رو به دیتابیسهای مختلف انتقال بدیم.
مثال عملی این موضوع Bank of America هستش که برای ارتباط سیستم ATMهاش با سیستم Core Bank از گلدنگیت استفاده میکنه به این صورت که هر تراکنشی که در atm میخوره باید از طریق core انجام بشه فضراً فکر کنید در core سند خورده که حساب شما دستور ویژه داره خب موقع استعلام حسابتون از طریق atm فقط داده شما با گلدنگیت به atm برمیگرده و اطلاعات حسابتون خونده میشه
تو این سناریو شما باید broadcat و integration رو باهم راهاندازی کنید چون همیشه این ارتباط یکطرفه نیست و فرضاً در آخر که رکورد شما آپدیت میشه پ شما پول از atm دریافت میکنید باید اطلاعات با core هم sync بشه
CASCADING or Scability
cascade یا همون عملیاتهای آبشاری مثل revoke کردن دسترسیها از دسترسیهای SYSTEM و OBJECT به این صورت که وقتی شما grant system privilege به کاربری با grant admin بدید اگه کاربر ما با کاربر دیگهای این grant رو بده دیگه با revoke privilege از کاربر اول از کاربر دوم دسترسی گرفته نمیشه ولی در object privilege ها با دادن دسترسی با grant admin به کاربر حتی اگه کاربر مذکور دسترسی رو به کاربر دیگهای بده ما اگه از کاربر اولمون که خودمون بهش grant دادیم دسترسی رو revoke کنیم دترسی تمام کاربرهایی که کاربر مذکور به کاربرهای دیگه هم با grant admin خودش داده گرفته میشه که بهش cascade revoke میگن
یا مثل cascade standby در معماری دیتاگارد این همون standby ای هستش که روی standby دیگهای راهاندازی میشه
این معماری یک مشکل اساسی داره physical ما میتونه به صورت passive or active با دیتابیس اصلی sync باشه ولی همیشه cascade standby ما(تا 11g) به اندازه یک لاگ عقبتر هستش و هیچوقت نمیتونیم به صورت آنلاین cascade رو داشته باشیم (تو 12c این مشکل برطرف شده و cascade standby ما هم میتونه همیشه با آخرین تغییرات آنلاین باشه)
یکی دیگه از توپولوژیهای بسیار کاربردی گلدنگیت همین موضوع هستش ما میتونیم دیتابیسهای cascade داشته باشیم مثلا دیتا رو بفرستیم روی یک دیتابیس دیگه و از اون دیتابیس دوباره دیتا رو به یک دیتابیس دیگه به صورت آنلاین(realtime) منتقل کنیم فرضاً در سادهترین شکل ما میتونیم یک HOT Standby راهاندازی کنیم و دوباره بر روی Standby امون یک HOT Standby دیگه بدون محدودیت راهاندازی کنیم
از این قابلیت گلدنگیت برای ساخت Data Martها هم میتوان استفاده کرد مثلا ما نیاز به ساخت یک DWH کوچیک برای بخشهای مالی و اداری و انبار در استانهای مختلف داریم پس با گلدنگیت به راحتی میتونیم از DWH مارتهای گوناگون در محلهای فیزیکی مختلف بسازیم
منبع
https://docs.oracle.com/goldengate/1212/gg-winux/GWUAD/wu_about_gg.htm