خب تا حالا داشتیم سناریوی Unidirectional رو باهم مرور میکردیم نوبتی هم باشه نوبته معماری Bidirectional هستش
Bidirectional
معماری Unidirectional یا یکطرفه دیتایی رو از سرور مقصد به سرور مبدا نمیفرسته و همیشه جهت ارسال یکطرفه از سمت مبدا به مقصد هستش خب اگه دقیقاً همین مسیر Unidirectional رو به طور دقیق با همین از مقصد به مبدا برگردیم ما سناریوی Bidirectional رو داریم
یعنی بیایم روی target بگیم که خب تو یه capture داشته باش خب بعدش اون یه trail فایل میسازه و سرویس pump اون رو برمیداره و میفرسته به سمت source و سرویس delivery تغییرات رو روی خودش اعمال بکنه
خب موافقید که قطعاً می‌تونیم این سناریو رو ۲ طرفه بدونیم :)
نکته مهم: این سناریو به صورت پیش‌فرض باعث ایجاد loop میشه قبول دارید مگه نه؟ چون هر بار که تو target اولی تغییری deliver بشه باعث ایجاد یک تغییر تو دیتابیس میشه و باعث میشه دوباره همون داده به نقطه اول برگرده و همینطور ببرید جلو
مثال عملی: ما جایی بودیم که همچین سناریویی رو خودشون راه‌اندازی کرده بودن ولی متوجه مشکل نبودن مشکل این بندگان خدا این بود که مثلاً یک فرم تو اپلیکیشن ایجاد میکردن ولی بعد از یه چایی فرمشون خراب میشد. خب اینها یه مدت واقعا فکر میکردن این چایی خوردنشونه که این مشکل رو ایجاد کرده :) بعد وقتی گفتن بیا کار رو بررسی کن رفتم دیدم درسته این سناریو تو سطح دیتابیس ایجاد شده و باعث شده Insert هایی که سمت مبدا میخوره تو loop بیوفته و دوباره بهش برگرده خب گلدن‌گیت یه قابلیت خوبی که داره و منم راجع بهش گفتم اینه که می‌تونید بگید تغییرات یک کاربری رو capture نکنه حالا شما تو سناریوی Bidirectional هرکاری که خود کاربر ggs (کاربر که تو سطح دیتابیس برای گلدن‌گیت ساختید تا capture ها رو انجام بده) انجام میده رو capture نکن چون اگه capture این کاربر انجام بشه وارد loop میشیم (همیشه باید کار هر کدوم از Nodeها رو یک جایی تموم کنیم)
پس در capture برگشتمون باید این کاربر رو تو کانفیگ فایلها exclude کنیم و همچنین در capture رفتمون باید کاربری که replicat داره باهاش تو دیتابیس مینویسه رو تا loop ما ایجاد نشه
Peer-to-Peer
یک حالت دیگه هم میشه ring رو راه‌اندازی کرد اونم اینکه هر کدوم از دیتابیسها فقط به یکی از دیتابیسها اطلاعات بفرسته و به صورت خطی اطلاعات منتقل بشوند و هر دیتابیس هم ریپلیکیشنش با یک کاربر مجزا انجام بشه که دیگه این مشکلات loop ایجاد نشه
Broadcast
خب ما اگه بخوایم سناریوی broadcast داشته باشیم در گلدن‌گیت چه اتفاقی میوفته؟ در اینجا هر pump فقطبه یک محل اشاره میکنه مثلا ما یک capture در دیتابیس master راه‌انداز می‌کنیم و به ازای هر سرور دیتا روش اعمال میشه یک delivery و pump نیازه
نکته: ما می‌تونیم به ازای هر delivery یک سرویس capture در master ایجاد کنیم ولی معمولاً اینکار رو نمی‌کنیم چون اولاً هرچی تعداد سرورها بالتر بره نگهداری اونها سختر میشه دوماً هر کدوم از این سرویسها که بالا میاد مقداری cpu, ram از حافظه ما اشغال میکنن پس تا جایی که ممکنه ما با کمترین سرویس میخوایم کار رو انجام بدیم
استارتژی: با کمترین سرویس سناریو راه‌اندازی شود
Integration/Consolidation
در این معماری هر سرور نیاز به یک delivery خاص داره چون هر سرویس delivery نیاز داره یک RBA خاصی رو بخونه و اعمال کنه پس خروجی هر سرور trail فایلهای جداگانه از هم هستند و نمیشه با یک delivery سناریو رو انجام داد
Cascading
در این سناریو نیاز به یک سرویس capture و همچنین سرویس pump و delivery برای هر سرور هستش