Hi Dan, I got the point. But does it store those known IP addresses anywhere in metadata or cluster configuration?
I am copying disk store files from prod to dr as it is. As an example, If I have /apps/geode/pdx_metadata directory in prod machine say machine with ip1, my process makes the same replica available in dr site as well say ip2 where ip2 is only for disaster recovery and not a part of active cluster running in prod machine. Is that understanding correct? Thanks, Dharam Sent with BlackBerry Work (www.blackberry.com) ________________________________ From: Dan Smith <[email protected]> Sent: Jul 25, 2017 2:45 AM To: [email protected] Subject: Re: Global Aliases/CommonName in Diskstore config Hi Dharam, Those IP addresses you are seeing are just for your information, showing where that disk store was last known to be stored. The DR members won't trying to contact those PROD ip addresses, they are just telling you what disk store they are waiting on. -Dan On Mon, Jul 24, 2017 at 2:00 PM, Thacker, Dharam <[email protected]<mailto:[email protected]>> wrote: Hi Dan, Yes we are copying files from prod to dr site but worried about dependency on ip addresses being printed as last known location for disk store. As soon as I make my cluster offline in prod and restart the same in dr which has different sets of ip addresses, it may complain as I think. We never use ip addresses while connecting to locator or server but use f5 load blanacer or global load balanced names which at a time is pointing to either prod or dr machine. Do you suggest any way for that? Regards, Dharam Sent with BlackBerry Work (www.blackberry.com<http://www.blackberry.com>) ________________________________ From: Dan Smith <[email protected]<mailto:[email protected]>> Sent: Jul 25, 2017 01:30 To: [email protected]<mailto:[email protected]> Subject: Re: Global Aliases/CommonName in Diskstore config Hi Dharam, I'm not quite sure I understand what you are asking for. Are you asking for the ability to configure the location of the disk store using an alias? You can put variables in your cache.xml file - see https://gemfire.docs.pivotal.io/geode/reference/topics/elements_ref.html#topic_7B1CABCAD056499AA57AF3CFDBF8ABE3__section_5DBA12F9FC08406AAD5557E13A3DEDF2. Or are you copying files from PROD to your DR site and wondering why you see the PROD machine names in your log? The log is listing the last known location of those disk store files that it thinks are missing. Once you start up a member using those disk store files, it will update the last known location. -Dan On Mon, Jul 24, 2017 at 3:52 AM, Thacker, Dharam <[email protected]<mailto:[email protected]>> wrote: Hi Team, Is there any way to bring ‘Global Aliases (PROD – DR pair alias)/Common Names’ in location of disk store? When we are working on PROD, usually disk stores are also being replicated at the same folder structure on target DR machine. That helps to resume and rebuild cluster on DR (Disaster Recovery) machine with same cluster config and disk store references. [info 2017/07/24 03:16:48.543 EDT EventServer1 <main> tid=0x1] Region /PdxTypes has potentially stale data. It is waiting for another member to recover the latest data. My persistent id: DiskStore ID: 73ccf4ad-a5e0-42e2-8ce4-f1fd9f559c8a Name: EventServer1 Location: /A1.B1.C1.D1:/apps/geode/pdx_metadata Members with potentially new data: [ DiskStore ID: 94e4fdff-0db0-4bed-8858-04ac2f1ebd54 Name: EventServer1 Location: /A2.B2.C2.D2:/apps/geode/pdx_metadata ] Use the "gfsh show missing-disk-stores" command to see all disk stores that are being waited on by other members. Thanks, Dharam This message is confidential and subject to terms at: http://www.jpmorgan.com/emaildisclaimer<http://www.jpmorgan.com/emaildisclaimer> including on confidentiality, legal privilege, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited. This message is confidential and subject to terms at: http://www.jpmorgan.com/emaildisclaimer<http://www.jpmorgan.com/emaildisclaimer> including on confidentiality, legal privilege, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited. This message is confidential and subject to terms at: http://www.jpmorgan.com/emaildisclaimer including on confidentiality, legal privilege, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.
