Migrating When the Currently Active Host is Unavailable Use this migration
10.2.16.3.1 Migrating When the Currently Active Host is Unavailable Use this migration
procedure if a clustered Managed Server that was the active server for the migratable service crashes or becomes unreachable. This procedure purges the failed Managed Servers configuration cache. The purpose of purging the cache is to ensure that, when the failed server instance is once again available, it does not re-deploy a service that you have since migrated to another Managed Server. Purging the cache eliminates the risk that Managed Server which was previously the active host for the service uses local, out-of-date configuration data when it starts up again. 1. Disconnect the machine from the network entirely. It should not be accessible to the Administration Server or client traffic. If the machine has a dual ported disk, disconnect it. 2. Migrate the migratable services to a Managed Server instance on a different machine. The Administration Server must be running, so that it can coordinate the migration and update the activation table. ■ If you use the command line for migration, use the -sourcedown flag. ■ If you use the Console, it will ask you to make sure the source server is not going to restart. The migratable service is now available on a different Managed Server on a different machine. The following steps can be performed at leisure. 3. Perform the necessary repair or maintenance on the failed machine. 4. Reboot the machine, but do not connect it to the network. Node Manager will start as a service or daemon, and will attempt to start the Managed Servers on the machine. ■ If Managed Server Independence is enabled, the Managed Server will start, even though it cannot connect to the Administration Server. ■ If Managed Server Independence is disabled, the Managed Server will not start, because it cannot connect to the Administration Server. 5. Reconnect the machine to the network and shared storage, including dual ported disk, if applicable. 6. Restart the Node Manager daemonservice or reboot the machine, to start all remaining Managed Servers. 7. Start the Managed Server that was disabled. This is a normal start up, rather than a restart performed by Node Manager. The Administration Server must be reachable and running, so that the Managed Servers can synchronize with the migratable service activation table on the Administration Server—and hence know that it is no longer the active host of the migratable service.10.2.17 Configure In-Memory HTTP Replication
Parts
» Oracle Fusion Middleware Online Documentation Library
» Document Scope and Audience Guide to this Document
» What Are the Benefits of Clustering? What Are the Key Capabilities of a Cluster?
» Servlets and JSPs EJBs and RMI Objects
» Getting Connections with Clustered JDBC Failover and Load Balancing for JDBC Connections
» Pure-Java Versus Native Socket Reader Implementations
» Client Communication via Sockets
» How WebLogic Server Creates the Cluster-Wide JNDI Tree
» How WebLogic Server Updates the JNDI Tree Client Interaction with the Cluster-Wide JNDI Tree
» Load Balancer Configuration Requirements Load Balancers and the WebLogic Session Cookie
» Related Programming Considerations How Session Connection and Failover Works with a Load Balancer
» Round-Robin Load Balancing Weight-Based Load Balancing
» Transactional Collocation Optimization for Collocated Objects
» Methods of Configuring Clusters Load Balancing for JDBC Connections
» Using Replication Groups HTTP Session State Replication
» Connection with Load Balancing Hardware Failover with Load Balancing Hardware
» Configuration Requirements for Cross-Cluster Replication
» Configuring Session State Replication Across Clusters
» Clustering Objects with Replica-Aware Stubs
» Failover and JDBC Connections Understanding Server and Service Migration
» Migration Terminology Oracle Fusion Middleware Online Documentation Library
» Features That Use Leasing Leasing Versions
» Determining Which Type of Leasing To Use High-availability Database Leasing
» Non-database Consensus Leasing Leasing
» Preparing for Automatic Whole Server Migration
» Configuring Automatic Whole Server Migration
» Startup Process in a Cluster with Migratable Servers
» Automatic Whole Server Migration Process
» Manual Whole Server Migration Process Administration Server Role in Whole Server Migration
» Migratable Server Behavior in a Cluster Node Manager Role in Whole Server Migration
» Cluster Master Role in Whole Server Migration
» JMS-related Services JTA Transaction Recovery Service
» Custom Store Availability for JMS Services Default File Store Availability for JTA
» Best Practices for Targeting JMS when Configuring Automatic Service Migration
» Architecture Web Application Tiers
» Combined Tier Architecture De-Militarized Zone DMZ Load Balancer Proxy Plug-In
» No Collocation Optimization Firewall Restrictions
» Multi-Tier Proxy Architecture Proxy Architecture Benefits Proxy Architecture Limitations
» Proxy Plug-In Versus Load Balancer
» DMZ with Two Firewall Configuration
» Dynamic Cluster Address If you do not explicitly define a cluster address
» Configuration Roadmap Install WebLogic Server
» Starting a WebLogic Server Cluster
» Configure Node Manager Configure Load Balancing Method for EJBs and RMIs
» Sample web.xml This section contains a sample deployment descriptor file
» Accessing Applications Via the Proxy Server Ensure that applications clients will
» Configure Replication Groups Configure Migratable Targets for Pinned Services
» Migrating When the Currently Active Host is Unavailable Use this migration
» Configure Multicast Time-To-Live TTL Configure Multicast Buffer Size
» Cluster-Related Configuration Options Follow Usage and Configuration Guidelines
» Manual Migration of the JTA Transaction Recovery Service State Management in a Cluster
» Naming Considerations Administration Server Considerations
» Firewall Considerations Avoiding Problems
» Check the Server Version Numbers Check the Multicast Address Check the CLASSPATH Value
Show more