If it were my farm I'd go into farm view -> all and on the farm in question I'd click options and edit, verify that each role is set with the role name I expect with the correct min and max instances , save the farm config then open up that farms instances; terminate any instances with incorrect role names. If you mess with mysql roles make sure you trigger a mysql bundle before you terminate it.
Mysql data is saved per farm not role so you can switch the mysql role if necessary. I don't know your farm don't do anything that places your production data at risk. If in doubt wait for scalr, prod them via Twitter if your not getting a response. On Sep 1, 2009, at 5:49 PM, Mikhail Malamud <[email protected]> wrote: > > Looking at the DNS zone. it is completely busted containing records > for the r1, r2, r3 and r4. I have no instances of r3 and r4 roles. > > Guys, please help to clean this up. This is impacting our production > environment. > > > > On Tue, Sep 1, 2009 at 5:43 PM, Mikhail Malamud<[email protected] > > wrote: >> Donovan, thanks. >> >> It is a big bite and completely pointless, not considering the fact >> it >> breaks everything since there is no such role in that farm. >> >> Can you elaborate though on >> >> "To recover go into each farm and set the role back to r1." >> >> When I go to applications, I cannot even select the true roles that >> are in that farm. >> >> On Tue, Sep 1, 2009 at 5:34 PM, Donovan Bray<[email protected]> >> wrote: >>> >>> This is by design unfortunately. It's confusing and bites everybody >>> who runs more than one farm in their scalr account. >>> >>> Sync-all will restart instances with the same source role name >>> regardless of what farm they are in; thus if you have r1 in nine >>> different farms if you sync it to r3 all nine farms will be >>> changed to >>> r3. >>> >>> To recover go into each farm and set the role back to r1. >>> >>> To prevent that from occurring next time instead of creating a farm >>> and selecting r1 as your source instance; go to roles new and create >>> r3 and base it off of an instance running r1. After you've synced >>> and >>> renamed the requisite roles, create your farm using the new role >>> names, modify to suit then sync those roles again. >>> >>> I see no advantage to the current design, I've never needed a cross >>> farm sync but it's bitten me in the ass more times than I care to >>> admit. >>> >>> On Sep 1, 2009, at 2:37 PM, mmalamud <[email protected]> >>> wrote: >>> >>>> >>>> let me clarify this a little more. >>>> >>>> 1. Farm 1 {r1, r2} >>>> 2. Farm 2 {r1, r2} >>>> 3. Synch All on Farm 2, Choose new roles names {r3, r4} >>>> 4. Now application myapp.com which was pointing to Farm 1, r1 >>>> points >>>> to Farm 1, r3. >>>> >>>> r3 does not even exist in farm 1. >>>> >>>> >>>> >>>> On Sep 1, 1:41 pm, mmalamud <[email protected]> wrote: >>>>> This is a major issue. Here is what happened >>>>> >>>>> farm1 had roles r1 and r2 >>>>> >>>>> farm 2 had same roles >>>>> >>>>> I did synchronize all on r1 and r2 but chose new role names r3 and >>>>> r4. >>>>> >>>>> r1 and r2 stayed fine in farm1 but my application which which was >>>>> pointing to r1 in farm1 now points to r3 in farm1 and r3 does not >>>>> even >>>>> exist in farm1. >>>>> >>>>> farm id is 2270. >>>>> >>>>> application should be pointing to www64-2009xxxx role. not www64- >>>>> stg3 >>>>> >>> >>>>> >>> >> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "scalr-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/scalr-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
