تعاریف پایه Oracle GoldenGate

گلدن گیت ۲ نوع معماری کلی داره:

• 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 نیست.

• 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 Scalability

اینجا 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