Sponsored Content
Operating Systems AIX IBM TDS/SDS (LDAP) - can I mix endianness among servers in an instance ? Post 303039487 by maraixadm on Monday 7th of October 2019 06:07:12 PM
Old 10-07-2019
IBM TDS/SDS (LDAP) - can I mix endianness among servers in an instance ?

I'd like to add some x/linux-based servers to my current AIX-based TDS/SDS server community. Reading the Fine Install Guide (rtfig ?) I believe this may be covered by the section "Upgrade an instance of a previous version to a different computer" i.e. I'm going to install latest/greatest SDS on a new server image, then bring in the instance data from one of my current servers.

The chart in that section of the Install Guide indicates this is only possible among systems with the same endianness.

Is it possible to have Intel & power servers cooperating on the same directory ? If so, can someone pls point me to doc on how to get there ?

Much appreciated !

[edit:] more reading. I see in the section "creating a copy of an existing instance" the same requirement that only data from a source with the same endianness as the target can be used.

So: can I create an instance copy without data, then (quiesce replication and suspend my servers and) dump the directory to an LDIF, and load the new instance from that instead of from a backup ? Then ensuring that replication is prepared on the new copy and then spinning up the whole pile ? The crux being that by importing the data as text rather than binary, I avoid the fact that handling of endianness/network byte order is missing from the deploy tools ?

Same question as above though, crudely, does replication handle network byte order correctly and swap data nice between different endiannesses ?

Last edited by maraixadm; 10-08-2019 at 12:28 AM..
 

5 More Discussions You Might Find Interesting

1. UNIX for Advanced & Expert Users

HP-UX 10.2 servers interoperability with IBM mass storage devices

Does anyone have succesfully interconnected HP-UX 10.2 HP 9000 K370 servers with A6885A HBA's, with an IBM Fastt storage server? I need to replace integrate both platforms. Interoperability matrices from manufacturers do not certified such integration. Thanks for anybody's help. (0 Replies)
Discussion started by: raltmannr
0 Replies

2. UNIX for Dummies Questions & Answers

Is no LDAP unusual for 40+ solaris servers?

I am the new jr admin on a solaris team (2 people). We have over 40 solaris servers (v8 and v9) yet no LDAP to manage it all. Is this unusual? So, if we need to add a new user, we have to add him 40x. Thanks in advance ~R (1 Reply)
Discussion started by: abstractrick
1 Replies

3. AIX

IBM Servers Documentation

Hello dear friends, I wanrt to document our servers configuration but have no Idea which softweare should I use for documenting server environment.. maybe anyone can suggest me which software should I use.. thanks in Advance (2 Replies)
Discussion started by: Vit0_Corleone
2 Replies

4. AIX

executable problems with shell script in IBM servers

We have a java stand alone application running currently on sun Solaris system. The java application runs on Jdk 1.4. We are reshooting this java application to new Ibm servers. There are 10 unix scripts for this application. All scripts works well except one shell script, This shell... (2 Replies)
Discussion started by: poojagupta
2 Replies

5. AIX

Mix LDAP and LOCAL user on AIX

Hello, I'm currently trying to mix local and LDAP users on an AIX 7.1. I've triied many things. My LDAP Server in on a CentOS - OpenLDAP (which works fine with linux). I'm currently stuck on AIX at how to declare LDAP AND Local users. Here's what i did : /usr/sbin/mksecldap -c -h 'ldap03'... (15 Replies)
Discussion started by: AIX_user_324891
15 Replies
MYSQLREPLICATE(1)						  MySQL Utilities						 MYSQLREPLICATE(1)

NAME
mysqlreplicate - Setup replication among two MySQL servers SYNOPSIS
mysqlreplicate [options] DESCRIPTION
This utility permits an administrator to start replication from one server (the master) to another (the slave). The user provides login information for the slave and connection information for connecting to the master. It is also possible to specify a database to be used to test replication. The utility reports conditions where the storage engines on the master and the slave differ. It also reports a warning if the InnoDB stor- age engine differs on the master and slave. For InnoDB to be the same, both servers must be running the same "type" of InnoDB (built-in or the InnoDB Plugin), and InnoDB on both servers must have the same major and minor version numbers and enabled state. By default, the utility issues warnings for mismatches between the sets of storage engines, the default storage engine, and the InnoDB storage engine. To produce errors instead, use the --pedantic option, which requires storage engines to be the same on the master and slave. The -vv option displays any discrepancies between the storage engines and InnoDB values, with or without the --pedantic option. Replication can be started using one of the following strategies. Start from the current position (default) Start replication from the current master binary log file and position. The utility uses the SHOW MASTER STATUS statement to retrieve this information. Start from the beginning Start replication from the first event recorded in the master binary log. To do this, use the --start-from-beginning option. Start from a binary log file Start replication from the first event in a specific master binary log file. To do this, use the --master-log-file option. Start from a specific event Start replication from specific event coordinates (specific binary log file and position). To do this, use the --master-log-file and --master-log-pos options. OPTIONS
mysqlreplicate accepts the following command-line options: --help Display a help message and exit. --master=<master> Connection information for the master server in <user>[:<passwd>]@<host>[:<port>][:<socket>] format. --master-log-file=<master_log_file> Begin replication from the beginning of this master log file. --master-log-pos=<master_log_pos> Begin replication from this position in the master log file. This option is not valid unless --master-log-file is given. --pedantic, -p Fail if both servers do not have the same set of storage engines, the same default storage engine, and the same InnoDB storage engine. --rpl-user=<replication_user> The user and password for the replication user, in name:passwd format. The default is rpl:rpl. --slave=<slave> Connection information for the slave server in <user>[:<passwd>]@<host>[:<port>][:<socket>] format. --start-from-beginning, -b Start replication at the beginning of events logged in the master binary log. This option is not valid unless both --master-log-file and --master-log-pos are given. --test-db=<test_database> The database name to use for testing the replication setup. If this option is not given, no testing is done, only error checking. --verbose, -v Specify how much information to display. Use this option multiple times to increase the amount of information. For example, -v = verbose, -vv = more verbose, -vvv = debug. --version Display version information and exit. NOTES
The login user for the master server must have the appropriate permissions to grant access to all databases and the ability to create a user account. For example, the user account used to connect to the master must have the WITH GRANT OPTION privilege. The server IDs on the master and slave must be nonzero and unique. The utility reports an error if the server ID is 0 on either server or the same on the master and slave. Set these values before starting this utility. EXAMPLES
To set up replication between two MySQL instances running on different ports of the same host using the default settings, use this command: $ mysqlreplicate --master=root@localhost:3306 --slave=root@localhost:3307 --rpl-user=rpl:rpl # master on localhost: ... connected. # slave on localhost: ... connected. # Checking for binary logging on master... # Setting up replication... # ...done. The following command uses --pedantic to ensure that replication between the master and slave is successful if and only if both servers have the same storage engines available, the same default storage engine, and the same InnoDB storage engine: $ mysqlreplicate --master=root@localhost:3306 --slave=root@localhost:3307 --rpl-user=rpl:rpl -vv --pedantic # master on localhost: ... connected. # slave on localhost: ... connected. # master id = 2 # slave id = 99 # Checking InnoDB statistics for type and version conflicts. # Checking storage engines... # Checking for binary logging on master... # Setting up replication... # Flushing tables on master with read lock... # Connecting slave to master... # CHANGE MASTER TO MASTER_HOST = [...omitted...] # Starting slave... # status: Waiting for master to send event # error: 0: # Unlocking tables on master... # ...done. The following command starts replication from the current position of the master (which is the default): $ mysqlreplicate --master=root@localhost:3306 --slave=root@localhost:3307 --rpl-user=rpl:rpl # master on localhost: ... connected. # slave on localhost: ... connected. # Checking for binary logging on master... # Setting up replication... # ...done. The following command starts replication from the beginning of recorded events on the master: $ mysqlreplicate --master=root@localhost:3306 --slave=root@localhost:3307 --rpl-user=rpl:rpl --start-from-beginning # master on localhost: ... connected. # slave on localhost: ... connected. # Checking for binary logging on master... # Setting up replication... # ...done. The following command starts replication from the beginning of a specific master binary log file: $ mysqlreplicate --master=root@localhost:3306 --slave=root@localhost:3307 --rpl-user=rpl:rpl --master-log-file=my_log.000003 # master on localhost: ... connected. # slave on localhost: ... connected. # Checking for binary logging on master... # Setting up replication... # ...done. The following command starts replication from specific master binary log coordinates (specific log file and position): $ mysqlreplicate --master=root@localhost:3306 --slave=root@localhost:3307 --rpl-user=rpl:rpl --master-log-file=my_log.000001 --master-log-pos=96 # master on localhost: ... connected. # slave on localhost: ... connected. # Checking for binary logging on master... # Setting up replication... # ...done. RECOMMENDATIONS
You should set read_only = 1 in the my.cnf file for the slave to ensure that no accidental data changes, such as INSERT, DELETE, UPDATE, and so forth, are permitted on the slave other than those produced by events read from the master. Use the --pedantic and -vv options for setting up replication on production servers to avoid possible problems with differing storage engines. COPYRIGHT
Copyright (c) 2010, 2012, Oracle and/or its affiliates. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 of the License. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MER- CHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA AUTHOR
MySQL Utilities Team COPYRIGHT
2010, Oracle and/or its affiliates. All rights reserved. 1.0.3 May 09, 2012 MYSQLREPLICATE(1)
All times are GMT -4. The time now is 03:51 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy