En la práctica de producción, por alguna razón, muchos estudiantes han realizado operaciones de respaldo, sincronización de datos o migración de datos en la base de datos mysql o tabla de datos a través del comando mysqldump.De hecho, hay muchos escenarios de sincronización que involucran la migración de la base de datos, como los siguientes Estos escenarios :

¿Fuerza mayor, el servidor donde se encuentra la base de datos se recicla, o el disco del servidor está dañado, se debe migrar la base de datos?

La presión de lectura y escritura de la base de datos de un solo punto está aumentando. ¿Necesita expandir uno o más nodos para compartir la presión de lectura y escritura?

La cantidad de datos en una sola tabla es demasiado grande, ¿qué debo hacer si es necesario dividirla horizontal o verticalmente?

La base de datos debe migrarse de mysql a otras bases de datos, como PG, OB...

Para muchos estudiantes, los escenarios anteriores pueden estar más o menos relacionados con el negocio en el que se encuentran. Está bien si no los han encontrado. Una vez que ocurren tales problemas, ¿cómo lidiar con ellos? Este artículo utilizará una cierta cantidad de espacio para discutir en detalle en combinación con la experiencia práctica de producción.

2. Escenario de migración de datos

En términos generales, los diferentes escenarios comerciales tienen diferentes modos y requisitos para la migración de datos.Algunos requieren la migración a nivel de servidor de toda la base de datos, algunos solo necesitan migrar los datos de la tabla y otros solo pueden migrar la base de datos.Migre algunas tablas en , y aquí están los siguiente resumen de varios escenarios involucrados en la migración de datos basados en la experiencia práctica en producción.

2.1 Migración de toda la base de datos

Las principales razones de la necesidad de migrar toda la base de datos son:

El servidor se recicla;
Espacio en disco insuficiente;
Corrupción de disco;
La transformación de microservicios del proyecto requiere dividir la base de datos...

La migración de la base de datos completa es común cuando la base de datos se implementa en una máquina física, pero la máquina física puede reciclarse debido a algunas razones especiales, o el disco puede dañarse, por lo que la base de datos en la máquina física debe migrarse en su totalidad;

En algunos escenarios, para restaurar el escenario del problema de producción, pero cuando el entorno de desarrollo o prueba no se puede reproducir, también puede implicar la migración de todos los datos de la base de datos, y es necesario migrar una copia de los datos de producción a un máquina de construcción propia.

2.2 Migración de datos de tablas

No sé si te has encontrado con los siguientes escenarios:

La estructura de la tabla de producción ha cambiado, como agregar nuevos campos, pero no quieres dejar de actualizar;
La cantidad de datos en una determinada tabla es demasiado grande, lo que se ha convertido en el cuello de botella de rendimiento del sistema, y los datos en la tabla de datos deben dividirse horizontal o verticalmente;
Cuando el proyecto cambia, los datos de una determinada tabla en una determinada base de datos deben migrarse por completo a otra base de datos;

La migración de datos de tablas generalmente ocurre cuando se necesita segmentar el volumen de datos de una sola tabla, en este momento se necesitan ciertos medios, que pueden ser herramientas, scripts SQL, procedimientos almacenados o incluso programas externos para completar;

Cambio de versión de mysql 2.3

En la experiencia anterior del editor, mysql se actualizó de 5.7 a 8.X en el entorno de producción. Debido a las grandes diferencias en la codificación del conjunto de caracteres y otros aspectos de las bases de datos de diferentes versiones, los datos de la versión inferior se utilizan directamente. como la versión superior. Para usarlo, experimenté muchos giros y vueltas. Después de algunas trampas, finalmente lo terminé. Por lo tanto, cuando se trata de actualizar versiones de mysql u otras bases de datos relacionales, existe una alta probabilidad de que la migración de datos estará involucrado.

2.4 Migrar datos mysql a otros medios de almacenamiento

Cuando se ajusta la estructura del producto, por ejemplo, antes del ajuste, los datos comerciales se almacenan en una base de datos relacional como mysql.Después de ajustar la estructura, los datos deben escribirse dos veces, como es, mongo , hbase y otros medios de almacenamiento. En este momento, para poder poner en uso el medio de almacenamiento recién agregado lo antes posible, es necesario alinear los datos mysql con el nuevo medio de almacenamiento, lo que implica la migración de datos, que es un escenario común en la producción real.

2.5 Datos autoconstruidos para el entorno de la nube

En los primeros años antes de que la nube pública se implementara por completo, muchas empresas compraron sus propios servidores para construir sus propias bases de datos, o empresas de cierta escala construyeron sus propias salas de computadoras y centros de datos.Con el auge y el uso generalizado de las nubes públicas, Una vez que el servicio está en la nube, inevitablemente se enfrentará al trabajo de migración de datos de los datos autoconstruidos al entorno de la nube.

2.6 datos mysql a otras bases de datos nacionales

En los últimos años, debido a la influencia del entorno externo, muchas empresas de Internet han planteado problemas de seguridad y están surgiendo muchas bases de datos nacionales, como GAUSS, Dameng, etc. Para los sistemas que se han puesto en producción, para para ser compatible con la base de datos doméstica, inevitablemente se enfrentará al trabajo de migrar los datos mysql a estas bases de datos localizadas.

3. Plan de implementación de la migración física de la base de datos

En lo anterior, se resumen con más detalle algunos escenarios comunes en los que puede ocurrir la migración de datos. Para diferentes escenarios, las estrategias para lidiar con la migración de datos específicos también son diferentes, y es difícil tener un conjunto de estrategias generales en la industria. Sin embargo, , combinado con la experiencia de producción real, aquí hay algunas soluciones e ideas relativamente factibles como referencia.

3.1 Descripción general de la migración física de la base de datos

La migración física es adecuada para la migración general de datos masivos. Puede copiar directamente los archivos de datos originales o utilizar la herramienta de cliente Navicat para la migración de copia de seguridad. La migración física entre diferentes servidores requiere mantener la misma versión, configuración y permisos del servidor MySQL en los dos servidores.

La ventaja de este tipo de migración física es que es rápida, pero la desventaja es que se requiere que la configuración del nuevo servidor sea exactamente igual a la del servidor original, aun así, pueden ocurrir algunos errores desconocidos.

3.1.1 Escenarios aplicables para la migración física

Es adecuado para la migración general con una gran cantidad de datos, como la migración de datos para el reemplazo completo del servidor.

3.1.2 Ventajas y desventajas físicas

ventaja

La velocidad de migración es relativamente rápida, sin tener que considerar los detalles de los datos.

defecto

Para garantizar la coherencia de los datos antes y después de la migración, es posible que se requiera un tiempo de inactividad, que no es lo suficientemente flexible, y los errores desconocidos son difíciles de predecir.

A continuación, se utilizará un caso para demostrar los pasos completos de la migración física.

3.2 Copiar archivos de datos para la migración física

Preparación

1. Dos servidores, respectivamente IP1 e IP2;

2. Prepare el entorno mysql en los dos servidores con anticipación, que se puede construir rápidamente usando docker;

3.2.1 Descripción general de la replicación de archivos de datos

Los estudiantes que han usado la base de datos mysql deben estar familiarizados con los archivos de almacenamiento de datos mysql.Tomando 5.7 como ejemplo, para una determinada base de datos, se crearán muchos directorios de archivos para esta base de datos en el directorio de datos mysql, como ibd para registrar archivos de datos de tablas. , archivos frm que describen la información de la tabla, etc.

Por lo tanto, en teoría, para lograr la migración de datos copiando archivos de datos, solo necesita hacer una copia completa del archivo del directorio de datos de la base de datos y mantener el directorio de datos mysql y la estructura de la máquina de destino igual;

3.2.2 Crear una base de datos en la primera máquina

Cree una base de datos db_emp en la máquina IP1 y cree una tabla t_user debajo de la base de datos e inserte un dato para la tabla t_user;

En este punto, en el directorio de datos mysql, puede ver un directorio de datos sobre la biblioteca

3.2.3 Copie los archivos en la primera máquina para copiar

Cabe señalar que, para minimizar otros problemas causados durante el proceso de migración de la copia de datos, intente mantener la versión de mysql en las dos máquinas de manera consistente, y la ubicación del directorio de datos de mysql debe ser consistente. , los datos montados La configuración del directorio es consistente;

El directorio de archivos que debe copiarse es el siguiente (algunos estudiantes dijeron que no es necesario copiar el directorio mysql, pero lo probé aquí y parece funcionar)

Luego copie los directorios anteriores en la misma ubicación en la máquina IP2. Antes de copiar, asegúrese de que no exista tal archivo en el directorio IP.

Para copiar el archivo de datos, puede usar la herramienta ftp, o directamente scp, y descomprimirlo después de completar la copia (tenga en cuenta que debe hacer una copia de seguridad del directorio de datos anterior)

Una vez completada la copia, descomprima el archivo. Una vez completada la descompresión, reinicie el servicio mysql y luego use el cliente para conectarse. Si no hay ningún accidente, puede ver la misma base de datos y datos de tabla;

3.3 Migración de herramientas para migración física

De las operaciones anteriores, el proceso de usar directamente la copia del directorio de datos sigue siendo muy engorroso, y cuando el tamaño del archivo de la base de datos que se va a migrar es grande, el proceso puede ser muy largo. Además, la transmisión de datos El proceso es también se ve afectado fácilmente por factores ambientales externos como la Red. Por supuesto, si en la práctica de producción, si se permite el uso de herramientas de cliente, puede considerar usar herramientas de cliente para cooperar con la migración de todos los datos de la base de datos. Aún tomando la base de datos anterior como ejemplo para ilustración, veamos el proceso de operación específico.

3.3.1 Eliminar la base de datos en IP2

Para garantizar el efecto de demostración, primero elimine la base de datos en IP2

3.3.2 Exportar la base de datos en IP1

Use la herramienta navicat para conectarse al servicio mysql de IP1 y exporte la base de datos de db_emp como un archivo sql

La exportación es rápida debido al pequeño volumen de datos

3.3.3 Importar el archivo sql en IP2

Ejecute el archivo sql e importe el sql exportado anteriormente a través de navicat.Esta operación debe ser realizada por muchos estudiantes en momentos normales, por lo que no entraré en detalles;

4. Plan de implementación de la migración de la lógica de la base de datos

Aunque la migración física parece simple y tosca, de hecho, en la práctica de producción, especialmente en entornos con muchos microservicios y bases de datos a gran escala, la migración física no es una solución común. ¿Por qué dices eso?

4.1 Desventajas de la migración física

no lo suficientemente flexible

Para garantizar la coherencia de los datos antes y después de la migración, puede ser necesario cerrar y volver a migrar los servicios que se ejecutan en línea, lo que no es lo suficientemente flexible.

datos demasiado grandes

En el entorno de producción real, el tamaño del archivo de la base de datos es pequeño en G y dinámico en T. Este tipo de velocidad de copia entre máquinas y requisitos para la red son inimaginables.

problema de copia de seguridad

Si realiza una copia de seguridad de los archivos de datos anteriores, necesita ocupar mucho espacio de almacenamiento en disco. Si hay muchos archivos y el tamaño del archivo es demasiado grande, la copia de seguridad llevará mucho tiempo.

El entorno es difícil de garantizar la consistencia.

De hecho, es difícil garantizar la consistencia del directorio de datos y otros entornos de diferentes máquinas antes y después de la replicación de datos como se mencionó anteriormente. En realidad, muchas dificultades incontrolables a menudo son provocadas por factores del entorno del servidor. Esta es la razón por la que muchos ingenieros de desarrollo y Un dolor de cabeza para los ingenieros de operación y mantenimiento

En la operación real, los factores más impredecibles hacen que la migración física no sea la solución de migración de datos preferida. Por lo tanto, en la mayoría de los casos, los DBA o el personal de operación y mantenimiento prefieren la migración lógica.

Todavía tome el db_emp anterior como ejemplo para ilustración, veamos los pasos de operación específicos.

4.2 Características de la migración lógica

En comparación con la migración física, la migración de base de datos lógica tiene ventajas más obvias y se puede aplicar a varios escenarios, específicamente:

4.2.1 Ventajas y desventajas de la migración lógica

ventaja

Alta compatibilidad, flexible y conveniente, versión cruzada, transferencia de archivos relativamente pequeña

defecto

El tiempo de migración puede ser muy largo. El principio de la migración lógica es convertir los datos y la estructura de la tabla en la base de datos MySQL en archivos SQL. Si el archivo SQL de respaldo es particularmente grande, el proceso de análisis y conversión llevará mucho tiempo.

4.2.2 Asuntos que requieren atención en la migración lógica

1. Verifique las bibliotecas o tablas de datos que no necesitan migrarse;

2. Procesamiento separado para mesas grandes;

3. Verifique los datos tan pronto como se complete la migración

4.3 Copia de seguridad y recuperación de la lógica de la base de datos

La copia de seguridad lógica de la tabla de datos de la base de datos mysql no se elaborará aquí. No es el enfoque de este artículo. Los estudiantes interesados pueden consultar este artículo: copia de seguridad y recuperación de datos mysql. En pocas palabras, el núcleo de la copia de seguridad lógica es utilizar el Comando mysqldump Realice una copia de seguridad de la tabla de datos de la base de datos y realice una recuperación o migración de datos basada en este archivo.

4.3.1 Ejecutar el comando de copia de seguridad de la base de datos

Ejecute el siguiente comando de copia de seguridad de la base de datos para hacer una copia de seguridad de la base de datos db_emp

mysqldump -uroot -p su contraseña --bases de datos db_emp > /var/lib/mysql/db_emp.sql

Una vez completada la ejecución, puede ver que se exporta un archivo sql en el directorio actual;

4.3.2 Copiar archivo sql

Copie el archivo de la base de datos respaldado anteriormente en el mismo directorio en la segunda máquina

4.3.3 Restauración de datos de copia de seguridad

Inicie sesión en el servicio mysql de IP2 y elimine la base de datos db_emp anterior

Ejecute el siguiente comando para restaurar los datos

mysql -uroot -su contraseña < /var/lib/mysql/db_emp.sql

Una vez completada la ejecución, verifique el mysql de IP2 nuevamente y podrá ver que los datos se han migrado;

5. Plan de implementación de migración de aplicaciones

En el negocio real, pueden existir los siguientes escenarios (derivados de requisitos comerciales reales):

No hay personal de implementación profesional o personal familiarizado con la base de datos en el sitio del proyecto;
Algunas tablas de negocios en la base de datos pueden aumentar o disminuir campos de vez en cuando;
La alta disponibilidad fuera del sitio requiere respaldo de datos, respaldo incremental o completo;
Solo necesita hacer una copia de seguridad de los datos de eventos de cambio específicos de algunas tablas, como la adición, eliminación y modificación de datos;
Es necesario sintetizar heterogéneamente nuevas tablas para algunos datos de tablas para otros usos comerciales...

En resumen, una de las características de los escenarios anteriores es que los escenarios de datos a migrar tienen ciertas particularidades, o en escenarios personalizados, en este caso es difícil tratarlo con un método fijo, es un buena opción para resolverlo a través del programa.

Cuando se trata de la práctica, ¿cómo implementarla? En combinación con varios escenarios comunes, a continuación se enumeran varias soluciones de procesamiento de uso común.

5.1 Requisitos e implementación del caso de negocio 1

Hay una tabla en la base de datos de una aplicación A, y ahora es necesario guardar algunos datos de campo de los datos de la tabla A en otra base de datos, y al mismo tiempo recopilar estadísticas y agregar los resultados de un determinado indicador a la aplicación B para visualización en pantalla grande

análisis de la demanda

A través de la descripción del requisito anterior, se pueden extraer los siguientes puntos clave:

La operación es una tabla específica en la base de datos;
Lo que debe migrarse es parte de los datos de la tabla;
Los cálculos estadísticos deben realizarse en los datos de tablas existentes;

Combinado con las necesidades originales anteriores y el análisis de los requisitos, es difícil lograr este requisito directamente a través de la migración de SQL. A continuación se presentan algunas soluciones de implementación de uso común:

A través del procedimiento almacenado de mysql;
A través de la migración lógica, una vez completada la migración, corrija, calcule y complete manualmente los resultados del cálculo;
a través del programa para completar;

Obviamente, la implementación de los métodos primero y segundo no es lo suficientemente flexible y puede implicar operaciones de tiempo de inactividad. Se puede considerar un programa intermedio para completar este asunto. Aquí recomendamos el canal de middleware de código abierto de Ali para implementarlo.

5.1.1 Usar canal para completar la migración de datos

canal es una herramienta de sincronización de bases de datos mysql de código abierto de Ali. Su objetivo principal es proporcionar suscripción y consumo de datos incrementales basados en el análisis de registros incrementales de la base de datos MySQL. dirección del canal git

El principio de implementación del canal se muestra en la siguiente figura.

è¿éæå¥å¾çæè¿°

Tan específico para el programa de aplicación, ¿cómo puede el canal lograr los requisitos anteriores? De hecho, se puede entender simplemente que después de usar canal, canal es equivalente a un oyente que puede monitorear varios cambios de eventos en la tabla de datos de destino. Después de escuchar diferentes eventos de cambio de datos, puede analizar y procesar los registros modificados. Canal puede directamente La instalación, implementación, configuración simple y uso en el servidor también proporcionan un SDK del lado del cliente para el programa.Basado en el SDK, puede convertirse en el punto de entrada para la realización comercial mencionada anteriormente.

Asignado a los requisitos anteriores, la idea de implementación completa es la siguiente:

Configure el canal del servidor por adelantado;
El cliente presenta el SDK de canal;
La aplicación escucha el evento de cambio de datos especificado y escribe los datos en la nueva tabla;
Las estadísticas de la aplicación agregan los resultados a la nueva tabla (este paso también se puede realizar en otro lugar);

5.1.2 código de ejemplo de implementación de canal

Código de muestra del programa intermedio (para una implementación completa, consulte el caso de demostración oficial)

import com.alibaba.fastjson.JSONObject;
import com.alibaba.otter.canal.client.CanalConnector;
import com.alibaba.otter.canal.client.CanalConnectors;
import com.alibaba.otter.canal.protocol.CanalEntry;
import com.alibaba.otter.canal.protocol.Message;
import com.google.protobuf.ByteString;

import java.net.InetSocketAddress;
import java.util.List;

public class CanalClient {

    public static void main(String[] args) throws Exception{

        //1.获取 canal 连接对象
        CanalConnector canalConnector =
                CanalConnectors.newSingleConnector(new
                        InetSocketAddress("canal所在服务器IP", 11111), "example", "", "");

        System.out.println("canal启动并开始监听数据 ...... ");

        while (true){
            canalConnector.connect();
            //订阅表
            canalConnector.subscribe("shop001.*");

            //获取数据
            Message message = canalConnector.get(100);

            //解析message
            List<CanalEntry.Entry> entries = message.getEntries();
            if(entries.size() <=0){
                System.out.println("未检测到数据");
                Thread.sleep(1000);
            }

            for(CanalEntry.Entry entry : entries){
                //1、获取表名
                String tableName = entry.getHeader().getTableName();

                //2、获取类型
                CanalEntry.EntryType entryType = entry.getEntryType();

                //3、获取序列化后的数据
                ByteString storeValue = entry.getStoreValue();

                //判断是否rowdata类型数据
                if(CanalEntry.EntryType.ROWDATA.equals(entryType)){
                    //对第三步中的数据进行解析
                    CanalEntry.RowChange rowChange = CanalEntry.RowChange.parseFrom(storeValue);
                    //获取当前事件的操作类型
                    CanalEntry.EventType eventType = rowChange.getEventType();

                    //获取数据集
                    List<CanalEntry.RowData> rowDatasList = rowChange.getRowDatasList();

                    //便利数据
                    for(CanalEntry.RowData rowData : rowDatasList){

                        //数据变更之前的内容
                        JSONObject beforeData = new JSONObject();
                        List<CanalEntry.Column> beforeColumnsList = rowData.getAfterColumnsList();
                        for(CanalEntry.Column column : beforeColumnsList){
                            beforeData.put(column.getName(),column.getValue());
                        }

                        //数据变更之后的内容
                        List<CanalEntry.Column> afterColumnsList = rowData.getAfterColumnsList();
                        JSONObject afterData = new JSONObject();
                        for(CanalEntry.Column column : afterColumnsList){
                            afterData.put(column.getName(),column.getValue());
                        }

                        System.out.println("Table ：" + tableName +
                                ",eventType :" + eventType +
                                ",beforeData :" + beforeData +
                                ",afterData : " + afterData);

                    }
                }else {
                    System.out.println("当前操作类型为：" + entryType);
                }
            }
        }
    }
}

5.2 Requisitos e implementación del caso de negocio 2

Descripción del requisito

El sistema empresarial a menudo se encuentra con la necesidad de actualizar los datos de una determinada tabla a múltiples almacenamientos, es decir, la actualización de los requisitos mencionados anteriormente.Por ejemplo, después de que los datos de una determinada tabla en mysql cambien, es necesario actualizarlos. a otra base de datos sincrónicamente, y también actualizado sincrónicamente a es, redis, mongo y otro almacenamiento

En tal escenario de demanda, hay una mejor opción, que es la implementación de flink-cdc.

5.2.1 Principios e ideas de implementación de Flink-cdc

La siguiente figura es un diagrama de flujo de negocios sobre la implementación de flink cdc proporcionado por el sitio web oficial. No es difícil entender que esto es muy similar al principio de implementación de canal

è¿éæå¥å¾çæè¿°

Si usa flink cdc para lograr este requisito, puede hacerlo aproximadamente de acuerdo con las siguientes ideas

1. Binlog de configuración de MySQL;

2. El programa introduce dependencias SDK;

3. Escriba un programa, supervise el evento de cambio de datos de la tabla de destino y escriba datos en la tabla de destino;

5.2.2 flink-cdc implementa códigos clave

A continuación se muestra el código de muestra implementado con flink-cdc, los estudiantes interesados pueden estudiarlo en profundidad.

import org.apache.flink.api.java.tuple.Tuple2;
import org.apache.flink.streaming.api.datastream.DataStream;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.table.api.Table;
import org.apache.flink.table.api.bridge.java.StreamTableEnvironment;
import org.apache.flink.types.Row;

public class CdcTest2 {

    public static void main(String[] args) throws Exception{

        //1.创建执行环境
        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

        env.setParallelism(1);
        StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);

        //2.创建 Flink-MySQL-CDC 的 Source
        tableEnv.executeSql("CREATE TABLE user_info1 (" +
                " id STRING NOT NULL," +
                " name STRING NOT NULL," +
                " version INTEGER NOT NULL" +
                ") WITH (" +
                " 'connector' = 'mysql-cdc'," +
                " 'hostname' = 'IP'," +
                " 'port' = '3306'," +
                " 'username' = 'root'," +
                " '连接密码' = '连接密码'," +
                " 'database-name' = 'bank1'," +
                " 'table-name' = 'record'" +
                ")");

        //tableEnv.executeSql("select * from user_info1").print();

        Table table = tableEnv.sqlQuery("select * from user_info1");
        DataStream<Tuple2<Boolean, Row>> retractStream = tableEnv.toRetractStream(table, Row.class);

        //结果打印输出
        retractStream.print();

        env.execute("flinkCdcSql");

    }

}

6. El middleware realiza la migración de datos fuera de línea

Con la creciente demanda de migración de datos, han aparecido en el mercado algunos middleware de código abierto que son fáciles de usar para ayudar a completar la migración de las tablas de datos de la base de datos. Aquí hay algunos middleware de uso común y relativamente estables para la sincronización de datos. .

El canal 6.1 realiza la migración o sincronización de datos.

En lo anterior, presenté brevemente la función de canal y el proceso de completar la sincronización de datos en combinación con el programa. De hecho, la función de canal sigue siendo muy poderosa. Puede sincronizar datos y también puede importar datos mysql a otros almacenamientos, e incluso cooperar con aplicaciones.programa para completar algunas realizaciones de escenas complicadas y especiales.

6.1.1 Usar canal para realizar la migración o sincronización de datos

En términos generales, para usar el canal para realizar la migración o sincronización de datos, consulte los siguientes pasos

1. Instale el servidor del canal;

2. Agregue un archivo de configuración, configure la base de datos de origen, la dirección de la tabla de datos, configure la base de datos de destino, la dirección de la tabla de datos;

3. En función del segundo paso, se pueden realizar configuraciones más detalladas, como sincronizar solo los datos de cambio de eventos específicos en la tabla, y se puede configurar una sincronización incremental o completa según los requisitos;

4. Después de completar el archivo de configuración, inicie el servicio;

5. Si no se puede resolver directamente a través de la configuración, se pueden completar operaciones más complejas con el código de la aplicación;

6.2 datax implementa la migración de datos

6.2.1 Introducción a datosx

DataX es una herramienta/plataforma de sincronización de datos fuera de línea ampliamente utilizada dentro de Ali, que puede realizar una sincronización de datos eficiente entre varias fuentes de datos heterogéneas, incluidas MySQL, Oracle, HDFS, Hive, OceanBase, HBase, OTS, ODPS, etc. DataX adopta The framework + plug El modo -in es actualmente de código abierto y el código está alojado en github, dirección datax git

6.2.2 funciones de datosx

Como un marco de sincronización de datos, DataX abstrae la sincronización de diferentes fuentes de datos en un complemento de Reader que lee datos del origen de datos de origen y un complemento de Writer que escribe datos en el extremo de destino. En teoría, el marco de DataX puede admite la sincronización de datos de cualquier tipo de fuente de datos Trabajo. Al mismo tiempo, el sistema de complemento DataX sirve como un ecosistema: cada vez que se conecta una nueva fuente de datos, la fuente de datos recién agregada puede comunicarse con la fuente de datos existente.

6.2.3 Escenarios aplicables

Por lo general, cuando se suspende el servicio, una parte de los datos se migra de una base de datos a otra base de datos en un período corto de tiempo, o bajo otros tipos de bases de datos diferentes.

6.2.4 datax implementa el proceso de migración de datos

El proceso general de migración de datos mediante datax es más o menos el siguiente:

1. Descargue el paquete de instalación y descomprímalo;

2. Escriba un archivo de configuración para configurar la base de datos original, la tabla, la conexión y otra información para sincronizar;

3. Configurar la información de la base de datos de destino, base de datos, tabla, etc.;

4. datax no necesita que el nombre de la tabla de origen y la tabla de destino sean iguales, e incluso los campos no necesitan ser completamente consistentes, siempre que el tipo de datos sea correcto;

5. Ejecute comandos en el archivo de configuración para completar la migración de datos fuera de línea;

6.2.5 Configuración de simulación de migración de datos datax

La siguiente es una información de configuración para la migración de datos usando datax. Para obtener más detalles, consulte la información oficial;

{
    "job": {
        "setting": {
            "speed": {
                 "channel": 3
            },
            "errorLimit": {
                "record": 0,
                "percentage": 0.02
            }
        },
        "content": [
            {
                "reader": {
                    "name": "mysqlreader",
                    "parameter": {
                        "username": "连接用户名",
                        "password": "连接密码",
                        "column": [
                            "id",
                            "name"
                        ],
                        "connection": [
                            {
                                "table": [
                                    "user_info"    #表名
                                ],
                                "jdbcUrl": [
     "jdbc:mysql://IP1:3306/shop001"			#源地址
                                ]
                            }
                        ]
                    }
                },
               "writer": {
                    "name": "streamwriter",
                    "parameter": {
                        "print":true,	#开启任务运行过程中的打印
	       "column": [
                        "id","name"		#待同步的字段
	         ], 
	    "connection": [
                            {
                                "jdbcUrl": "jdbc:mysql://IP2:3306/shop001", 		#目标地址
                                "table": ["user_info_copy"]		#目标表
                            }
                        ], 
                        "password": "连接密码", 
                        "username": "连接用户名"
                    }
                }
            }
        ]
    }
}

7. Migración de datos fuera de línea de las herramientas del cliente

En el trabajo diario, cuando los requisitos en tiempo real no son altos y la cantidad de datos no es particularmente grande, también puede usar algunas herramientas de cliente para completar el trabajo de migración de datos. trabajo de migración.

7.1 navegación

Navicat es una herramienta de cliente con la que creo que todo el mundo está familiarizado. Se encontrará durante el desarrollo, la operación y el mantenimiento diarios. Esta herramienta de cliente no solo puede satisfacer la conexión diaria y el uso de muchas bases de datos como mysql, PG, OB, etc. , pero también ayudan a completar algunos trabajos de migración de datos de rutina. Por ejemplo, el proceso de migración de la base de datos mysql a postgresql se puede completar fácilmente a través del cliente navicat.Echemos un vistazo a los pasos específicos de la operación.

7.2 Navicat migra datos mysql a postgresql

7.2.1 Preparación

Antes de migrar datos, debe crear una nueva conexión MySQL y PostgreSQL y confirmar que la cuenta de conexión tiene todos los permisos para migrar la base de datos.

7.2.2 Migrar configuración

Haga clic en el menú Herramientas>>Transferir, aparece la siguiente ventana, seleccione MySQL de origen, base de datos PostgreSQL de destino

7.2.3 Selección de tablas para la migración

Seleccionar todas las tablas de la base de datos

7.2.4 Marque Continuar cuando se encuentren errores

La razón es que el índice en MySQL es único en la tabla, pero el nombre del índice en PostgreSQL es único globalmente. Si encuentra errores relacionados durante la sincronización, se proporcionarán suplementos de SQL más adelante.

De acuerdo con los pasos de operación anteriores, se puede completar la migración de datos de mysql a pg.

7.3 tetera

7.3.1 descripción general de la caldera

El nombre chino de Kettle es Kettle. El programador principal de este proyecto espera poner todo tipo de datos en un recipiente y luego fluir en un formato específico. Kettle se usa para la migración de datos, es decir, para transferir todos los datos en una base de datos Importa otra base de datos.

KettleEs una ETLherramienta extranjera de código abierto, puramente Javaescrita, verde sin instalación, extracción de datos eficiente y estable (herramienta de migración de datos).

7.3.2 Proceso de migración de datos del hervidor

Kettle se usa ampliamente en ETL de big data. Después de abrir, puede configurar directamente varias operaciones a través del cliente a través del cliente con una interfaz similar a navicat. La idea general es similar a la de navicat anterior.

Kettle no solo se puede usar para la migración fuera de línea de datos entre bases de datos mysql, sino que también puede realizar la migración entre diferentes tipos de bases de datos, como mysql a mogo.

Ocho, escrito al final del texto.

Este artículo resume los esquemas de procesamiento comunes de migración o sincronización de datos mysql en detalle en un espacio grande. De hecho, la situación en el entorno de producción es mucho más complicada que estos. Por ejemplo, en el modo maestro-esclavo de mysql, nuevo esclavo los nodos deben expandirse. Aquí hay algunos relativamente generales. Las ideas de solución se pueden consultar cuando se encuentren escenarios similares en trabajos posteriores. Este es el final de este artículo, gracias por mirar.

Resumen de soluciones comunes para migración y sincronización de datos mysql

I. Introducción